Taking a founder-only codebase to a real engineering teamBuilding the first real engineering team around a founder

The problem

The founder had built a working product entirely on his own and got paying customers onto it. Impressive, but it left the company with a bus factor of one. He was the only person who understood how the system fitted together, so every change, from a small bug fix to a major feature, went through him.

There was no review process and no written documentation, because there had never been anyone to review or read it. Customers were starting to ask due diligence questions about key-person risk, and the honest answer wasn’t a good one. He couldn’t take a week off without development effectively stopping.

He wanted to hire, but he’d never built a team. Hiring without a process risked bringing in engineers who still needed him to check every line, which would have solved nothing.

What we did

We started with hiring, because nothing else works without more people. I helped him define the first roles around ownership of specific areas of the product, rather than a wishlist of impressive-sounding skills. We designed an interview process that tested judgement, debugging and the ability to work independently, rather than algorithm trivia. I sat in on the early hires so he wasn’t making those calls alone. The team grew to between four and six engineers.

Hiring was only half of it. The other half was a way of working that didn’t need the founder’s personal sign-off:

• Pull requests with required review and CI. Every change went through a PR with at least one reviewer and automated tests before merging. That catches defects before they ship and spreads knowledge of the system beyond one person.
• Documentation. We wrote down how the system actually works (architecture, key flows, local setup) clearly enough that a new engineer could be productive within their first couple of weeks.
• Onboarding. Onboarding used to mean sitting next to the founder and asking questions as they came up. New hires now had a clear path through the codebase, the product and how decisions get made.
• ADRs and RFCs. Bigger technical decisions are written up as short proposals, with a clear threshold between what an engineer can just decide and what needs a wider conversation. Decisions stopped being either bottlenecked on the founder or made by guesswork.

Where things landed

The founder noticed the clearest change first: he could go quiet for days, on holiday or heads-down on sales, and development kept moving. Bugs got fixed and features shipped without anything waiting on him.

With review and CI on every change, the team catches its own mistakes before customers do. That’s a quieter benefit than it sounds, but it changes the risk profile of a growing product.

And when customers asked the key-person question in due diligence, there was finally a real answer: a team, a documented system, a review process and a written record of the big decisions, not one very talented person holding it all together.

The problem

The founder here had done something genuinely impressive: built a working product entirely on his own and got real customers using it. But he’d reached the point every technical founder hits eventually, where the thing that got the business started is now the thing holding it back. He was the only person who understood how the whole system fit together, which meant every decision, from a small bug fix to a major new feature, had to pass through him.

That’s exhausting for a founder and it’s also a serious business risk. Customers were asking harder questions during sales conversations, the kind that come from a proper due diligence process, and the honest answer to “what happens if something happens to you” wasn’t a good one. He couldn’t take a week off without the product effectively pausing. He wanted to hire, but he’d never built a team before and wasn’t sure how to do it without ending up with people who needed him to check every line of their work, which would have solved nothing.

What we did

We started with hiring, because nothing else works until there are more hands on deck. I helped him get clear on what the first few hires actually needed to look like, not a wishlist of impressive-sounding skills, but people who could genuinely take ownership of parts of the product and be trusted with them. We built out an interview process that tested for judgement and the ability to work independently, not just technical trivia, and I sat alongside him through the early hires so he wasn’t making those calls alone.

Hiring the people was only half the job. The other half was giving them a way to work that didn’t require the founder’s personal approval on everything. We put in a proper code review process, so changes got a second pair of eyes before going live, which both catches mistakes and spreads knowledge of the system beyond one person’s head. We wrote down how the product actually worked, in plain enough terms that a new engineer could get properly useful in their first couple of weeks instead of needing weeks of one-to-one hand-holding from the founder.

We also built a simple onboarding process, because until then “onboarding” had meant sitting next to the founder and asking questions as they came up, which doesn’t scale past one person. New hires now had a clear path to understanding the codebase, the product, and how decisions got made, without needing to interrupt him constantly to do it.

Alongside all of this, I helped set some basic technical direction and decision-making habits: how the team decides on approach when there’s more than one way to build something, and when a decision is big enough to need a wider conversation versus small enough to just make. That’s the kind of thing that sounds obvious until it doesn’t exist, and then everything either grinds to a halt or turns into guesswork.

Where things landed

The clearest change is the one the founder noticed first: he could go quiet for a few days, on holiday or just heads-down on sales, and the product kept moving without him. Bugs got fixed, small features shipped, and nothing came to a stop waiting for his input.

The team also started catching its own mistakes before customers did, simply because code review meant a second person looked at everything before it went out. That’s a quieter benefit than it sounds, but it changes the whole risk profile of a growing product.

And when customers asked those due diligence questions about what happens if the founder gets hit by a bus, there was finally a real answer: a team, a process, and documentation, not just one very talented person holding it all together.