You Didn't Choose One Market. You Could Only Afford One.

You keep almost-building a second product for a second audience, and keep deciding you can't afford it. Here's the part of that calculation that quietly changed, and the part that didn't.

Open the settings page of any product that's been alive for three years and count the toggles. Then count how many of them are sitting there because one group of customers needed something the rest of your users will never touch.

That second number is a list of markets you entered without ever admitting you'd entered them. You didn't get a second product out of the deal. You got a longer settings page, a vaguer empty state, and a support inbox with two different kinds of confusion in it.

The arrangement you actually wanted was one backend and multiple products, each one shaped for the people it's actually for. You've probably even sketched it on the back of something. And then you didn't build it, because the second product was the expensive part, and everyone you respect was telling you the same thing anyway.

Focus. Pick a lane. Narrow the ICP (ideal customer profile). Say no.

The Advice Had a Price Tag On It

You're one person, or maybe three. Your product does more than it did last year, and every single addition was defensible at the time, which is exactly what makes this situation so hard to see from the inside. Nothing went wrong, you just kept saying yes to reasonable things, until one day you noticed you were explaining your own product with a sentence that starts "so it depends who you are."

Meanwhile there's that other audience you keep circling. Different vocabulary, different workflow, different willingness to pay, and every time you drift toward them the same advice arrives dressed up as a virtue: discipline, maturity, the sign that you've finally grown up as a founder.

I want to ask a question about focus that doesn't get asked much. Not whether it was true, because it was. The question is what made it true.

The answer turns out to be a lot less inspiring than the advice. Serving that second audience properly meant building a second surface, and a surface is never just screens: it's design, build, tests, documentation, onboarding copy, support load, and maintenance for as long as the product stays alive. Call it a designer and a frontend engineer for a few weeks, followed by a tax you pay forever, and then multiply the whole thing by every audience you were ever tempted by.

That multiplication is the entire reason "pick your market" was a decision rather than a preference. The advice was downstream of a price, and when a price stays high for long enough, it stops looking like a price and starts looking like wisdom.

I owned a courier service for twenty years, and I ran this exact arrangement there, in vans, decades before anyone could ask a model to build them a frontend. It started as one service for the top of the market, the clients who buy a promise rather than a price. Then I built a second one for the tier below them.

Same couriers. Same dispatch, same in-house software, same logistics, same everything that actually moved a package from one address to another. One company, one engine, two names on the paperwork.

Above that line they shared almost nothing. Different name, different pricing, different sales conversation, different promise about what happens when a delivery goes wrong, different tone at eight in the morning when someone calls about a package that should have arrived by now.

The question was never whether one operation could carry two products. That has worked for as long as businesses have existed, with paper and phones and no diagram anywhere. What the price controlled was how many you could carry at once.

Two is where it stopped. There was a third tier and I could see it perfectly well, but that second surface was made of people, staff trained into a different voice and materials written twice, and a third brand meant a third of all of that. There was no third of me.

But…

Look at what that surface was made of, because it decides everything that follows. In logistics, the product layer is human. People trained into a voice, people scheduled, people answering a phone at eight in the morning. The human half of a price has never dropped much in my lifetime.

In software, the product layer is mostly screens, copy, tests, and documentation.

That's the half that moved.

One backend can support several products in software the same way one fleet did in vans. The engine holds the capabilities, the identity, and the state, while each product above it owns its own workflow, vocabulary, defaults, and pricing. That works for exactly as long as every piece of shared behavior has one implementation underneath, and it starts coming apart the moment a surface becomes the only place some rule lives.

Notice Who Headless Actually Paid Off For

None of the architecture here is new. API-driven headless systems have been shipping since the early 2000s, and by 2016 Forrester was writing about the rise of the headless CMS as an established category rather than a curiosity.¹ Separating the interface from the system underneath is settled, taught, tooled, and frankly a bit boring.

The part that got skipped is the economics of who it actually paid off for. Headless worked beautifully for platforms, for larger teams, and above all for vendors whose customers built the expensive last mile on their own dime. A headless CMS company doesn't build your website; it sells you an engine and lets the market absorb the cost of every surface, which is a wonderful business to be in when you're the one selling engines.

The version almost nobody could afford is the one where the same builder owns both sides: one engine, several thin products above it, each shaped for a different segment, all shipped by one person or a team of three. That was never an architectural problem. It was a budget.

What AI collapsed is the build cost of the surface specifically, and I'd insist on that word "specifically." Not the thinking, not the judgment about what deserves to exist, and not the taste. Just the surface: the screens, the forms, the empty states, the responsive behavior, the test scaffolding, the documentation nobody ever wanted to write.

The tenth surface now costs something close to what the second one costs. That's my read from building this way, not a measured curve, and I'd be suspicious of anyone who hands you one. It's still the right number to argue about, because it's the number that forced the choice in the first place.

