What a technical cofounder actually decides

The question underneath the question

Most first-time founders don't ask whether they need a technical cofounder. They ask whether they're allowed to have opinions about the product without one.

The honest answer is that half the decisions people call technical aren't. They're product decisions wearing technical clothes, and you're better placed to make them than an engineer is. The other half genuinely need somebody who has shipped something before, and no amount of reading closes that gap.

Here are all eight, and which is which.

The four you can hold yourself

What ships in version one. This looks technical and isn't. It's a question about which customer, doing which job, on which day. You know that better than anyone you could hire. What an engineer adds is a sense of what each item costs to build, which changes the order, not the judgement.

What to stop building. Nobody is better placed than you to notice that a feature you were excited about has been live for two months and nobody has touched it. Engineers are famously bad at this, because the thing works and it took a fortnight.

What done means. Write the acceptance from the user's side, in plain sentences. "A new customer can sign up, pay, and get their first report without emailing us." That's a better specification than most technical ones, and it's yours to write.

What to do when an estimate slips. Three options: cut scope, move the date, or spend more. That's a commercial decision with a technical input, not the other way round. What you need from an engineer is an honest new date, not permission.

The four that need somebody who has shipped

Build versus buy on each piece. The trap is that almost everything is buyable and almost nothing is buyable well. Authentication, payments and email are usually bought. The thing that makes your product different is almost never buyable, however close an off-the-shelf tool looks. Getting this wrong in either direction costs months, and you can't tell which direction you're wrong in without having been wrong before.

Which stack you can hire against later. A stack that one contractor loves and nobody else uses will strand you in eighteen months, at exactly the point you're trying to hire your first engineer. This decision is made in week two and its cost arrives in year two, which is why first-time founders almost never see it coming.

How much to spend on infrastructure before revenue. There's a version of this where you spend nothing and the first real day of traffic takes you down. There's another where you're paying for capacity you won't use for two years. Both are common and both are avoidable with someone who has watched a system under load.

When to rewrite. The hardest call in software. Rewrites are usually wrong, occasionally essential, and always more expensive than the estimate. Somebody who has done one knows the tells. Somebody who hasn't will either rewrite too early because the code is ugly, or too late because rewriting feels like failure.

What this changes about hiring

If four of the eight are yours, the question stops being "do I need a technical cofounder" and becomes "who holds the other four, and on what terms."

That's a much easier question. It has more than one answer, and giving away a quarter of your company is only one of them.