Building without a technical cofounder

When you genuinely need a technical cofounder

Some companies shouldn’t try to work around the gap. You probably need a cofounder, with real equity and full-time commitment, if:

• The technology is the product’s edge – a novel algorithm, a hard infrastructure problem, a research-heavy AI product. You can’t outsource the core of what makes you different.
• You expect to iterate daily for years. Someone has to live in the code and care about it the way you care about the business.
• Your target investors expect one. Many early-stage investors are reluctant to back a software company with no technical founder. Ask the ones you’re targeting directly.

If that’s you, my honest advice is to spend the time finding a cofounder. I can help you evaluate candidates technically, but I won’t be a substitute.

When a technical cofounder alternative works

Plenty of good businesses are software-enabled rather than software-first: a marketplace, a vertical SaaS for an industry you know deeply, an internal platform for an operations-heavy company. The edge is your market knowledge and distribution. The software has to be solid, but it doesn’t have to be novel.

For those, a part-time senior technical lead plus an agency or small team is a reasonable setup, at least until you can hire a full-time technical leader.

Translate: what I do in your meetings

Much of the value is simply being in the room. When the agency says a feature will take six weeks, I can tell you whether that’s reasonable and what’s driving the number. When the developer says the system needs to be rewritten, I can tell you whether that’s true or whether they’d just prefer a fresh start. When an investor asks about scalability or security, I can help you give an answer that’s accurate and that you understand.

Verify: how to tell if your dev team is doing good work

Even without me, you can check a lot yourself. Ask for these, and treat resistance as a warning sign:

1. The code is in a repository your company owns (a GitHub or GitLab organization in your name), with the developers added as members.
2. Cloud, domain and third-party accounts are registered to the company, with you as an owner.
3. There’s a staging environment you can use, updated at least weekly, so progress is something you can click rather than a demo.
4. Deploys are routine. Ask how often code reaches production and how long it takes. Weekly or better is healthy; “we’re saving it for the big launch” isn’t.
5. Errors are tracked. There should be a tool that records crashes, and someone looking at it.
6. Estimates come with assumptions. A number without a list of what’s included and what’s risky is a guess.

If several of those fail, a short code audit is a cheap way to find out what you actually have before spending more.

Hire: building your first engineering team

Eventually you’ll want engineers on staff. Non-technical founders often hire the person who interviews best rather than the person who’ll build best. I help write the job spec, run the technical part of the interview with a practical exercise, and give you a clear recommendation. For the most senior hire, the CTO job description guide is a good starting point.

How this usually runs

It starts with a two-week sprint. I review what exists, sit in on your meetings with the dev team, ship a real fix or improvement myself, and give you a written view of where you stand. After that, I can stay on for a fixed number of days a week until a permanent technical leader is in place. If you’re still at the idea stage, see MVP development for startups instead.

Related

• MVP development for startups, built to survive Series A
• Fractional CTO for startups: what you need at each stage
• A code audit that tells you what you’ve actually got
• Software project rescue for late, stalled and inherited projects
• CTO job description: a template by company stage
• Staff augmentation vs outsourcing: which model fits your team?