Technical cofounder meeting before equity talks for startups

Why this meeting matters

Most founder equity talks break down before anyone names a percentage. The problem starts earlier, when people negotiate from hope instead of facts.

Early excitement makes that worse. The idea feels clear, the chemistry feels good, and both founders assume they mean the same thing. Then the real questions show up. What are you promising customers in the first six months? How much ownership do you want to protect for future hires and investors? Who will handle the slow, unglamorous work every week?

If you skip those questions, the conversation drifts fast. One founder may think they are joining a fast build with a light support load. The other may expect enterprise sales, custom work, late-night fixes, and a long runway before revenue. On paper, both are talking about ownership. In reality, they are pricing two different jobs.

A good meeting puts the vague parts into plain words before anyone starts bargaining. Start with three basics: what customers have been promised, what each founder wants from the cap table, and how the day-to-day work will actually run.

These topics sound simple. They are not. They force founders to trade fantasy for specifics, which is the whole point.

This meeting does not replace a lawyer, tax advice, or formal documents. It does something earlier and often more useful. It shows whether the partnership makes sense before tension turns into a permanent ownership deal.

If the conversation feels uncomfortable, that is usually a good sign. You are finding the real shape of the company before the cap table locks in bad assumptions.

What to bring into the room

Bring the messy version, not the polished one. This meeting works best when both people look at the same facts, even if those facts are incomplete or awkward.

Start with the current pitch and the notes behind it. Bring the deck, the one-page summary, sales call notes, demo feedback, and the roadmap you are using right now. If the pitch says the product will save teams hours every week, but customer calls keep asking for hands-on service, that gap matters before you talk about ownership.

Write down every promise already made to customers or trial users. Do not rely on memory. Include delivery dates, custom features, support expectations, pricing promises, security claims, and anything said in email or calls that shaped a buyer's decision. Founders often negotiate around the product they want to build, then spend the next year building the product they already sold.

You also need a plain list of who does what today. Keep it basic. Who owns product choices? Who writes code? Who hires? Who talks to users when something breaks on a Friday night? This is where founder alignment gets real. If one founder thinks support is shared and the other assumes it belongs to the non-technical side, friction starts early.

Bring a simple cap table draft too, even if it feels early. It should show current ownership, any advisors or early contributors, the option pool you expect to need, and the shares you may want to reserve for future hires or investors. You do not need a lawyer-style spreadsheet yet. A rough, readable draft is enough.

A small example makes this concrete. Say the startup already promised a pilot customer custom reporting within eight weeks. The product founder expects the technical founder to build that first. The technical founder wants to spend two months fixing the architecture before shipping anything new. If neither person brings the sales notes, roadmap, role split, and share plan into the room, they end up negotiating around wishful thinking.

The goal is simple: bring proof of the business you have, not just the business you imagine. That gives you a fairer base for titles, ownership, and a working agreement later.

Start with customer promises

Ownership talks get messy when founders argue from different versions of the product. One person thinks the company sold a simple MVP. The other thinks it already promised enterprise features, custom workflows, and a tight launch date. If you do not clear that up first, the whole conversation turns into a fight about fantasy.

Start with a plain question: what do customers believe they are getting? Use the actual words from sales calls, proposals, pilot agreements, invoices, and follow-up emails. A customer does not care that a feature was "just an idea" if a founder said it would be ready in six weeks.

Sort promises into two buckets. The first bucket is firm commitments: signed scopes, paid pilots, dates in writing, and features used to close a deal. The second bucket is hopeful talk: rough roadmap guesses, ideas mentioned in discovery calls, or things said to keep interest warm. Those buckets should not carry the same weight.

Some promises sound small but pull in months of engineering work. Custom reporting, audit logs, SSO, offline mode, mobile apps, or deep integrations can change the entire build plan. If one founder sold any of those, mark them clearly. They affect staffing, timing, and whether one technical founder is enough.

A short checklist helps:

• Which promises are written down and tied to money?
• Which ones need new architecture, not just polish?
• Which ones force security, compliance, or support work early?
• Which ones move the timeline from weeks to months?

Say a startup told its first customer, "You will get role-based access, approval flows, and a full admin dashboard by the end of the quarter." That is not a loose product vision. It is a delivery promise with staffing and scope built into it.

If those promises mean backend work, infrastructure work, and ongoing support, the cap table conversation changes fast. You are no longer discussing an abstract product. You are discussing the cost, risk, and effort attached to promises already out in the world.

Put cap table goals in plain words

Most founders say they want "a fair split," but that phrase hides a lot. One person may want long-term control. The other may care more about enough ownership to stay motivated through a hard first two years. If you do not name those goals early, the discussion turns into guesswork.