Which means feature breadth stops necessarily producing interface breadth, and that's a stranger consequence than it first sounds. Adding capability used to push you toward one of two bad destinations: either a single interface that got harder to use with every release, or separate products each dragging around its own copy of the engine and drifting a little further apart every quarter. Everybody accepted that trade, because the third option cost far too much to seriously consider.

One increasingly capable system underneath. Many increasingly focused products above it.

The Engine Is the Last Thing You Should Build

Now the part that makes this strategy fail, because if you take only the good news you'll build something you can't hold onto.

Here's the objection that should worry you, in its strongest form:

Ten surfaces is ten places the same rule can be wrong. You didn't read most of that code, and you won't learn which copy drifted from a test, you'll learn it from a customer who got charged twice. Now multiply that by every engine change for four years. Building was never what killed small teams, and you've just made the part that does more numerous.

That's right about the direction. Generating a surface is a one-time cost, while keeping that surface honest against an engine that keeps changing is a forever cost, and forever costs are what quietly killed multi-surface strategies long before any of this was AI-assisted. That second number moved too. It just moved considerably less.

The shape of the problem is easy enough to see once you say it out loud. The tenth surface is cheap to build, and from that day forward every single change to the engine becomes ten separate opportunities for something to drift out of sync behind your back. Cheap to create, expensive to keep true, and the second cost shows up every week for years.

Where the objection stops being right is the assumption that each surface stays heavy. AI helps on this side too, just far less dramatically. A thin surface carries less bespoke code that can rot, and a surface generated from a canonical description of what the engine does can be regenerated against a changed engine for very little. That genuinely improves the arithmetic without making the problem disappear, and anyone selling you the version where it disappears is selling you the fun half.

And here's the part of the objection I can't answer. Whether your surfaces actually stay thin is discipline rather than architecture, and nobody, me included, can promise you'll hold it for four years running. If you won't, the objection wins outright and you should be running one product. This strategy is only ever as good as the smallest amount of attention you're still willing to pay it in year three.

Which is why the worst possible move at this point is to go and build the engine.

You've just read an argument for multiple products on one spine, so the temptation is to open a terminal and start designing the shared infrastructure you'll obviously need someday. Don't. You don't know the future, you're currently thinking about your first product, and anything you build for the second one right now is a forecast wearing the costume of infrastructure.

Build the first product. Just the product, end to end, with its logic sitting wherever it's convenient, and no shared anything.

When the second one arrives, resist again. Build it standalone as well, exactly the way you built the first, and let yourself feel the duplication. That wince is information: it tells you which parts genuinely repeat and which parts only looked like they would, and there is no way to get that information by predicting it in advance.

Then extract. Sometimes on the second when the overlap is undeniable, more often on the third, once you've seen the same behavior three times and finally know what it actually is rather than what you assumed it would be.

Programmers already named this, decades before any of it was AI-assisted. Martin Fowler's rule of three, which he credits to Don Roberts: the first time you do something you just do it, the second time you wince at the duplication and do it anyway, the third time you refactor.² The engine is what you extract at the end of that sequence, and an engine built before you had two real products is a guess with a schema attached.

There's a problem with borrowing that rule into this era, though, and it comes directly from the thing that made the strategy possible. The wince was doing your thinking for you. Duplication used to hurt to produce, and the hurt was the measurement: three implementations was roughly where the pain outgrew the uncertainty.

Generate the second surface in a day and the third in an afternoon, and you may never feel a thing. The duplication is still there, doing the same damage to your ability to change anything, except now nothing is telling you about it.

You go looking on purpose instead. Not for repeated code, which is cheap and mostly harmless, but for repeated decisions: the same rule about what counts as expired, the same definition of who's allowed to do what, written out twice in two places by two sessions that never spoke to each other. A spine with no second limb is just an expensive way to have one product.

Nobody Should Have to See the Complexity That Exists for Everyone Else

The first thing this arrangement buys back is simplicity, without asking you to surrender any capability in exchange for it. You keep the capabilities down in the engine and expose only what's relevant in each surface, which means no user ever has to confront the complexity that exists for somebody else's job.

The tools for doing that are ordinary and you already know most of them: profiles, guided onboarding, progressive disclosure, command bars, usage history. Each one makes a given surface simpler while leaving the full system reachable underneath it.

Most products stop one step too early here, though, and the step they skip is the interesting one. Watch what a profile actually is. It's a guess, the best approximation available before there's any real usage to read, which means that when you ask someone three questions at signup you've shaped their entire product around who they said they were on a Tuesday morning, in a hurry, while still deciding whether to trust you at all.

