Technical cofounder equity after the MVP: how to score it

Why the split gets hard after the MVP

Once the MVP exists, the usual cofounder math stops working. You are not splitting an idea anymore. You are splitting a product, real momentum, and the risk of carrying it forward.

Past work matters now. If one founder spent a year building the codebase, fixing late night bugs, and getting the first users in, that work has weight. A generic split often treats that history like background noise, but it is part of the company you have today.

Future work matters just as much. The next year can be heavier than the last one. Shipping an MVP is one thing. Turning it into a stable product with releases, hiring, support, and customer trust is another. The person who owns that load can take on more risk than the cap table shows.

Things get messy fast when one founder carries several jobs at once. They may still own most of the code, make architecture calls, review hires, and jump in every time production breaks. That is very different from joining a company where the product already runs smoothly and the team can execute without you.

A copied split hides those differences. Founders often grab a familiar number like 50/50 or 60/40 because it feels fair and avoids an awkward talk. On paper, it looks clean. A few months later, it can feel badly off. One founder may handle investor meetings and sales. Another may hold the whole product together. Both matter, but not always in the same way or at the same time.

That is why the split gets harder after the MVP. You are pricing work that already happened, responsibility that still sits with one person, and uncertainty about what breaks next. Skip that nuance and the deal will likely age badly.

What you are dividing now

Once the MVP exists, equity stops being a reward for who typed the first lines of code. You are dividing future load, future risk, and the parts of the company that still depend on one person knowing how everything works.

That matters because an MVP is usually fragile. One founder may know why the payment flow works, where the ugly shortcuts live, which parts will break under real traffic, and which features are still too risky to promise. That knowledge does not sit neatly in a repo. It lives in decisions, tradeoffs, and memory.

A fair discussion should include the codebase, but it should not stop there. After launch, the technical side often means five jobs at once: owning the existing system, making roadmap calls when speed and debt collide, hiring and managing engineers, answering investor diligence questions, and carrying production responsibility when something fails.

Code ownership is the obvious part. If one person can rebuild the system, explain the architecture, and fix the hardest bugs fast, that lowers company risk. Two founders may both "understand the product," but only one may know how to ship the next version without breaking the current one.

Roadmap control matters too. A technical founder often decides whether a feature takes two weeks or two months, whether to patch or rebuild, and when debt becomes expensive. Those calls shape burn, hiring, and fundraising.

Team load is easy to miss. If the company needs to hire three engineers, someone has to write the scorecard, review code, onboard people, and clean up mistakes. That work is slow, human, and mostly invisible. It still counts.

Fundraising changes the picture as well. Investors rarely back a product with no technical owner in the room. If the technical founder joins calls, answers diligence questions, explains security and scale, and gives investors confidence that the team can execute, that is founder work.

Then there is production responsibility. When the app goes down on a Sunday night, who gets the alert and fixes it? If one founder owns uptime, incidents, releases, and the risk of customer pain, that has real weight. This is one place where founders often underprice the person who keeps the product alive after launch.

Score code ownership and product risk

When founders argue about the split, they usually start with visible output. That is a mistake. A polished feature matters less than knowing how the whole product stays alive when something breaks on a Sunday night.

Start with a simple question: who can ship a fix without help? If only one founder can trace a bug through the backend, database, auth, payments, and deployment setup, that person holds more than coding duties. They hold continuity.

Full system understanding matters more after the MVP than many teams admit. One person may have built most of the user facing work, while another knows the hidden parts that keep the product stable: infrastructure, logging, backups, access control, release process, and ugly edge cases nobody wrote down. That second kind of ownership is easy to miss and expensive to replace.

Product risk also includes uptime and security. If one founder carries the pager, reviews risky changes, handles incidents, and knows where customer data could leak, count that load directly. Investors rarely see it. Users only notice it when it fails.

A few blunt questions help:

• Who can fix a production issue alone?
• Who understands the full system, not just one layer?
• Who owns security, deployment, and failure recovery?
• If that person leaves, how much would the team need to rewrite?

Rewrite risk is often the biggest blind spot. If the team would spend four months rebuilding core services because nobody else understands them, that is company risk. Score it honestly.

Also keep visible features separate from hard maintenance. Shipping a new dashboard is easy to celebrate. Keeping migrations safe, taming outages, and making sure releases do not break old customers protects revenue. If one founder carries that weight, the split should reflect it.

Add the hiring and team load

Once a second engineer joins, the technical founder stops being only the person who ships code. They start spending hours on work that keeps the team moving. Ignore that time and your math will be off.

Hiring alone can eat a surprising part of the week. Someone writes job briefs, screens candidates, runs interviews, checks take home work, sells the role, and closes the offer. Then they onboard the new hire, answer the same setup questions, review early pull requests, and fix gaps before they turn into habits.