Put each founder's ownership goals on one page. Write what each person wants from equity, not just the number they hope to get. That usually means voting power, future upside, room for early employees, and how much dilution they can live with.

This gets easier when both people look at the same simple cap table instead of arguing from instinct. Start with who owns what today, then add the changes you expect next: an option pool for future hires, likely dilution after the first outside round, and the ownership picture after one or two hires you already know you need.

This often changes the mood fast. A founder who feels great about 40% today may feel very different when that number drops after an option pool and investor dilution. Another founder may realize they do not need a bigger starting number if they still keep enough after a seed round.

Control goals need the same honesty. If someone wants to keep board control for as long as possible, say it out loud. If the plan is to raise quickly and hire a senior team, that control will usually shrink. Those ideas can live together, but only if both founders see the trade-off.

Stage matters too. A small services business, a bootstrapped SaaS product, and a venture-funded startup do not produce the same cap table. Founders often argue over percentages before they even agree on what kind of company they are building. That is backwards.

Do not negotiate around raw percentages until everyone sees the same table and the same next steps. When both founders can point to the same numbers and say, "Yes, this is the path we expect," the actual split gets easier to discuss and much harder to regret.

Talk about working style before titles

A title sounds important, but daily behavior decides whether two founders can build together. Before talking ownership, compare how you work when things get messy, late, or expensive.

Start with pressure. If a launch breaks on Friday night, who decides what ships, what gets rolled back, and who talks to customers? One founder may want fast calls with partial information. The other may want a written plan first. Neither style is wrong, but a mismatch creates resentment quickly.

Small habits matter more than most founders expect. Put real numbers on them. Say whether you reply in an hour, by end of day, or when you can. Say how many meetings you can tolerate each week. Say where decisions live so nobody has to hunt through chats later.

Keep the practical points short and clear:

• expected response time for urgent and normal messages
• meeting rhythm and who sets the agenda
• where product and technical decisions get written down
• how you raise a concern when you disagree
• what happens when someone misses a deadline

Conflict deserves direct language. Some people argue in the room and move on. Others go quiet, then stay frustrated for weeks. Talk about that now. Decide what happens when deadlines slip too. Do you re-scope, ask for help, or reset the promise together?

Then define the role in hours, not vibes. "Full-time" might mean 50 hours a week to one person and 30 focused hours to another. "Part-time" may be enough for architecture and hiring, but not enough to run delivery. "Advisory" usually means limited access, limited ownership, and no day-to-day responsibility.

A simple test helps: describe the next 90 days in calendar terms. Who is available on weekdays, who joins customer calls, who writes specs, who reviews code, and who owns production issues? If one person expects a partner and the other plans to be an occasional helper, the title will not fix it.

Run the meeting step by step

This meeting works best when both people look at the same facts on one page. Use a shared doc or whiteboard. Keep the conversation plain. If someone cannot explain a point in one sentence, it is probably still fuzzy.

Start with the promises you plan to make to customers. Name the problem, who has it, what version one needs to do, and what you will not build yet. A startup can survive a rough roadmap. It usually cannot survive a promise it has no chance of keeping.

1. Write down the product scope first. Name the first customer type, the first result they expect, and the limits of the first release. If the idea is still broad, narrow it now.
2. Move to roles and time commitment. Decide who owns product decisions, who builds, who talks to users, and who handles hiring or fundraising. Be direct about hours. "Full-time" and "nights and weekends" are not close enough to treat as the same thing.
3. Discuss ownership goals only after the work is clear. Say how much room you want to keep for future hires, advisors, and investors. If one founder wants control and the other wants flexibility, say that early instead of arguing over percentages.
4. End with open risks and next decisions. List what still feels uncertain, who will check each item, and the date of the next meeting. A follow-up date matters because unresolved issues drift into resentment fast.

This order makes the discussion calmer. You are not debating worth in the abstract. You are matching ownership to actual work, actual risk, and actual plans.

Sometimes an outside operator helps here. A startup advisor or fractional CTO can spot gaps in scope, team design, or cap table assumptions before they turn into a bad deal.

A simple startup example

A two-person SaaS startup often reaches the ownership conversation too early. One founder sells. The other builds. That sounds clean until customer promises get ahead of the product.

Say Nina handles sales and partnerships. Pavel is the builder. Nina talks to five early prospects and gets real interest fast, but she also promises custom reporting, a Slack integration, and team permissions in the first month because she wants deals to move.

Pavel hears this in the meeting and pushes back. He is not being difficult. He is doing the math. With two people, no designer, and no budget for another engineer, those promises mean late nights, rushed code, and support problems a few weeks later.

