Technical cofounder vesting terms that fit real work

Why copied vesting terms fail

Most founder fights do not start with a missed paycheck. They start when two people sign the same standard vesting deal even though they are carrying very different loads.

A copied schedule treats every cofounder as if the work is equal and predictable. Early startups rarely work that way. One person may build the first version, choose the stack, handle late-night outages, and interview every engineer. Another may work part time for months, join after the product direction is clear, or stay focused on a narrower lane. If both get the same vesting terms by default, tension is hard to avoid.

The problem gets worse when a company uses a flat timeline and ignores execution pressure. A technical founder often does far more than write code. They absorb risk that looks small on paper but feels very real in practice: shipping the first product with little support, fixing bad hires, making architecture choices that are hard to reverse, and carrying delivery pressure when deadlines slip.

A plain four-year schedule cannot capture that on its own. Time matters, but so does what happens during that time. If one founder spends six months turning an idea into a working product while another contributes unevenly, equal vesting starts to feel dishonest.

That is when small disagreements turn into bigger ones. A missed deadline becomes an argument about commitment. A hiring delay becomes a fight about ownership. Normal startup stress starts to feel personal when the equity split does not match the work people think they are doing.

Good vesting terms start with the workload, not a template. They should reflect who is building, who is recruiting, who is on the hook when things break, and who takes the bigger risk if the plan stalls.

People copy terms from another startup because it feels fair and simple. It is simple. Fair is a different question. A clean document does not fix a bad match between ownership and effort.

What the package should actually cover

A good package does more than assign a percentage and a four-year vesting line. It should match the work the technical founder is taking on, the parts of the company they truly control, and the uncertainty they carry before the business has traction.

Start with ownership from day one. Write down who owns the product architecture, codebase, security, infrastructure, release process, and technical decisions. If one founder will also pick tools, set coding standards, and handle production issues at 2 a.m., that is a bigger job than "build the first version."

Then separate coding from management. Founders often blur those into one role, and that causes trouble later. Writing code is one track. Hiring engineers, reviewing their work, setting process, and carrying delivery risk is another. Someone who does both should not get the same package as someone who only writes code.

A short checklist helps. Cover product and system ownership, delivery responsibility, hiring, production and security risk, and decision rights when deadlines slip. Those are usually the areas that create confusion later.

Hours matter less than risk. Two people can both work 50 hours a week, but one may carry the harder burden: building from zero, solving unknown technical problems, and making early calls that can save or sink the product. Vesting should reflect that risk, not just time spent at a laptop.

Scope also changes. It usually does. If the plan starts with one founder coding the first version and later turns into running infrastructure, hiring a team, adding compliance, and supporting larger customers, the package should say how that shift affects equity, salary, or both. The reverse matters too. If the role gets smaller because the company hires a CTO or cuts product scope, the agreement should let both founders revisit the terms.

The cleanest package names the role, the work, and the events that can change the deal. That alone can save a lot of resentment.

Separate equity from role and pay

Equity answers one question: how much of the company does this person earn over time? Pay answers another: what does the company owe them for work right now? If you mix those together, you end up with a deal nobody can explain six months later.

A technical cofounder can take more risk than an early employee, but risk is not the same as free labor. If cash is low, say that plainly. Do not let unpaid months quietly turn into extra ownership unless both founders agreed to that rule from the start.

Write the ownership piece on its own. State the total equity, when vesting starts, how it accrues, and what happens if the founder leaves or stops doing the agreed work. That is the ownership deal.

Write pay in a separate paragraph or a separate document. Keep it simple. Say whether salary starts now, later, or only after funding or revenue reaches a stated level. Say whether deferred salary is tracked and owed later or simply waived. Reimbursements for tools, cloud costs, or travel are not part of equity. If heavy hiring or a launch period calls for extra cash, that needs its own agreement too.

Control needs its own rules as well. Many founder fights start because one person thinks equity gives them final say on architecture, deadlines, and engineering hires. It does not unless you write that down.

If the technical founder controls architecture, define the boundary. They may choose the stack, coding standards, deployment approach, and security rules. Product priorities, budget limits, and release dates may still need joint approval or CEO approval. Put each decision in the right bucket.

Write the role in phases

Early on, the same person often writes code, ships the first version, handles infrastructure, and interviews candidates. Later, that job can shift. Once the team has a few engineers, the founder may spend less time building and more time hiring, reviewing work, and keeping delivery on track.

Name the trigger for that shift. It could happen after launch, after funding, or when the team reaches a set size. Then say what changes: title, salary, authority, and weekly duties. Do not reopen vested equity just because the day-to-day job changed.

