How Much Equity to Give a Technical Cofounder After AI MVP

For a technical cofounder joining after AI built your MVP, the working range most builders land on is 10 to 25 percent, vested over time, not handed over at signing. The number moves almost entirely on one variable: how much of what they're joining actually needs to be rebuilt, versus how much they're being asked to own and scale from here. A cofounder inheriting a clean, extensible AI-generated codebase who mostly needs to ship features is worth less equity than one who has to gut the thing and rebuild the data layer before you can take a single paying customer.

That range is lower than the classic 30 to 50 percent a technical cofounder could command when they were the reason the product existed at all. AI changed the leverage. The old logic was simple: no code, no product, so the person who wrote the code owned half the company. When a non-technical founder can generate a working prototype with Claude or Cursor in a weekend, that leverage doesn't disappear, it just moves to whoever is left to make the thing actually work in production. A cofounder split is one of several ways an AI-built product ends up making money for the people involved, and it's worth weighing against the full menu of AI monetization strategies before assuming a cofounder is even the right structure.

Why AI-Built MVPs Change the Equity Math

Equity splits for cofounders have always been a proxy for a harder question: who is taking on the risk and doing the work that makes this thing succeed. Before AI tools got good, "who wrote the code" was a decent proxy for that. Six months of unpaid nights and weekends building a functioning product from nothing was real, scarce, hard-to-replace labor, and equity compensated for it.

An AI-built MVP breaks that proxy in two ways. First, the unpaid-labor story is weaker. If the founder or a freelancer produced a working prototype in a few weeks with heavy AI assistance, there's less banked sweat equity to repay. Second, and more important, what the incoming technical cofounder is actually being asked to do is different. They're rarely being asked to build v1 from a blank editor. They're being asked to look at what exists and answer a much less romantic question: is this thing sound enough to build a company on, or does it need to be torn out and redone.

That second question is where the real negotiation lives. It has three possible answers, and each one points to a different equity number.

Scenario one: the codebase is genuinely usable

The AI-generated MVP has reasonable structure, a real (if imperfect) data model, and no landmines that would blow up at 100 users. The technical cofounder's job is to harden it, add the features that get you to product-market fit, and eventually scale it. This is closer to a senior engineering hire with founder-level commitment and founder-level risk. Expect the low-to-mid end of the range, roughly 10 to 15 percent, vesting over four years.

Scenario two: parts need a real rewrite

Auth is bolted on wrong, the database schema will fall over past a few thousand rows, there's no test coverage and no clear separation between the UI and the business logic. This is common with AI-generated code that was optimized for "looks like it works in a demo" rather than for maintainability. The technical cofounder is doing real architectural work before the company can safely grow, closer to 15 to 22 percent.

Scenario three: it needs to be rebuilt from the ground up

The AI-built version was a prototype in the truest sense: useful for testing the idea with users, not something anyone should build a business on. The technical cofounder is starting close to zero on the code, even if the product concept and early traction are proven. This is functionally closer to the pre-AI cofounder scenario, and equity should reflect that: 20 to 25 percent or more, especially if they're also taking on ongoing CTO-level responsibility for architecture, hiring, and security.

Notice what doesn't move the number much: how the MVP was built. Whether it was AI-assisted, hand-coded by a freelancer, or duct-taped together in a no-code tool matters far less than what condition it's in and what's left to do. Founders who anchor the equity conversation on "but I already built the whole app" are arguing the wrong point. The technical cofounder isn't buying credit for what exists. They're pricing what they're about to be responsible for. If you haven't already stress-tested whether the product itself is worth this conversation, validating the AI product idea before you build a cofounder relationship around it is worth doing first.

What the Technical Cofounder Is Actually Being Asked to Own

Before any number gets discussed, write down what this person is actually signing up for, because "technical cofounder" means wildly different things depending on the company. Get specific on:

• Whether they're doing a full audit and rewrite of the AI-generated code, or extending it as-is

• Whether they own infrastructure, security, and compliance long-term, or just ship features

• Whether they're expected to hire and manage an engineering team eventually

• How much non-technical work they're absorbing too, like product decisions, vendor evaluation, or support

• What happens to the current AI tooling workflow, do they keep using AI-assisted development or move to a more traditional process

A cofounder who's rebuilding the product, owning security, and will eventually hire a team is closer to a full partner and the equity should reflect that regardless of how the first version got made. A cofounder who's mainly extending working AI-generated code and shipping new features is closer to a very early, very trusted senior hire, and the equity, while still real, sits lower. It's also worth naming the alternative out loud: some founders decide the better move is selling the app they built with AI outright rather than giving up a fifth of the company to get it finished.

Dynamic Splitters and Why They Still Work Here