What makes the arrangement worth the trouble is what you do after that guess. Once the system can see how someone genuinely works, the surface is free to move with them: promote the capabilities they keep reaching for, quietly retire the ones they've never once opened, introduce complexity at the moment it becomes useful instead of at the moment they arrive.

And there's a tool on that list that didn't used to be there, which is the one that makes this practical rather than aspirational. Rule-based adaptation only ever fires on conditions somebody thought to write down in advance, which is why most products ship three static personas and stop. A model watching actual usage against the full set of capabilities sitting in the engine can propose the rearrangement itself: surface the capability this person clearly needs and has never found, fold away the three they abandoned in week one, suggest the workflow that people in their situation keep converging on.

Propose is the word that matters there. A surface that reshuffles itself overnight leaves people hunting for what moved. A surface that says you've done this the long way eleven times, want the shortcut? hands them the same change and lets them keep it. Same evidence, same rearrangement, except now somebody chose it.

That's the same guess the onboarding questionnaire was making, except made continuously, from evidence instead of a form. The correction loop stops being a settings screen they have to go hunting for and becomes part of the product itself.

A surface that can't correct its own first guess about you is just a longer settings page with better manners.

One Negative, Many Prints

Photographers have been running this exact arrangement for more than a century, and they worked out its failure mode long before any of us got here.

Ansel Adams had the line for it: the negative is the score, and the print is the performance.³ The negative holds everything the scene gave you, all of it, whether or not any particular print has use for it. Each print is a separate set of decisions about what to show, at what size, on what paper, for whom, which is why a gallery print and a quick work print can come off the same negative and behave like entirely different objects.

Prints are disposable in a way that negatives never are. Burn a print, make another one, crop it differently, and you've lost nothing that mattered.

Now the part that should worry you. Retouch a dust spot on the print instead of on the negative and the next print still has the dust, so do that ten times across ten prints and you end up with ten prints each carrying its own private correction and one negative that's quietly, permanently wrong.

Nobody decided to do that. Everybody just fixed the thing in front of them, because the thing in front of them was always faster to fix.

That mistake has a name in our world: business logic drifting upward into the surface. Photographers were making it in a darkroom long before we made it in code.

Surfaces Can Compose Capabilities. They Can't Own Them.

The instinct isn't new in software either, which should reassure you that the boundary is a real thing and not something I'm inventing. Sam Newman's backends-for-frontends pattern carries the identical warning: the client-specific layer aggregates, filters, and reshapes, and it does not hold business logic, precisely because logic living there can never be shared with any other client.⁴ Academia got there earlier still, under the name software product line engineering, where the shared part is called core assets and variation is something you plan rather than discover in a panic.⁵

The rule underneath all of it is short. Anything two products need as the same underlying behavior belongs below the line, and anything that exists because one audience thinks, works, or buys differently belongs above it.

When I'm genuinely unsure where a piece of behavior goes, three questions settle it. Call it the Placement Test.

1. Would a second product need this exact underlying behavior? If yes, it goes below the line, even when only one product needs it today.
2. Does this exist because an audience thinks, works, or buys differently? If yes, it stays up in the product, and it stays there even when it starts looking like duplication.
3. Could you delete this entire surface tonight and lose nothing but the surface? If the answer is no, something has already crossed the line while you weren't watching.

The third one is the question that catches people, because it's the only one of the three you can't answer optimistically.

What the test is protecting is a surface's freedom to be genuinely different. A surface should be able to rename a capability, hide it, fuse it together with three others, give it completely different defaults, or drop it into a workflow the other products don't even have, all while the capability itself keeps exactly one canonical implementation underneath. That freedom is what makes surfaces deliberately disposable, which is the entire reason it's worth building them cheaply in the first place.

Two things break this, and only one of them ever gets warned about. The famous one is drift: logic creeps upward because putting it there is faster today, and it keeps being faster today, until each surface has quietly forked the engine and you're maintaining four negatives instead of one.

The quieter failure runs in the opposite direction, and I suspect it does more damage to small teams because it feels like good engineering the entire time it's happening. You pull genuine product differences downward because they look like duplication, when two surfaces solving the same problem differently for two audiences isn't a mess waiting to be cleaned up at all. Chasing DRY across products will cost you more than the duplication ever did. What must never duplicate is the underlying truth, and the fact that some things do duplicate between products is close to the whole reason they're separate products.

Four Products That Don't Look Like Siblings

Treat the interface as the product and the engine as infrastructure, and something changes about what you're permitted to build. The same engine can carry products that make entirely different promises: a different answer to who this is for, what it costs, and what it claims to do. The workflows, terminology, defaults, positioning, and pricing are how each promise gets kept. The promise is the thing that makes it a separate product at all.

This is worth separating carefully from the thing it superficially resembles. A pricing page with three columns is one product wearing three hats, and every customer can see all three hats at once, which is exactly why they sit there comparing them. What I'm describing is different in kind: separate products off one spine, where a customer of one has no particular reason to know the others exist.