That separation keeps expectations clean. Ownership rewards long-term commitment. Pay covers current work. Role defines who decides what.

How to build terms step by step

Start with the next 12 to 18 months, not with a copied schedule. The goal is to match ownership transfer to the work that actually has to happen before the company becomes real.

A pre-product startup with no engineers needs a different deal from a company that already has customers, code, and a small team. If one founder is joining to build version one from scratch, carry on-call work, and make the first hires, the package should reflect that load.

A simple process works well:

1. Look at the company as it is today. Is there only an idea, or is there already a prototype, users, or revenue? Write that down in plain English because the starting point changes the risk on both sides.
2. Estimate the work needed to reach the next durable point. That usually means launch, early customer feedback, the first stable release, and the first one or two hires. Be honest about time. Building the product and hiring at the same time can easily double the founder's load.
3. Pick a vesting period that matches that plan. Four years is common, but common is not the same as correct. If most of the hard value creation sits in the first 18 months, you may still use four years, but you should know why.
4. Add a cliff only if both founders accept the trade-off. A one-year cliff protects the company if someone leaves early, but it also raises the personal risk for the founder doing the build. If that feels lopsided, shorten it or remove it.
5. Write review points before anyone signs. Set dates, say what you will check, and say what does not change unless both people agree. Good review points are concrete: product shipped, core system stable, first engineers hired, handoff working.

A simple test helps: "If we follow this plan and one founder does the hard part for nine months, will the equity already earned feel fair?" If the answer is no, fix the terms now.

This is where vesting usually goes wrong. Founders negotiate percentages, then leave the messy part vague. The better move is boring and clear: define the work, define the risk, and define when you will review it.

When milestones help and when they hurt

Milestones can work when a technical cofounder takes on work that is easy to name and easy to verify. They fit concrete events such as shipping the first usable product, moving the app into production, or hiring the first engineer and getting that person productive. In those cases, both founders can point to the same result and agree that it happened.

They create trouble when they describe effort instead of outcomes. Terms like "lead the tech side," "support fundraising," or "build the platform" sound fine on day one, then create arguments later. One person thinks the goal is done. The other says it is only half done. That is where resentment starts.

A milestone should pass a simple test. Both founders should be able to measure it without debate. One person should not be able to block it for reasons outside the work. The result should matter to the company rather than to anyone's ego. And the deadline should make sense for the startup's stage.

Ownership transfer should depend on milestones only when the finish line is clear. "First paying customer can log in and use the product" is clear. "Product is market ready" is not. If the wording leaves room for a long argument, fix it before anyone signs.

Be careful with goals tied to investor behavior. A founder should not lose equity because a fund took six months to decide, the market cooled off, or a lead investor walked away. Fundraising depends on timing, relationships, and luck, not just execution. If you want to reward help with fundraising, do it through role expectations or pay, not through equity triggers.

Time-based vesting should still carry part of the package. That gives both sides a stable default and lowers the chance of constant scorekeeping. A practical middle ground is to keep most equity on a normal vesting schedule and place only a smaller part on milestones. That works better than putting everything behind gates.

If the startup has a lot of uncertainty, simpler terms usually win. A clean schedule with one or two sharp milestones is easier to live with than a clever formula nobody wants to argue about six months later.

A simple example with two founders

Maya knows the market. She spent two years talking to buyers, understands the problem well, and has three early customers ready to pay if a first version solves one painful task. Leo joins as the technical founder. He takes over the codebase, chooses the stack, and commits to shipping v1 in four months.

They do not copy a flat 50/50 deal. Maya brings the idea, customer access, and the first path to revenue. Leo takes on execution risk right away. Their vesting terms match that mix instead of pretending both jobs are the same.

They agree on a simple structure:

• Maya gets 55%, vesting over four years with a 12-month cliff.
• Leo gets 35% on the same schedule for owning product delivery, code quality, security, and the v1 launch.
• Leo can earn another 10% if he hires the first two engineers, sets up team process, and keeps delivery on track for six straight months.

That extra 10% is not a reward for effort alone. It pays for a larger job. Hiring takes time, judgment, and cleanup when early recruits are not a fit. If Leo builds the first engineering team well, he changes the company in a lasting way.

They also write review dates into the agreement. At 90 days, they check whether the product scope still matches the original plan. At launch, they review whether Leo delivered v1 and whether Maya turned those early customer talks into real contracts. At month 12, they decide whether the hiring milestone is still active and whether Leo earned the added equity.