Frameworks like the Slicing Pie model or the Founder's Pie Calculator were built to solve exactly this kind of disagreement: how do you compare contributions that don't look alike, like idea generation, existing traction, and ongoing engineering work. They score each founder across categories such as idea, business plan execution, domain expertise, commitment, and cash or assets contributed, then convert the scores into a percentage split.

These tools are still useful for an AI-built-MVP negotiation, with one adjustment: treat the existing codebase as a much smaller line item than it would have been three years ago. Score it honestly on its real condition (working prototype, tested product, or needs-rewrite) rather than defaulting to "months of engineering time" credit. Score the incoming cofounder's contribution on what they're committing to going forward, not a hypothetical "what would this have cost to build." Run the numbers, then sanity-check the result against the three-scenario range above. If a splitter spits out 45 percent for a cofounder who's mostly adding features to a solid app, something in the inputs is off.

Vesting: The Part Founders Skip and Regret

Whatever percentage you land on, it should vest, full stop. The industry-standard structure is four years with a one-year cliff: nothing vests in year one, then 25 percent vests at the twelve-month mark, with the remainder vesting monthly or quarterly after that. If a cofounder leaves at month four, they leave with nothing. If they leave at month fourteen, they leave with a quarter of their grant, not the whole thing.

Two adjustments matter specifically in the AI-built-MVP situation:

1. Account for the founder's own head start. If the founding, non-technical founder has already put a year of unpaid work into the product, they can reasonably start their own vesting partially credited, rather than resetting both cofounders to zero at the same moment the new person joins.

2. Tie the first milestone to the actual technical question, not just the calendar. If the deal hinges on "can this codebase support real users," consider a short technical-diligence window, often two to four weeks, before the vesting clock and the equity grant are finalized, so neither side is guessing.

This is also the moment to sort out how the founder was compensated, or not, along the way. If cash changed hands before there was a formal company, get it documented, the same way you would when getting paid for AI work before you've formed a company. Loose money arrangements from the pre-cofounder era have a way of resurfacing during a cap table conversation.

Skip vesting because "we trust each other" and you're one bad month away from an ex-cofounder owning a meaningful chunk of a company they haven't touched in a year. This is the single most common regret founders report after a cofounder split, and it's also the easiest one to prevent on paper before it becomes a problem in practice.

Negotiating the Number Without Guessing

A few things make this conversation go better on both sides:

• Get a real technical opinion on the codebase before negotiating, ideally from someone other than the candidate cofounder. "Needs a rewrite" carries a lot of equity weight and shouldn't rest on one person's self-interested read of the code.

• Separate salary from equity explicitly. A technical cofounder taking below-market or no cash for a year is taking real risk that deserves to be priced, even if the code they're inheriting is in decent shape.

• Put a number on what's already been spent, including any paid development, AI tool subscriptions, and contractor time, so the founding contribution isn't just "I had the idea and typed some prompts."

• Write down what triggers a re-negotiation. Roles and contributions shift fast in the first year, and a fixed split with no review point tends to age badly.

Many technical cofounders in this exact situation are moving over from freelance or contract work, where the skills involved in finding a first AI freelance client translate directly into evaluating whether a founder's pitch and existing codebase are worth the equity being offered. Treat the negotiation with the same scrutiny either side would bring to any other deal.

The goal isn't a perfectly "fair" number, because there isn't one. It's a number both people can defend to themselves eighteen months from now, when the early-stage romance has worn off and the cap table is the thing that's left.

Frequently Asked Questions

How much equity should a technical cofounder get if they're joining after the MVP is done?

Most deals land between 10 and 25 percent, vested over roughly four years with a one-year cliff. Where it falls in that range depends mainly on how much of the existing AI-built code needs to be reworked and how much ongoing technical ownership the cofounder is taking on, not on how the MVP happened to get built.

Does it matter that the MVP was built with AI instead of by a developer?

It matters less than founders expect. What matters is the condition of what exists now and what's left to build. An AI-built MVP that's genuinely usable justifies less equity than one that needs a ground-up rewrite, the same way a hand-coded prototype would.

Should a technical cofounder's equity vest immediately since they're taking on real work right away?

No. Immediate, fully-vested equity is one of the most common regrets in cofounder splits. Standard practice is a four-year vesting schedule with a one-year cliff, even for cofounders joining with clear, committed roles from day one.

What if the technical cofounder thinks the AI-built code is unusable and the founder disagrees?

Get a third-party technical opinion before finalizing the split. This disagreement is common and it's exactly the kind of thing that should be resolved with an outside read on the codebase, not settled by whoever argues harder.

Is a 50/50 split ever right for a cofounder joining after an AI-built MVP already exists?

It's uncommon, since one person already has a head start on the idea, product direction, and often early users or revenue. A 50/50 split can still make sense if the incoming cofounder is fully rebuilding the product, taking on equal financial risk, and stepping into an equal leadership role going forward, but it should be a deliberate choice, not a default.