
An agent-built codebase against a hosted builder
We build on both. The deciding variable is almost never technical capability, it is who owns the site in eighteen months and what they can change without calling anyone.
We build on both, so this is not a defence of either. The question is never which is better. It is who owns the site in eighteen months and what they can do without calling somebody, and that question has a different answer for a four-person clinic than for a company with a developer on staff.
What the codebase actually buys you
- No ceiling. The things that send a Webflow project off the platform, deep variant matrices and multi-country tax among them, are ordinary work in a codebase.
- No per-feature pricing. Site search, localisation and A/B testing are priced add-ons on a hosted builder and dependencies in a repository.
- Real version control. Branches, review and a revertible history, rather than a linear list of published versions.
- Portability. Hosting is a decision you can change, which is not true once a site is built inside a platform.
What it costs you, honestly
Someone has to own it. Dependencies need updating, a framework ships a breaking major version every so often, and a site nobody has touched for a year is a security question rather than a design one. A hosted builder absorbs all of that, and that absorption is most of what the subscription buys. The second cost is editing: a client who cannot change a headline without a developer will stop asking, and a site that stops being updated stops working.
Where the agent changes the arithmetic
It moves the build cost, which used to be the whole argument, and it moves almost nothing else, because the agent runs the build and reads the error itself. A marketing site that was three weeks is now days. But the maintenance burden, the client's ability to edit, the security surface and the question of who answers when something breaks are all exactly where they were. Teams that treat the lower build cost as though it changed the ownership question end up with a cheap site nobody can run.
How we actually decide
| If this is true | Lean |
|---|---|
| The client edits weekly and has no developer | Hosted builder |
| The content model is listings, filters or a deep catalogue | Codebase |
| It must integrate with systems the business already runs | Codebase |
| Five pages, a form, and nothing will change for two years | Hosted builder |
| Several languages with localised URLs | Either, but price the add-on first |
| Nobody internally will own a repository | Hosted builder, without apology |
The platform-specific versions of this argument are in Webflow or Framer and when not to use Webflow, and the plan-gated features that decide a hosted build are in Webflow plan changes. What drives the cost either way is in what actually drives a build cost.
The failure nobody predicts
It is not that the agent wrote bad code. It is that a site got built faster than anybody decided what it was for, so there are now forty pages nobody can justify and a content model shaped by whatever was convenient on day one. Speed removes the natural pause in which scope used to get questioned. If you take one habit from working this way, make it the plan step: read what it intends to build before it builds it, because that is the only remaining moment where changing your mind is cheap. The workflow around that is in building a website with Claude Code.
Cost, over three years rather than at launch
Comparing a build quote against a monthly subscription is the mistake that makes this decision look obvious in whichever direction somebody already preferred. The honest comparison runs over the life of the site and includes the parts nobody quotes.
| Line | Hosted builder | Codebase |
|---|---|---|
| Build | Lower, and faster to a first draft | Lower than it used to be, which is the change |
| Hosting | Per site, per month, and it rises with features | Often free at this traffic, and portable |
| Features | Search, localisation and testing are priced add-ons | Dependencies, so the cost is engineering time |
| Maintenance | Absorbed by the platform. This is most of what you pay for. | Yours. Dependencies, breaking releases, security. |
| Editing | Anyone, immediately | Depends entirely on how the content layer was built |
| Leaving | Export is partial and the design does not come with you | Move the repository |
The hybrid most people should consider
These are not the only two options and treating them as a binary is why the decision feels harder than it is. A marketing site on a hosted builder with a separate application behind it is extremely common and usually correct: the pages that change weekly stay editable by anyone, and the part that needs real engineering gets real engineering. The same split works for commerce, where the storefront is a codebase and checkout is handled by a platform built for it, which is the reasoning in Webflow ecommerce limits.
Questions to settle before anybody builds
- Who changes a headline six months from now, and can they do it today without help?
- What happens when the framework ships a breaking major version, and whose budget is that?
- If this agency disappeared tomorrow, could somebody else pick it up, and what would they need?
- Is there a feature on the roadmap the platform cannot do, and is it real or aspirational?
A good answer to the first question settles most projects on its own. If you are weighing this against rebuilding something that already exists, the prior question is in when a rebuild is the wrong answer, and if the site is live and underperforming, not indexed or not ranking separates the two causes that get confused.
If the comparison lands on the codebase, two follow-on costs belong in the decision rather than discovered afterwards. The first is that you now own the deploy, which is a short checklist rather than a burden but is not optional: shipping to production without surprises is that list. The second is that an agent with write access to your repository needs gates, and writing them once is cheaper than reading every diff forever: the hooks that gate a website repository covers the three that earn their place.