There's a closer neighbor than the pricing page, and it's the one that will fool you, because it looks like exactly what I'm describing. A product with optional modules. Stripe is the honest example: one money-moving engine under Billing, Checkout, Connect, Invoicing, and a beautiful piece of engineering. It is also not this. Every one of those pieces is sold to the same buyer, under the same name, from the same dashboard built to make you discover the next one. That's optionality, composed by one customer under one promise. The give-away is simple: if a single buyer could see all of it at once and happily pick what they want off the menu, you built one product with good optionality, not several products. The line isn't in the engine, and it isn't even in the features. It's whether there's one promise or several.

It resembles one more thing, and that one comes from the adaptation I was arguing for a few sections ago. If a surface keeps reshaping itself around the individual, you eventually approach a product per person, and it's fair to ask why you'd bother naming four of them at all.

Because there's a line inside the surface too, and it hides while you're calling the whole thing "the interface." Adaptation owns the arrangement: what gets promoted, what gets folded away, what somebody already inside sees first on a Thursday in month four. It has never once owned the promise: who this is for, what it costs, what it claims to do for the person still standing outside deciding whether to come in.

Four products means four promises. A thousand personalised arrangements sitting underneath them doesn't change that number.

Make it concrete. This one's invented, so take the specifics as illustration, not a recommendation. Say the engine verifies a person and pulls the records that matter: identity, history, a report at the end. One product screens tenants for small landlords. Another vets caregivers for parents hiring a sitter. Same engine underneath, doing the same work both times. But no landlord wants a product that talks about babysitters, no parent wants one that talks about evictions, the prices aren't in the same universe, and the two buyers will never once stand in a room comparing them. One positioning could not hold both without repelling one of them. That's what separates this from a menu of features: not that the products do different things, but that a single honest promise can't reach both buyers.

This is exactly what the two courier brands were. Not premium and economy tiers on one rate card, the kind every customer sees at once and chooses between. Two names, two promises, two sets of clients who mostly never learned they shared a fleet. I built the second brand precisely because one pitch could not win both kinds of client. That was the whole reason there were two.

You build the expensive part once, and then you get to enter markets you previously had to choose between.

I should be careful with the word "boundary," though, because it implies more precision than actually exists. The line between engine and interface was never a specification you could write down and then enforce. It's a discipline, held continuously, in both directions, by somebody paying attention.

MVC (model, view, controller) never settled exactly where domain logic ends and view logic begins, developers are still arguing about it in public more than forty years later,⁶ and the pattern earned its keep anyway. This one will too, on the same terms.

The Surface Got Cheap. The Audience Didn't.

Go back and look at what actually moved, because I've been letting one word carry too much. Building a product and entering a market are different activities, and only one of them got cheaper.

Four products is four positioning stories, four sets of first customers who have to be found one at a time, four inboxes with real people in them, four separate ways of discovering you were wrong about something. None of that was ever the part a designer and a frontend engineer were doing for you.

The second courier brand didn't get expensive at the logo. It got expensive in month four, when somebody still had to answer that phone in the right voice on a Tuesday, and then again on the Tuesday after that. That brand's surface was made of people, which is exactly why its price never fell. Yours is made of the part that did.

So the focus advice doesn't die here. It relocates.

What used to be true is that you couldn't afford to build for two markets at once. What's still true is that you can't pay attention to two markets at once, and attention was always the scarcer half of that pair. The difference is that the two costs used to arrive fused together, as a single decision you made once and then lived inside for years. Now they come apart, and you get to pay them on separate schedules.

Which turns a choice into a sequence. Ship one product into one market with everything you have, let the engine appear underneath it when a second real product finally shows you what repeats, and don't launch that second surface until you have the attention to sell it. A surface with no market behind it is pure forever cost with no revenue attached to argue for it.

The people who get hurt by this will be the ones who read "the tenth surface is cheap" and hear "launch ten things." The build was always the cheap part of a launch. We just couldn't see that while it was also the impossible part.

So go back to that settings page.

Some of those toggles are capabilities that belong down in the engine, where every future product can reach them. A few of them are products you almost started and then talked yourself out of. And the reason you could never tell which was which is that for most of your career they were the same thing: a decision you couldn't afford to make twice.

A recreation, not the original. The arrangement is twenty years old; the drawing isn't.

Rabbit Hole

More on this subject

• Prioritize Feature Requests Before You Know Your Customer: Use reversible feature requests to discover which customer segment deserves its own product.
• What Survives When Anyone Can Build Anything: See which costs remain after building gets cheap, and where the durable business moves.

See this concept in another subject

• You Can't Afford Most Books: Follow the same hidden-cost mistake from product surfaces into unread books and attention.