Fallback terms prevent the usual arguments. If Maya cannot fund the first hires, the hiring milestone pauses instead of disappearing. If Maya keeps changing scope and pushes launch back, Leo does not lose equity because the target moved. If Leo stops working full time before v1 ships, his unvested shares return to the company.

This kind of split is not fancy. It simply ties ownership to the work each person actually does.

Common mistakes that cause resentment

Most equity fights start long before the fight itself. They start when people use a startup template that ignores the real job, the real risk, and the real time each person will put in.

One common mistake is giving every technical founder the same package. That sounds fair, but it usually is not. A person who will own architecture, hire the first team, carry on-call pressure, and make product tradeoffs is taking on a different load from someone who will mainly build features.

Another mistake is promising CTO-level equity for work that is closer to a senior engineer role. Writing code matters. Owning the whole technical side is more than writing code. If one person will recruit engineers, set standards, review work, handle outages, and make hiring calls, the equity should reflect that wider job.

Recruiting and team leadership often get ignored because they are harder to picture on day one. But they cost real time. Interview loops, candidate outreach, onboarding, and replacing weak hires can eat weeks. If the agreement treats all of that as invisible labor, resentment shows up quickly.

Founders also get into trouble when they use milestones nobody can verify. If a milestone depends on fuzzy phrases or on another founder behaving perfectly, it is a bad milestone. It will become a debate, not a decision.

Then there is silent scope creep. The role starts as "build v1" and slowly turns into "build v1, run infrastructure, fix security issues, recruit engineers, support sales calls, and manage contractors." If the package stays frozen while the job keeps growing, the founder carrying that extra load will notice.

Quick checks before you sign

A vesting draft is only good if both founders can explain it in plain English. If one person says, "you earn equity by staying," and the other says, "you earn equity by shipping and building the team," you do not have a shared deal yet.

This matters more than the template. Many fights start because the document looks standard, but each founder reads a different promise into the same sentence.

Before signing, answer five plain questions:

• Can both founders explain who earns what, when it vests, what can stop vesting, and what happens if someone leaves?
• Does the vesting match the work expected in the next 12 to 24 months rather than some vague long-term plan?
• Did you spell out who owns the code, who must hire, and who must deliver the product on a real timeline?
• Did you write what changes after funding, after a major scope change, or after a missed plan?
• Did each founder get separate advice before signing, even if the final deal stays the same?

The second point gets missed all the time. If one founder expects the technical cofounder to build version one, run releases, recruit two engineers, and fix early customer issues for the first 18 months, the vesting schedule should reflect that load. A flat schedule can work, but only if the actual role is also flat. Early startup work almost never is.

Write hard edges into the draft. Say who controls the repository, who can approve production changes, whether the technical founder must manage hiring, and what counts as delivery. "Help with product" is too soft. "Own architecture, ship MVP by month six, hire first backend engineer by month nine" is clear.

Separate advice matters too. One lawyer for the company can paper the deal, but each founder should still get their own read from counsel or from an experienced CTO advisor. That costs less than a breakup later.

If you can both read the agreement out loud and neither side feels surprised, the split is probably close to fair.

What to do next

Do not start with legal papers. Start with a one-page memo that says what each founder is expected to do, what equity they earn, how vesting works, what salary is planned now, and what changes if hiring slows down or the company runs short on cash.

That memo does two useful things. It exposes vague promises before they become a fight, and it gives your lawyer something clear to turn into documents later. If you cannot explain the deal in plain English on one page, the deal is still fuzzy.

A short process works better than a long debate. Write down the role, time commitment, and first 6 to 12 months of expected work. Tie ownership transfer to that real scope, not to a copied schedule. Add the conditions that would change the package, such as missing hires, a product pivot, or a shift from full-time to part-time work. Then ask both founders to read it separately and compare where they disagree.

Before lawyers draft anything, get a neutral review from someone who understands product, hiring, and delivery risk. A good advisor can spot a mismatch quickly. A technical founder may agree to own engineering, hiring, security, and production operations while the vesting terms only reflect coding. That gap usually turns into resentment later.

It also helps to plan one review point in advance. Revisit the package when the company changes stage, raises money, cuts the hiring plan, or asks one founder to carry more execution risk than expected. Early terms do not need to stay frozen if the job itself changes.

If you want an outside review before you sign, Oleg Sotnikov at oleg.is works with startups on technical scope, hiring plans, product architecture, and Fractional CTO questions. A practical review from someone who has handled engineering, infrastructure, and founder-level tradeoffs can catch a bad equity match before it turns personal.

A short memo today can save months of damage later.