That work is easy to dismiss because it does not look like product output. It still matters. A founder who can hire two solid engineers faster than the company could on its own changes the pace of the business.

Count recurring team load in plain hours, not vague credit. Look at interview time, follow up, onboarding, code reviews, architecture calls, time spent unblocking developers, release prep, testing rules, and bug triage. This work repeats every week, even when nobody celebrates it.

The unblocking part gets missed most often. If one founder spends half a day each week fixing access, clarifying specs, calming a stuck developer, or sorting out deployment problems, that founder is carrying delivery risk for the whole team.

Release setup belongs here too. Somebody has to own quality checks, decide what must pass before a deploy, watch errors after release, and make sure the team does not ship avoidable messes. The same goes for tools and vendors. CI, hosting, monitoring, source control, device labs, test services, and contractor accounts all need an owner. If one founder picks them, negotiates them, and keeps them running, that is founder work.

People management counts as well. One on ones, feedback, performance calls, and hard conversations take energy. They also lower churn, which can save months of re hiring.

A simple rule helps: if the company would need to pay a senior person to do it, do not treat it as side work.

Count fundraising and founder work

After the MVP, founder work changes shape. One person may still write code while the other spends weeks in investor meetings, revising the deck, sending updates, answering follow ups, and keeping slow conversations alive. That work is less visible than shipping features, but it still moves the company.

Fundraising also creates technical work that sits between business and product. Investors ask hard questions about architecture, security, reliability, margins, hiring plans, and delivery speed. Someone has to answer them clearly. If the technical founder handles diligence calls, redraws system diagrams, defends build choices, and explains product risk, count that time. It is founder work, not free support.

Customer calls belong here too when they change the roadmap. If a founder spends hours talking to prospects, sorting real demand from polite feedback, and turning that into better priorities, that affects the business as much as a new feature. A founder who keeps the roadmap honest can save months of wasted effort.

Seen work and unseen work

Public work gets more credit by default because people can watch it happen. Pitching on calls, posting updates, and taking meetings looks like progress. Quiet work gets ignored. That includes prep for investor questions, pricing revisions, technical diligence docs, roadmap cleanup after customer interviews, and all the follow up after the call ends.

A useful way to score it is to track four things for each founder: hours spent each month, how hard the work is to replace, how much risk it removes, and how directly it changes funding, sales, or product direction.

Two founders can both spend 15 hours a week outside core product work, but the impact may differ a lot. One may take investor intro calls that go nowhere. Another may survive technical diligence, close the customer feedback loop, and keep a round alive with sharp follow up. Those are not the same.

If you are discussing the split, count the work people see and the work nobody sees. Startups often underpay the second kind, then wonder why the deal feels wrong six months later.

Use a simple scoring method

A fair split gets easier when you stop arguing in the abstract and put numbers on the work. Use one sheet and score each founder across four columns: ownership, load, risk, and fundraising.

Ownership covers what each person already built and still maintains. Load covers the weekly effort that keeps the company moving. Risk covers how exposed each founder is if things go badly, including career cost, reputation, and the chance of spending months on hard technical problems. Fundraising covers investor meetings, updates, pitch work, and the follow up that can eat whole weeks.

Keep the scale simple. Score each founder from 1 to 5 in every column. A 1 means limited contribution in that area. A 3 means steady, meaningful contribution. A 5 means heavy responsibility with clear impact.

Write a short note next to every score. Do not rely on memory. If the technical founder owns the codebase, carries production risk, and still expects to hire two engineers, say that plainly. If the CEO spent six months raising money and will keep doing it, write that down too.

Separate past work from future work in the notes. Past work matters because it got the company here. Future work matters because equity pays for the next few years, not only the last few months. A founder who carried the MVP alone may deserve a stronger ownership score, but if the product is now stable and the next stage leans heavily on sales and fundraising, the totals may move closer together.

After you score the table, compare totals out loud. Do not jump straight to percentages. First ask where the gap comes from. Sometimes one founder feels undercounted because the table missed invisible work, like on call stress or candidate screening. Fix the inputs before you talk numbers.

Then turn the result into a package, not just a split. Equity can sit alongside salary, vesting, and milestones. If someone gets more cash now, they may need less equity. If trust is still forming, vesting with a cliff keeps the deal fair if plans change.

A simple example

Two founders finish an MVP and think the answer is obvious. Founder A should get a much larger share because A wrote the code. A built the product, runs production, and still gets the late messages when something breaks. B did not build the stack, but B leads sales, runs customer calls, and closes the first paid pilots.

That is where these conversations usually go sideways. If they only look backward, A argues for 70-30. If they only look at revenue pressure, B argues for something close to equal. Both are missing part of the picture.

