Every few weeks a founder tells me they’re moving their marketing site to Next.js, Astro and a headless CMS. It’s “faster”, “more flexible”, “what serious companies use”. Then I ask who on their team will run it after launch. Silence. If you don’t have an in-house dev team, a custom stack isn’t an upgrade. It’s a subscription you didn’t know you signed up for.
The pitch vs the Tuesday afternoon
The pitch for a custom build sounds great: perfect performance scores, total control, no platform limits, a modern stack. All of that is true on launch day.
But your marketing site doesn’t live on launch day. It lives on a random Tuesday afternoon when someone in marketing needs to change a headline, add a logo to the client strip, or spin up a landing page for a campaign that goes live Thursday. That’s the day that decides whether your stack was the right call.
One of our clients publishes a blog post plus on-page updates every Friday on Webflow. We handle it for them, not because they can’t, but because they’d rather spend their time elsewhere. If they ever want to take it back in-house, they can do it next week. On a custom build, that choice doesn’t exist. Every typo is an engineering request.
Every copy change becomes a dev ticket
On a custom build, even with a headless CMS bolted on, the content model is whatever the developer decided it should be. Want a new section type? Ticket. Want to reorder blocks the schema doesn’t allow? Ticket. Want a new page that doesn’t match an existing template? Ticket.
Your marketing team stops thinking “let me fix that” and starts thinking “is this worth asking for?” Most of the time the answer becomes no, and the site slowly goes stale.
Campaign landing pages sit waiting
Campaigns run on deadlines: a product launch, an event, a seasonal offer, a partner announcement. Marketing needs a page this week, not next sprint.
With no in-house dev, that page waits in a freelancer’s or agency’s queue behind other clients. The campaign either launches late, launches on a hacked-together tool outside the main site, or doesn’t get a page at all.
For one client, we built their landing pages as a kit of components in Webflow. Marketing swaps the copy and visuals and ships. No ticket, no queue, nobody blocking them.
The developer leaves
This one is guaranteed to happen eventually. The freelancer who built it takes a full-time job. The agency rotates the team. The one person who understood the repo moves on.
Now you have a codebase nobody on your side can read, a deploy process someone set up once, and environment variables in someone’s head. The next developer usually wants to “clean it up”, which is a polite word for rebuilding parts of it on your dime.
Code doesn’t sit still
A custom site is a living piece of software. Frameworks release new major versions. Packages get security warnings. A dependency gets deprecated. Hosting providers change pricing or build limits. Node versions go end-of-life.
None of this is visible to the marketing team until something breaks: a build fails, a preview stops working, a deploy hangs. Someone has to keep it updated, whether you’re shipping anything or not.
SEO and forms break quietly
The scary failures aren’t the loud ones. They’re the quiet ones.
- A redirect gets lost in a migration and old links start returning 404s.
- Meta titles or the sitemap stop generating after a refactor.
- A form integration’s API key expires and leads silently stop arriving.
- Someone ships a change and the cookie banner, analytics, or schema disappears.
On a managed platform most of this is a setting a marketer can check. On a custom build it’s code, and you find out when traffic or leads drop.
A client migrating from WordPress to Webflow had three forms running: event sign-ups, an ebook download and a newsletter. One of them had been silently leaking leads for who knows how long. After the move, we set up a Zapier alert that posts every submission and every failure to their Slack. If a form goes quiet, someone on the marketing team notices and tests it that day, without filing a ticket or waiting for a dev.
The retainer trap
Here’s the honest version: a custom site without an in-house team only works if you’re happy paying a monthly maintenance retainer forever. That’s a legitimate choice. Some companies make it knowingly and it’s fine.
The trap is when it’s sold as a one-time project. You pay for the build, the agency leaves, and three months later you’re buying hours every time you need a change. The “one-time” project quietly becomes a retainer, just without the priority, the response times, or the budget line you planned for.
If it’s a one-time project, don’t do it.
Your content team loses ownership
This is the cost nobody puts in the proposal. A marketing site is a marketing team’s tool. When they can’t touch it, they stop owning it. They stop testing headlines, stop adding proof, stop cleaning up old pages. The site becomes “the dev’s thing” and marketing works around it.
The best marketing sites I’ve seen are the ones the content team is slightly obsessed with, because they can change them.
When custom IS the right call
I’m not saying custom is bad. It’s the right call when:
- You have an in-house dev team that already ships every week and treats the site as part of their job.
- The site is product-heavy: logged-in areas, app-like features, heavy integrations with your product or data.
- You’re at real scale: tens of thousands of programmatic pages, complex localisation, or performance needs a visual platform genuinely can’t meet.
- You’ve budgeted for ongoing engineering, on purpose, as a line item and not a surprise.
If that’s you, go build. Your engineers will probably hate a visual editor anyway.
The test
Before you sign off on a custom marketing site, answer these honestly:
- Who on our team can change a headline today without asking anyone?
- Who ships a new landing page in 48 hours if a campaign needs it?
- Who updates dependencies and fixes a failed build next month?
- What happens on the day the developer who built it leaves?
- Have we budgeted a monthly retainer for this, forever?
If the answer to most of these is “we’d have to ask the agency”, you don’t need a custom stack. You need a site your marketing team can run.
Not sure which way to go? Tell us your team size and current stack, and we’ll tell you exactly what we’d do. [Get in touch →]
