When your marketing site and your product need the same codebase

The signal that a site builder isn't enough any more

It's rarely a design complaint. It's that your public pages and your logged-in product have started needing to know about each other. A pricing page that shows something different to an existing customer. An app screen that has to be indexed. A signup flow that spans both.

When that's true, running two systems means maintaining two copies of your components, your brand and your copy by hand. It works for a while. It stops working around the point where a one-sentence change needs two people and a calendar invite.

The opposite mistake is just as common and costs more. A team hears that the site and the product should share a codebase, merges them, and finds out afterwards that the only thing the two halves ever shared was a logo. So be precise about where the overlap is before anyone spends money on it.

Five checks that tell you which side of the line you're on

Run these in order and write the answers down. None of them needs an engineer. You're not looking for a score, you're looking for whether the same handful of pages keeps turning up in more than one answer, because that overlap is the only thing one codebase genuinely buys you.

Do it against the site and the product you have today rather than the ones in next year's roadmap. The overlap you can point at right now is the part that's real, and it's the part a build gets scoped against.

Checks one and two decide it between them. If both come back empty, you don't have a boundary problem and this stack isn't your answer. The other three tell you what the split costs you while you leave it alone.

1. 1. Count the pages that change depending on who's looking

   Go through your public URLs and mark every one that would show something different to a signed-in customer than to a stranger. Pricing, the plan comparison, anything with a start-free button, anything that hides a feature behind a tier. Then count them. One or two is a narrow problem with narrow fixes. A dozen means your public site is already half a product and is being maintained as though it isn't.

2. 2. Mark which of those also have to be found in search

   Now cross-reference. Of the pages you just marked, which ones do you need ranking for a search term? Documentation, templates, a public directory, a shared report, anything a stranger might land on before they have an account. Pages that need both a signed-in state and a search ranking are the specific thing two separate systems handle badly, and they're the honest argument for one codebase.

3. 3. Follow one person from stranger to signed in and count the handoffs

   Trace the whole path yourself, from a search result or an ad through to actually using the thing. Count every point where the domain changes, the design visibly changes, or somebody has to type the same information twice. Each of those is a seam, and seams are where people quietly leave. Two is normal. Six means the split is costing you customers rather than just irritating your team.

4. 4. List what exists twice today, and name who updates each copy

   Navigation, footer, buttons, brand colours, plan names, the legal wording at the bottom of the pricing page. Write each one down with the name of the person who changes it on the site next to the name of the person who changes it in the product. Where those are two different names, you've found the recurring cost. Where it's the same overworked name, you've found the risk.

5. 5. Ask what has to stay up while the product is down

   Get this answered before anyone merges anything. If your marketing pages, your pricing and your status updates have to keep serving while the application is broken or halfway through a deploy, say so now. One codebase can do that perfectly well, but only if it was built to. It's cheap to design for in week one and expensive to discover during an incident.

One codebase, and what it commits you to

Next.js puts the marketing pages and the application in the same project, with the same components and one deploy. That's the real reason to pick it.

The commitment is that you now own software. Somebody has to keep dependencies current, respond when a build breaks, and hold the context for why things were built the way they were. That's an ongoing cost, and it belongs in the decision rather than in a discovery six months later.

What that looked like on a real build

The product work we've published includes a multi-surface build for a market-research platform: a mobile app, a web counterpart and an internal admin dashboard, hosted on Vercel. That shape is the common one, and the interesting decisions weren't inside any one surface. They were at the seams between them.

Three surfaces over one codebase is the part worth naming, because one codebase is what lets a change to a form control land everywhere at once instead of being copied three times. The product also sat next to the system the business already ran its commercial relationships in, and anything in that position has to settle once which side holds which record rather than discovering the answer during a support call.

What that build doesn't contain is a public marketing surface, so it isn't evidence for the marketing-plus-product case this page argues. Take it for what it shows: several surfaces over one codebase behaves the way you'd hope, and the decisions worth arguing about live between the surfaces rather than inside any one of them.

Who owns it in year two

This is the question that decides whether the stack was the right call, and it's almost never in the proposal. A codebase nobody is accountable for degrades quietly. Nothing breaks on day one. Then a dependency goes out of support, the build stops working on a new machine, and the person who held it all in their head has moved on.

The arrangement matters more than the handover document. Either somebody in-house can pick the codebase up, or you have a standing agreement with whoever built it, and that gets decided while there's still budget for it rather than during the first outage. Many of our engagements run a year or more for exactly that reason, and we'd rather say that out loud than let a document imply the problem is solved.

The cheapest version of ownership is a rhythm rather than an emergency. Dependencies get updated on a schedule. Build failures get read by somebody whose job it is to read them. None of that is interesting, and all of it is what separates a codebase you own from one you're hostage to.

What's locked in, and what isn't

Next.js itself is open source and runs on plenty of hosts, including your own hardware. The framework isn't the lock-in. The host-specific features are: the ones that make deployment, caching, image handling and edge behaviour effortless and have no direct equivalent elsewhere.

That trade is usually worth making. It's worth making knowingly, because what moving would cost later is a function of exactly which of those features the build ended up leaning on.

It helps to know what moving actually involves, because the honest answer has two very different halves. Running one Next.js server yourself is well-trodden ground. The framework publishes a self-hosting guide, image handling works with no configuration on a standard server, and the main piece of advice is to put a reverse proxy in front of it rather than exposing it straight to the internet.

Running several servers is where the work is. Next.js stores its page cache on the local filesystem of each server instance by default, so more than one instance means writing a shared cache handler or serving some visitors stale pages. Every instance also has to share one encryption key for server functions, and rolling deploys need a deployment identifier so a browser holding the old version doesn't ask for files that are gone. None of that is hard. All of it is somebody's job, and it's the part an estimate leaves out.

When Next.js and Vercel are the wrong choice

When it's a marketing site and nothing else. A dozen pages, no accounts, no product surface, and a non-technical team who need to edit it. This stack makes that worse, not better, because you've added an engineering dependency to a problem that didn't have one.

When nobody will own the code. With no in-house engineer and no ongoing partner, a custom codebase is a liability on a delay. A managed platform is the honest answer even though it's the less impressive one to put in a proposal.

When the reason given is that the framework is popular. Popularity is a hiring argument. It isn't an architecture argument, and it's worth making whoever raised it say which of the two they mean.

A managed platform, your own servers, or a site builder

Three places this can run, and they fail in different directions. A managed application platform takes deploying, scaling and caching off your plate and bills you against the traffic and compute you use. Your own servers give you a bill you already understand and an operations job you now have to staff. A site builder isn't a place to run an application at all, and it belongs on the list because for plenty of teams it's still the right answer.

Our recommendation, when checks one and two come back with real overlap: the managed platform. Not because it's technically superior, but because the way these projects actually fail is that nobody is operating the thing in year two, and it's the only one of the three that shrinks that job rather than creating it. Move off it when you have people whose job is running infrastructure, or a rule about where your servers have to physically sit.