They score the work they are doing now, not just the work that got the MVP out the door:

• Code ownership and production risk: A 25, B 5
• Hiring and team load: A 15, B 5
• Customer discovery and pilot sales: A 5, B 25
• Founder work outside daily delivery, including investor questions: A 10, B 10

That puts A at 55 points and B at 45. The split changes from the first emotional draft to something more grounded: 55-45 instead of 70-30.

That result feels fairer for a simple reason. A still carries real technical risk. If the product fails in production, A has to fix it. A also spends time hiring engineers, which drains more energy than many founders expect. But B carries the pressure of turning interest into cash. Early pilots, customer interviews, pricing talks, and the fear of missing payroll usually land on B.

A 55-45 split does not mean the argument is over forever. If B starts building a larger part of the team, or A stops owning production, they can score it again later. They should also use vesting so the cap table does not lock in a bad guess.

The point is simple: the MVP matters, but the work after the MVP matters more. If the current load is close, the split should look close too.

Mistakes that skew the split

Most bad deals come from one shortcut: founders copy a split before they score the real work. That might feel fair in the moment, but the company has already changed after the MVP. There is code, product debt, release risk, customer feedback, and often a fragile system that only one person fully understands.

A 50/50 deal is the usual trap. It can make sense on day one, when both people take the same unknown risk. After the MVP, it often hides a different picture. If one founder owns the architecture, knows why the odd parts exist, and can keep production stable, that is not the same as holding a title and joining late.

Titles confuse people too. "CTO" sounds important, so founders sometimes give equity for the label instead of the work. That is backward. Equity should follow what the person actually carries: product decisions, code ownership, hiring, incident response, roadmap tradeoffs, and the cost of being hard to replace.

Replacement cost gets ignored all the time. Deep system knowledge is expensive because a new hire cannot absorb it in a week. If the product has custom infrastructure, messy integrations, or thin docs, replacing the person who built it can take months and a lot of money. Founders should count that risk directly.

Friendship makes this worse. Friends avoid awkward talks, so they round numbers, skip hard questions, and call it trust. Later, the same friendship gets damaged when one person feels underpaid and the other feels cornered. Clear terms are kinder than vague promises.

A dull habit fixes more of this than people expect: write down the work before you talk about percentages.

Leave vesting out, and a bad split gets worse. If someone stops contributing six months later, unvested shares protect the company and the other founder. Without vesting, dead equity can sit on the cap table for years.

Three fixes usually help:

• Score real duties, not titles.
• Count replacement cost for system knowledge.
• Put vesting and cliffs in writing before signing.

If the numbers feel uncomfortable, that usually means you are finally talking about the real deal.

Quick checks before you agree

A split should feel easy to explain. If either founder needs five minutes, a spreadsheet, and a speech to defend it, the deal is probably off. Good logic fits into plain English.

Run through a few blunt questions before anyone signs. Can each founder explain the number in under a minute? Does the split match the next 12 to 18 months, not just the last six? Did you count both past and future work on both sides? Would the deal still feel fair after a bad quarter with missed revenue, a failed hire, and a product delay? And does everyone understand what happens if someone leaves, stops contributing, or changes roles?

One more test helps. Put the agreement away for two days, then read it again. If the same parts still feel fuzzy, fix them now. Small confusion at this stage usually turns into a much bigger fight when money, hiring, or control gets harder.

What to do next

Do the scoring on your own first. If you fill it out together from the start, the louder person often sets the frame. Separate drafts make the gaps obvious, and those gaps usually show where the real disagreement lives.

Then compare notes line by line. Do not argue about the final percentage first. Talk about the inputs: who owns the codebase, who carries product risk, who will hire, and who will spend months on fundraising or customer pressure after the MVP.

A short written memo helps more than another long call. Keep it plain and specific. State each founder's current role, expected weekly load, and any assumptions behind the score, including part time or full time plans. Say what happens if one person stops owning a major area. Set a review date or a clear trigger for revisiting the split.

Write this down before lawyers draft anything. Lawyers turn your agreement into paper. They do not decide whether the split matches the work.

Set rules for when you will revisit it. Do not reopen the split every month, but do reopen it when the job changes in a real way. Good triggers include a founder going full time, the company hiring an engineering team, or one founder taking over fundraising for a long stretch.

If the conversation keeps looping, bring in one outside person who understands startup build work. A CTO advisor can spot things founders miss, especially around hiring load, architecture risk, and how much the codebase still depends on one person. Oleg Sotnikov often works on exactly this kind of operating question through his fractional CTO advisory, and oleg.is is a practical reference if you want a neutral technical view before you lock the terms.

That outside view does not replace founder judgment. It just gives you a cleaner starting point, which is often enough to get to a deal both people can live with.