When one product becomes two: how to split your AI-built app without starting over
Your AI-built app started as one product. Then you realized it was secretly two. Here's how to split an AI app cleanly — without abandoning what you already shipped.
You started with one idea. You described it to your AI app builder, watched it generate the screens, edited the rough edges, and shipped something real. People started using it. And then, slowly at first, a pattern showed up in the feedback: half your users wanted one thing, the other half wanted something else. They weren’t fighting over the same feature. They were asking for two different products.
This is the moment when a lot of founders panic and start a second project from scratch. They shouldn’t. There’s a cleaner way to split an AI app when your one product turns out to be two — and it usually keeps most of what you’ve already built. This post is about how to recognize the split, when to do it, and the three shapes the split tends to take.
How you find out you have two products
The signal almost never looks like a feature request. It looks like friction.
A productivity app I watched go through this had a clear story. It was sold as a “personal planner.” Users started showing up in two flavors. One group used it to schedule their own week and treated it like a private notebook. The other group ran small teams and wanted to assign things to other people. They were both happy enough to keep using the same product, but every release pleased one group and annoyed the other. The team thought they had a feature prioritization problem. They actually had a brand problem. They had a personal app and a team app sharing one codebase, one homepage, and one pricing page.
You will know you’ve crossed that line when one of these starts being true:
- Your landing page has to bury its actual pitch behind generic language because two audiences won’t believe the same words.
- Every new feature has a “but for the other kind of user it should work differently” caveat.
- Your support replies start branching: “if you’re using it for yourself…” vs. “if you’re managing a team…”
- A non-trivial number of users keep two separate accounts to keep the two modes separate.
If you’re seeing two or more of those, you don’t have a feature problem. You have a product split waiting to happen.
The three shapes of a split
You don’t have to pick a shape on day one. You can usually try the lightest one first and escalate. But it’s useful to know the menu before you start describing it to your AI builder, because the words you use will shape what gets generated.
Shape 1: One app, two doors
The lightest version. You keep one codebase. You add a question on first run — “Are you here for yourself or for a team?” — and use the answer to show a different set of pages and a different navigation. Same data store. Same login. Same billing. Just a different surface.
Most AI app builders handle this well if you describe it as a “two-mode app.” The thing to watch is that the two modes shouldn’t share screens with conditional shows-and-hides everywhere. That ends up looking like one cluttered app pretending to be two. Tell the builder the two doors are separate — different home pages, different settings pages, different empty states. The few screens that do overlap (account settings, billing) can be shared.
When this works: when the two audiences want different framing but the same underlying objects. The planner-versus-team example fits here. The thing you’re scheduling is still a task; only the rules around assigning, sharing, and notifying change.
When this doesn’t work: when the two audiences expect different objects entirely. A “client portal” and “internal admin tool” have almost no overlap, even if they look like they’re about the same business.
Shape 2: Two apps, one back end
The middle shape. You split the front of the product into two separate apps — two URLs, two landing pages, two onboarding flows, two pricing tables — but they both read from the same database underneath. A customer can have an account on both. An admin can see data from both.
This is what we recently did at the company that runs this blog. We had one app trying to serve two audiences: engineers evaluating our agent platform, and builders using our AI app builder. Same backend, same auth, same database — but the front end had grown two heads, and the messaging was confused. We split it into two front-end apps, one for each audience. Backend stayed exactly the same.
This shape is the right answer when:
- The two audiences buy for different reasons.
- They’d be confused or turned off by the other audience’s marketing copy.
- The data they care about is mostly the same shape, but framed differently.
- You don’t want to maintain two databases or two billing setups.
Tell your AI builder you want a “second front-end app that shares the existing API.” Most modern AI builders can scaffold a sibling project and point it at your existing backend. The trap to avoid: copy-pasting the first app’s components verbatim and then editing both copies forever. Ask the builder to extract the shared parts (auth screens, common form widgets) into a small library that both apps use. You’ll save yourself months of duplicate fixes later.
Shape 3: Two apps, two back ends
The heaviest split. You actually have two products. They don’t share data, they don’t share users, and they shouldn’t share a roadmap. The right move is to fully separate them: separate codebases, separate databases, separate domains.
This is the right move less often than people think. It’s tempting because it feels clean. The reality is that two completely separate apps means two of everything to keep running — two deploy pipelines, two on-call rotations, two billing integrations, two help docs. Don’t reach for this shape unless the products genuinely don’t overlap. A good test: if a user of product A would never be a user of product B, you probably do need Shape 3. If most of your users could plausibly want both, you almost certainly want Shape 2.
When you do this with an AI builder, the easiest move is to copy your existing project as a starting point for the second one, then ask the builder to remove the features that don’t belong and add the ones that do. Don’t start the second project from a blank canvas. You already learned a lot building the first one, and the AI builder will pick up that context if you let it.
What to do before you split anything
Before you describe the split to your AI builder, do three small things. They’re worth more than they sound.
First, write the new home page for each side. Two paragraphs each. The pitch, the audience, the one thing you want them to do. If you can’t write two different home pages, you don’t actually have two products yet — you just have two segments of one product, and you should solve that with messaging, not architecture.
Second, list which screens are shared and which aren’t. Be honest. “Login is shared. Onboarding is different. Dashboard is different. Settings are mostly shared. Billing is shared.” This list becomes the brief you hand to the AI builder. It saves a lot of back-and-forth.
Third, decide what’s the same underneath. Same users? Same data? Same payments? Each “yes” pulls you toward Shape 1 or 2. Each “no” pulls you toward Shape 3. There’s no right answer — only the answer that matches how your product actually works.
What changes after the split
Two things get easier and one thing gets harder.
Marketing gets easier. Each app gets its own clear pitch. Each landing page can speak to one audience without hedging. Your conversion rate usually goes up on at least one side, sometimes both.
Onboarding gets easier. A first-time user lands on a page that’s about them, not a page that’s trying to be about everyone.
What gets harder is keeping the shared parts in sync. If you fix a bug in the login flow, you want it fixed in both apps. If you change how the billing screen looks, you want both apps to reflect it. The discipline you need — and this is true whether you’re vibe-coding with an AI builder or building with a team of human developers — is to keep the shared parts genuinely shared. Don’t duplicate. Don’t fork. Either extract the shared screen into a small library both apps use, or accept that you have two truly separate apps and own that.
A small question to end on
If you ran your current app’s pitch past five strangers and they each described it differently — but in two distinct buckets — you’re probably already living with the split. The only question is whether you keep paying the tax of one confused product, or do the work of being honest about being two.
You don’t have to decide today. But the next time your AI app builder asks “what should I build next?”, consider that the most useful answer might not be a new feature. It might be a new front door.
If this resonated, you might also like our earlier piece on building for your team vs building for customers — same flavor of decision, one step earlier in your product’s life.