They stop talking about percentages for a moment and write down what customers were actually told. That changes the tone. Two promised items are nice to have. One is needed for the first pilot. Another would force a rewrite later if they build it the wrong way just to close one customer.

Pavel then puts the timeline in plain words. He can ship the core product in six weeks if they keep the first release narrow. He cannot ship the core product, custom features for three buyers, and production-grade admin tools on the same schedule without help. If Nina wants all of that, they need budget for a contract engineer and room in the cap table for an early hire.

Now the ownership discussion gets more honest. Nina is bringing demand and customer access. Pavel is taking on product, architecture, and the risk of building under pressure. They also talk about working style. Nina likes fast promises. Pavel wants written scope before he commits. Neither style is wrong, but they need rules.

They reset the plan. Nina will stop offering custom work before Pavel approves scope. Pavel will give rough estimates within a day instead of disappearing into a two-week planning cycle. They keep part of the cap table open for the first technical hire and agree on vesting so no one locks in a big stake after a short run.

Only after that do percentages make sense. The final deal is fairer because it reflects the real job, the real promises, and the real cost of getting to version one.

Mistakes that distort the deal

These meetings go wrong when both people price a company that does not exist yet. One founder talks about the app idea, the other imagines months of work, and they settle on a number before they agree on what customers are actually being promised. That creates fake certainty. If the promise is still rough, the split should stay rough too.

Effort gets misread fast when the product is only a sketch. A login screen and a dashboard can sound small. The real work may include data models, billing, admin tools, error tracking, deployment, backups, and on-call support. If nobody names that work, the builder looks "expensive" or "slow" when they are simply counting the full job.

Part-time help is another source of bad deals. A person who joins for five hours a week is not taking the same risk as someone who will own delivery, hiring, late-night outages, and security decisions. Advice, introductions, and code review matter, but they are not the same as full founder commitment.

Founders also skip the boring work because it is less visible. Support, infrastructure, security, monitoring, maintenance, and incident response do not make a flashy demo, but they keep customers from leaving. Architecture and operations are business choices, not side chores. If one person will carry that load, count it before the ownership discussion starts.

Future-valuation math causes the worst distortion. "If we become a $50 million company, this split will feel fair" is fantasy dressed up as logic. Early equity should reflect present risk, present responsibility, and the next stretch of work. If revenue takes longer than expected, ask who is still doing the hard work every week.

A simple example makes this clear. One founder says, "We just need an MVP in six weeks." The technical founder knows the promise also needs auth, audit logs, cloud setup, alerts, bug fixes, and customer support. That is not a tiny build. Many equity fights start as scope mistakes that nobody named in plain words.

Quick check before you discuss equity

Do not open the ownership conversation until both founders can answer a few plain questions the same way. If those answers drift, the numbers will drift too.

You are ready only when the business story and the work plan match. One founder should not picture a high-touch service business while the other expects a product that runs with little support. That gap turns a fair deal into an argument.

Five-minute test

Use this short check before anyone says a percentage out loud.

• Both founders can state the main customer promise in one sentence, using nearly the same words.
• The next 6 to 12 months have clear owners for product, sales support, hiring, delivery, and technical work.
• Time commitment is explicit. Full-time, part-time, evenings only, and the date that changes all matter.
• Decision rights are written down. Someone owns the final call on product scope, architecture, budget, and hiring.
• The cap table plan includes future dilution, an option pool if needed, and the first hires that will change ownership later.

Then write down the open risks before you discuss percentages. Put the hard stuff on paper: unpaid time, customer concentration, a product rebuild, a founder who may leave a day job late, or a sales plan that still feels shaky. If you skip this step, equity starts to cover hope instead of work and risk.

A simple test makes this even clearer. Ask each founder to answer this: "What do we owe customers in the next six months, and who will do that work?" If the answers differ, stop there. Fix the plan first.

This check does not need a long workshop. Twenty focused minutes can save months of resentment. If the two founders keep talking past each other, a neutral operator can help force specifics. Oleg Sotnikov at oleg.is does this kind of CTO-level advisory work with startups, especially when scope, architecture, and founder expectations are still blurry.

What to do next

Write the record while the conversation is still fresh. One page is enough. Once notes get too long, people start hiding uncertainty inside them.

That page should capture what each founder said yes to, what still feels shaky, and what must be true for the plan to work. Include customer promises, who owns the first stretch of work, and any cap table assumptions that came up.

A short format works well:

• what we agreed to now
• what we do not agree on yet
• what evidence or decision would settle each open point
• when we will meet again

Turn friction into questions you can answer. That is how you reach a deal both founders can actually live with.