There's a documented, sensible way to build a website on HubSpot CMS. You open Design Manager, build or clone a theme, and then your marketers create pages from it in the page editor, write posts in the blog editor, and assemble forms in the form builder. The app is where the work happens, and the app remembers everything you did. For a lot of teams that's exactly right. It lets people who don't write code ship real pages.
We built this site the other way around. The theme, the modules, the page copy, the blog posts, the forms: generative AI produced all of it as code, in a git repository, and HubSpot only ever saw the finished result, pushed over its APIs. Nobody opened Design Manager to design anything. The app didn't stop mattering. It just stopped being the place the site is made.
In this post I'll walk through what that inversion is, what AI did versus what we did, why it was worth it for us, and the places where HubSpot's normal way of working still wins.
Instead of going to HubSpot to design and write, we generated the design and the writing as code and sent it to HubSpot.
Two things flip when you do that. The first is the source of truth: git becomes canonical, and the live CMS becomes downstream of it. The second is the one that makes this more than a developer's git habit. It's who makes the thing. The designer and the copywriter, for most of this site, were a generative model. Our job moved from assembling pages in a WYSIWYG to giving direction and reviewing diffs.
If that sounds familiar, it's the same move software already made: from configuring servers by hand to infrastructure-as-code, from clicking in consoles to GitOps. What's new is applying it to a marketing CMS, and doing it at the moment AI got good enough to handle the part that was always the bottleneck. The bottleneck was never the config. It was the design and the words.
| HubSpot's documented way | How we did it | |
|---|---|---|
| Theme & modules | Hand-built or cloned in Design Manager | Generated by AI as code, from a design direction and our customer-call research |
| Page content | Created and edited by hand in the page editor | Authored as portable definitions in git, AI-drafted, reviewed |
| Blog | Written in the blog editor | 68 posts kept canonical in git, pushed over the API |
| Forms | Built in the form builder | Defined in git, created via the API |
| Source of truth | HubSpot | Git |
| Who makes it | A person clicking | AI generates; a person directs and reviews |
| Quality check | Eyeball the preview | Automated: a pixel-level visual check, accessibility, links and forms, all in CI |
| Deploy | Upload the theme, publish in the app | API deploy of the whole site at once, blocked before it can write if anything's unresolved |
| Reproducibility | Tied to the one portal you edited | Any portal, from git; production stays read-only |
Read the right-hand column top to bottom and you can see the shape of it. Nothing of consequence happens by hand in the app, and nothing reaches production that didn't pass through review and a gate.
The honest version of this is more interesting than the hype version, so I'll be precise.
AI proposed and built the theme (the templates, the modules, the CSS, the small bits of interactivity) and iterated on layout, typography, and accessibility against a stated aesthetic and the language our customers actually use. It drafted page copy and blog content as artifacts we could read, mark up, and reject, the same way you'd review a pull request. And it built the machinery around all of that: the pipeline that deploys the site, the tests, the visual checks. The inversion is self-hosting. The tooling that makes it possible was written the same way as the site.
What it didn't do is decide what's good. Our role compressed to taste, direction, and review: approve the change, or send it back. That's a smaller job than building pages by hand, but it is not a smaller responsibility. A model will happily generate something plausible and wrong. The review step is load-bearing.
A few things got better, and each one traces back to the inversion rather than to AI in the abstract.
Changes are reviewable. A redesign or a copy edit is a diff. You can read it, question it, and reject it before it's live, which the click-in-the-app workflow can't offer.
The result is reproducible and portable. The same site can land on any portal from the same source, so staging and production stop drifting apart. Production is read-only by policy, and the deploy code enforces it: it refuses to write to the production portal at all, with no flag to override.
It's fast where it used to be slow. Generation collapses the design-and-copy step that app editing drags out. The expensive part, making the thing, got cheap. The cheap part, reviewing it, is where we now spend our time.
And quality is verifiable, which is the benefit I'd point a skeptic at. After every deploy we screenshot the live site, forty page renders across desktop and mobile, and compare each one pixel for pixel against a baseline committed to git. If a change moves something it shouldn't, past a hair's-width tolerance, the build goes red. The in-app workflow has no equivalent. There's no way to assert "this still looks right" except to look.
I'd be selling you something if I left it there. The default workflow exists for good reasons, and inverting it costs you real things.
You lose the immediacy. A marketer in the page editor sees the change as they make it. We trade that for a generate-and-review loop, and for someone who just wants to fix a headline, that loop is friction, not safety.
Some things stay locked inside HubSpot no matter what you do. Connecting a domain, designating the homepage, and first creating the blog are gated to the app. The inversion can't reach them, so a human still clicks those once.
And HubSpot's APIs have sharp edges. Publishing has quirks, the edge cache behaves in ways that will surprise you, and there are rules about how module content renders that you learn by hitting them. We wrote those lessons down because we kept paying for them.
The whole approach also leans on its gates being trustworthy. Without the visual check, "deploy from git" can quietly drift from what you intended. The model changes something subtle, nothing errors, and you don't notice until a customer does.
Invert when you value review, reproducibility, and speed on design and content, and when you have (or will build) the checks that make an automated deploy safe to trust. That describes a team treating its website like software.
Stay app-centric when non-developers need to make edits themselves, when there's one site and one portal and no second use in sight, or when a generate-and-review loop would just be ceremony around a one-line change. Inverting a workflow you don't need is coupling with extra steps.
For us the trade was easy. We build AI products; it would be strange to hand-assemble our own website in an editor when a model can design it, write it, and help maintain the machine that ships it, under review, with the tests to prove it didn't break. The app is still serving this page to you. It just isn't where the page was made.
Building our own site this way wasn't much of a leap, because it's the same conviction that built our product: AI should do real, measurable work, not impressive demos. That's what Seventh Sense does for email. It learns the behaviors of your audience, how you're performing at the inbox provider layer and provides you with tools to run the execution of your email program to help you drive your next stage of growth. If you want that kind of AI working in your email program, we'd love to show you. Book a walkthrough.