Why does my team still need a developer to change the site?

The honest version

Building for content that has not been written yet costs more than building for content that has. A site built to look exactly like the design file is faster and cheaper than one built to survive a fifth card, a heading twice as long as the mockup, and a photo uploaded portrait when the layout assumed landscape.

When a build quote comes in surprisingly low, this is usually what got cut. You do not find out at handover. You find out eight months later, when the site that was going to save you a retainer turns out to need one.

CMS driven where it counts

The instinct, once someone has been burned, is to put everything in the CMS. That is the opposite mistake and it is expensive in its own way.

A collection is a contract. Every field is something a person has to understand before they can safely edit anything, and a CMS built for scale you do not have is its own kind of unusable. A five item collection with fourteen fields will sit untouched for a year because nobody wants to be the one who breaks it.

So the question at build time is not how much can go into the CMS. It is which parts of this site will change without me. Those get structured. Everything else gets built directly, because it is not going to move, and structuring it would only add fields for somebody to navigate around.

How to tell which parts those are

Three tests, worth running against every section of the site before anybody builds anything.

• Does it change on someone else's schedule? A catalogue, a team page, a list of certifications, anything tied to the business rather than to the design. That belongs in the CMS.
• Does it repeat? If there are three of something today there will be seven eventually, and a repeating structure that is not a collection is a developer ticket with a delay on it.
• Would changing it require a design decision? A hero layout, a navigation structure, the shape of a pricing table. That is not editing, that is design.

The third test is the one people fail

Handing a team the ability to change anything is not the same as handing them the ability to run the site. It is usually how sites get broken, and it comes from a good instinct: nobody wants to be the bottleneck, so everything gets exposed.

What a team actually wants is a small number of things they can change with total confidence, and a clear edge where the answer is that this one needs a developer. A narrow surface people trust beats a wide one they are scared of.

Where your team edits is a build decision

There is a second question underneath all of this and almost nobody asks it before signing: not what can your team change, but how many places do they have to go to change it.

On True North Jerseys the store does not run on Webflow's own ecommerce. It runs on a third-party app. That kind of decision usually comes with a separate dashboard, a second login, and a team that now maintains its catalogue in one place and its content in another. Six months in, that is how a site quietly stops being maintained: not because anyone found it hard, but because keeping two systems in step was nobody's job.

So the catalogue lives in Webflow CMS collections and the family-run team edits it in Webflow, in the same place they edit everything else. The store engine sits behind that and they never have to think about it. The tool was chosen for what it could do, and then wired so the choice never reached the people using the site.

That is what I mean by a build decision. Nothing about it is visible on the finished site. All of it decides whether the site is still current in two years.

The test to run before you accept a site

Give yourself an hour before launch and do four things.

• Add one more item to every list. A fourth card in a three across grid, an eleventh person on the team page.
• Double the length of the longest heading.
• Leave an optional field empty on one item and look at what renders.
• Upload an image in the wrong aspect ratio.

What that hour tells you

If any of the four needs a developer, the build is not finished. You do not need me to run this and it is the most useful hour you can spend before going live.

If you are commissioning a site right now, put those four checks into the acceptance criteria before you sign anything. It costs you nothing and it changes the conversation, because it moves the definition of done from how the site looks on launch day to whether it survives being used.

The half nobody sells you

The other half of running your own site is naming. I build with Client-First, a convention for naming classes and structuring a project so the next person can read it.

You will never look at a class name. But the developer you hire in two years will, and whether that person can make a change in an afternoon or has to rebuild the site is decided now, by someone you are paying today. Ownership is not a feeling about your site. It is whether the next person can find what they need without asking the last one.

When this is the wrong answer

If your site is five pages, changes twice a year and one person edits it, heavy structure is money badly spent. Build it simple, keep it cheap, and put the difference into the content.

And if nobody on your team wants the job, no amount of structure fixes it. A site that can be run by a team which has not assigned anyone to run it still goes stale. That is not a build problem and I cannot solve it for you.

The short answer

Your team does not need a developer because the platform is limited. They need one because somebody decided, at build time, which parts of the site were allowed to change, and how many places they would have to go to change them. Make those decisions on purpose and most of the tickets never get written.