Founder lessons: hiring your first engineer

There is a specific week in a company’s life when the founder realises the product has stopped being something you can commission and started being something that has to be owned. Usually it arrives as a small, undignified problem: a bug nobody is on call for, a dependency nobody has upgraded, a customer question that needs someone who knows why the code does what it does. That is the week hiring your first engineer moves from a line on next year’s plan to a live decision. Having sat on both sides of this, as the person doing the hiring and as the studio a founder calls instead, here is what I would want to know before starting.

When hiring your first engineer is the right call

The honest test is not whether you have work for an engineer. You always have work for an engineer. The test is whether you have continuity to protect.

Bring someone in-house when the product has behaviour worth defending: paying users, data you cannot afford to lose, a support load that needs someone who understands the system rather than the ticket, and a roadmap where the same person making decisions in March is still making them in September. That is continuity, and it is the one thing external teams cannot fully give you.

Do not bring someone in-house because the build is going slowly. A slow build is a scoping problem far more often than a capacity problem, and a first engineer inherits the scope you already had. Do not do it because a studio is expensive either. A first engineer with employer costs and eighteen months of ramp is not cheaper than a project, it is differently shaped. We wrote the fuller version of that comparison in fractional CTO versus product studio, and it applies almost exactly to this decision.

The uncomfortable version of the test: if this person left after nine months, would you be worse off than if you had never hired them? If the answer is yes because everything now lives in their head, you are not ready. That is the risk to design against, not to discover.

What the first engineer actually needs to be

Founders write this job spec by listing technologies. That is the wrong axis. The first engineer is a generalist with taste and a tolerance for ambiguity, and any stack they are strong in can be worked with.

Three qualities matter more than any framework on the CV.

They ship end to end. The first hire has no platform team, no design system and no QA. They need to be comfortable taking a vague problem all the way to something a user touches, including the unglamorous middle: migrations, error states, the deploy pipeline, the thing that pages someone at 2am.

They write things down. A first engineer who does not document is a single point of failure with a salary. This is the single strongest predictor I have seen of whether the hire survives contact with a second engineer.

They can say no to you. You are going to ask for things that are wrong. A first engineer who builds everything you request is not being loyal, they are being expensive. You want someone who will say “we can do that, and here is what it costs us in six months”, and then build it anyway if you still want it.

What they do not need to be is a CTO. Titles are cheap to give and painful to take back, and a title given in month one becomes a promise about the org chart in year two. Hire an engineer. Let the title follow evidence.

The real cost, beyond the salary line

The salary is the number that gets discussed and the smallest part of the decision. The full picture in the UK includes employer National Insurance, pension auto-enrolment contributions, holiday and sick cover, equipment, software seats, recruitment fees if you use an agency, and the founder time that goes into hiring and then into managing. The current employer rates and thresholds are published by HMRC, and worth checking at the point you build the model rather than taken from a blog post, including this one.

The honest framing is that the loaded cost of an employee sits meaningfully above the headline salary, and the ramp is real: most first engineers are not net productive for the first two to three months, because they are learning a codebase that has no documentation, from a founder who is also doing sales.

So the comparison worth building is not “salary versus studio invoice”. It is: total loaded cost over eighteen months, including your own time, against the same eighteen months bought as project work with a maintenance retainer. Sometimes the hire wins clearly. Sometimes it does not, and the deciding factor is the continuity argument rather than the arithmetic. Our MVP cost breakdown gives you the other side of that ledger in real numbers.

There is a third option founders skip too quickly. A three to six month contract with a senior engineer, with an explicit expectation of documentation and handover, buys you the continuity test without the permanence. If the work turns out to be genuinely continuous, you have a warm candidate and a codebase somebody already understands.

How to interview when you cannot out-code them

This is the part non-technical founders dread, and the fear is misplaced. You are not assessing whether they are a better engineer than you. You are assessing whether they will be a good first engineer for this company, and you are well qualified to judge that.

Four things that work.

Give them your actual mess. Not a puzzle. Show them a real screenshot of your product, a real support ticket, and a real constraint, and ask how they would approach it. Strong candidates ask about users and trade-offs. Weak ones jump straight to a stack recommendation.

Ask them to explain something you do not understand. Pick anything technical from your own product. The quality you are testing is whether they can make you a better decision-maker, because for the next year you will be making decisions with only their explanation to go on.

Ask what they would refuse to build. Silence here is a flag. Everyone senior has a list.

Get a second technical opinion on the code, not on the person. Bring in an advisor, a fractional CTO, or a studio you trust for one paid session to review a code sample or run a technical screen. It is a few hundred pounds against a decision worth tens of thousands. The same instinct applies when you are assessing an agency, and the framework in how to evaluate a developer’s portfolio transfers almost directly.

The first ninety days

Three commitments make the difference between a hire that compounds and one that quietly becomes a dependency.

Give them something shippable in week one. Not the architecture rewrite. Something small, real and user-facing, so they experience the whole pipeline early and you both learn where it is broken.

Insist on written decisions from day one. A short document per meaningful choice, stored where you can find it, is the cheapest insurance you will ever buy. It is also how you avoid the “everything lives in their head” failure mode you tested for at the start.

Protect their focus and be honest about the trade. In a small company the first engineer will get pulled into support, sales calls and integrations. That is fine, and it is often valuable, but it needs naming out loud rather than arriving as a surprise that shows up in their notice period.

Where this leaves you

Hiring your first engineer is worth doing when you have continuity to protect, a role scoped around judgment rather than a stack, and a realistic model of what the eighteen months actually cost. It is worth delaying when the real problem is scope, when the work is a project with an end date, or when nobody in the company can yet describe what the second engineer would do.

If you are weighing this against commissioning the work instead, send us a project brief with where the product is and what is straining. We will give you an honest read, including the answer that you should hire rather than call us.