How this site is built

Most help centers run on a hosted platform, which is why you’ll usually see a vendor name sitting at the bottom of the page. This one doesn’t. Maxio built and runs it ourselves. A lot of the code behind it was written by AI agents, and we’ve wired the documentation directly into how we build and ship the product. Since we make that claim in the footer, here’s what that actually means.

Documentation is part of the development process

When we make a change to a Maxio product, we automatically check whether that change should also update the documentation.

If it should, a draft gets created as part of the development process. That might mean updating an existing article or creating a new one if we don’t already cover it.

The goal is pretty simple: documentation shouldn’t be something we remember to do a few weeks after shipping a feature.

For features that haven’t shipped yet, those changes stay in draft and aren’t visible here. Once the feature is released, the documentation can ship with it.

There’s still a person in the loop. Every article is reviewed and approved before it gets published. The automation helps us find what needs to change and gets the first draft moving; it doesn’t decide what gets published.

The articles live in Git, not a CMS

Our documentation lives in its own Git repository and gets pulled into the site when we build it.

That gives every article the same basic workflow we use for software: version history, diffs, pull requests, and reviews. It also means the pages are built ahead of time and served as static files rather than assembled every time someone visits them.

A lot of the code is written by AI agents

Since mid-August 2026, 98% of commits to this site have included an AI co-author.

And by “AI,” we don’t just mean autocomplete.

For meaningful changes, we start with a written design that lays out what we’re trying to solve, the approach we’re taking, alternatives we considered, and the trade-offs involved. Those design docs live alongside the code, so we keep the reasoning behind the decisions too.

Once the approach is approved, agents can do a lot of the actual implementation. They work in their own copy of the code and submit changes through pull requests, just like a developer would.

A person still reviews and merges those changes. The agents can write a lot of the code. They don’t get to decide what ships.

What has to pass before anything merges

Writing code faster only matters if we can trust what gets shipped. So we’ve put quite a bit of automation around what agents — or people — are allowed to merge.

Before a change can go in:

• Types have to check across the project.
• Unit tests have to pass and the full site has to build.
• Changed logic has to be covered by tests. We measure that against the files being changed rather than relying on a project-wide coverage number.
• Internal links have to point to routes that actually exist, so renaming or moving an article doesn’t quietly create broken links somewhere else.
• Every page gets checked after the build for the metadata used by search engines and link previews.

If one of those checks fails, the change doesn’t merge.

Why we’re sharing this

There’s obviously a lot of “AI-powered” everything right now. We thought it was more useful to show what we’re actually doing with it.

For us, AI isn’t a feature we added to the help center. It’s part of how the help center itself gets built and maintained — from writing code, to catching documentation changes, to testing what gets shipped.

So instead of putting someone else’s platform name in the footer, we put a link here.

Figures on this page describe the site as of August 2026.