When to hire your first in-house engineer

Hire your first in-house engineer when the product changes every week, when the same context has to be re-explained to whoever picks up the work, and when the system has become the place other people look up the truth. Not because a build is nearly finished, not to save money in year one, and not before somebody exists who can interview, onboard, review and, if it comes to it, fire an engineer.

We are an agency, so name our incentive first. A client who hires well and keeps us on a smaller retainer is worth less per month and considerably more over five years than one who stays dependent. Enlightened self-interest rather than charity, and it should still be useful read that way.

The four signals it is time

None is about company size or funding stage, and one alone is rarely enough.

Change velocity is weekly, not quarterly

An agency is built around batches: a scoping conversation, a written change, a slot in a cycle, a release. That machinery earns its keep when changes arrive ten at a time and is absurd applied to a forty-minute fix.

The measurable version takes a month and no meetings. Log every request that would have shipped the same week if an engineer sat in your building. Not the roadmap: a column added to an export, a threshold nudged, a report someone needs by Thursday. Three or more a week for a month and coordination has become your largest line item.

Context now costs more than instruction

Take a brief you sent recently and mark each sentence as instruction or context. In year one nearly all of it is instruction. Two years into a live product a brief reads “same as the November rule but exclude the reseller accounts, and the Ontario ones bill a month behind.” Free to someone who sat through the last four months of your business. An hour of writing and a round of clarification to someone who did not.

We hold that context by keeping the same two people on an account and writing decisions down. But we hold it as a service, and it decays: an account that goes quiet for a quarter comes back to different availability. An employee accumulates it involuntarily, by being in the room when the decision is made.

The product became a system of record

There is a moment when software stops being a thing you built and starts being the thing the company reads. Finance closes the month out of your database. A dispute is settled by opening your audit log. Another team’s integration breaks if you rename a column. Most teams notice this about six months late.

A retainer can carry infrastructure, with a stated response window, and ours does. The honest limit: a good external team acknowledges in hours inside business days, because your incident competes with other clients for the same attention. An employee responds in minutes.

You need compliance answers in hours

Enterprise procurement asks a narrow, boring set of questions. Where is customer data stored, who can read it, how long is it retained, and show us. Under an agency that is a request, a queue and an engineer who goes and looks. Under an employee it is often answered in the meeting.

Decisive when a security review sits on the critical path of your largest deals, because answer latency becomes revenue latency. Not decisive at all if nobody has ever sent you a questionnaire, and this is the signal most often claimed early.

The signals it is not time, and they are more common

The build has a defined end

Hiring to finish a project with an end date converts a cost that stops into a cost that does not, at the point of maximum uncertainty about what follows launch. The related trap is hiring to rescue something late: a new engineer on an unfamiliar codebase is negative capacity for weeks.

Nobody can manage an engineer

The objection we press hardest and the one founders dismiss fastest. An engineer hired into a company with no engineering management does not become senior by being alone. They become the person who decides everything and is reviewed by nobody.

What is missing is not supervision, it is a second opinion. No code review. No check on whether the architecture survives the next feature. No calibration on whether six weeks was reasonable, because the only person who could judge is the person who said it. Two years on you have a codebase one human has read, the single-point-of-failure problem from our comparison of in-house, agency and freelance delivery, except now it is an employee and the exit options are worse. The fix is not to hire two people. Rent the reviewer function: a fractional technical lead a few hours a week is cheap next to a second salary.

One product surface, and it is stable

A single application with a settled feature set and three or four real changes a quarter will not fill a job. The most common failure of a first in-house hire is not incompetence, it is under-employment, and it breaks two ways. Either they leave inside a year because the work was smaller than the interview implied, or they fill the time building the platform they would like to work on: a design system nobody asked for, a framework migration, an abstraction over one use case.

Neither is a character flaw; it is what a capable person does with three spare days a week. If you cannot write down twelve months of work somebody else would agree is worth doing, the problem is retainer-shaped.

The reason is cost

Year one in-house is almost never cheaper than an agency. Year three almost always is. Our own estimate, itemised in the article linked above, puts a first senior full-stack hire in the United States near $242,000 across year one once burden, recruiting, ramp and management time are counted, roughly $10,300 per delivered engineering week. Year two falls to about $6,800. If you cannot say with a straight face that this system still matters in two years, the arithmetic has not turned.

What the first hire actually costs

The part that is not salary

The US Bureau of Labor Statistics measures this directly. In its Employer Costs for Employee Compensation release for March 2026, private-industry employers paid an average of $32.60 per hour worked in wages and salaries and $14.01 in benefits, with benefits at 30.1 percent of total compensation. That is roughly 43 percent on top of wages before a laptop, a seat in every tool the team uses, or an hour of recruiting. Software salaries sit above that average, so treat the percentage as the shape of the problem rather than your number. A $145,000 offer is not a $145,000 decision.

Equity is not a discount

Equity moves cost off the monthly P&L and onto the cap table rather than removing it. The mistake is treating a grant as a way to hire a $145,000 engineer for $110,000. It buys someone who wants to be an owner, a different candidate from the one you were briefing for, and if you would be unhappy giving away the percentage the candidate will price that gap in cash.

The lead time nobody schedules around

Our own estimate, consistent with the arithmetic above: six to twelve weeks from job description to signed offer, plus two to eight weeks of notice. Call it fourteen weeks to day one, and that is the search going well rather than stalling and restarting.

Then the ramp. On a codebase somebody else wrote, a strong engineer makes their first meaningful independent change around week three to six and is autonomous nearer the end of the quarter. The engagement should end after that point, not at offer acceptance. Stop paying the agency on the start date and you buy a quarter of nobody being able to answer anything.

The first hire is the one most likely to be wrong

Not because first hires are worse people. Because there is no internal bar to measure against, the interview is run by people who cannot fully evaluate the answers, and no second engineer is there to notice.

The BLS Employee Tenure release for January 2024 put median tenure with a current employer at 3.9 years overall, 3.5 years in the private sector, and 2.7 years for workers aged 25 to 34. All-industry figures, not software-specific ones, but the direction is clear: a plan assuming your first engineer is still there in five years has one leg.

Two things reduce the risk cheaply. Put a paid, scoped task on the real repository into the process, four to eight hours, reviewed the way you would review any change. And put an engineer from the outgoing studio on the technical panel. We do that and do not charge for it, and the incentive is genuinely awkward, because we are helping choose the person who replaces us.

What happens to the codebase during the handover

The freeze. Work stops during the search because nobody wants to spend agency money on a system about to change hands. Three months of nothing looks like a saving and is not: dependencies drift out of support and the new engineer inherits a system already behind on day one. Keep a maintenance floor running even if feature work pauses.

The rewrite instinct. A new engineer facing unfamiliar code will want to rewrite it and will have a sincere case. Occasionally they are right. Usually the code is unfamiliar rather than bad, and the case is strongest exactly when someone understands the system least. We take that judgement apart in how to judge a codebase you inherited. The defence is to give the new hire something new, adjacent and small to own in month one, so the first thing they ship is theirs.

The loss of why. The code survives a handover. The reasoning does not. Why this table is denormalised, why that webhook retries three times and then queues, which of two equivalent libraries was chosen after the other lost data in staging. That is what a handover exists to move, and it is the part a document dump never contains.

How a studio hands over well, and what to demand

Four artefacts and one overlap. Ask for them in the contract at the start, not in the exit conversation, for the same reason we argue for naming handover as a deliverable in fixed price versus time and materials.

• Repository ownership, from the first commit. The code lives in your GitHub or GitLab organisation, owned by an account you control, with the studio holding write access as a member. If the repo is transferred to you at the end, it was never yours. Open the owner list today and check whose name is on it.
• Cloud and third-party account ownership. Hosting, database, error tracking, analytics, payment processor, domain registrar, app store listings, in your name and on your billing details. The pattern that hurts later is accounts created under an agency email with your card attached, covered in switching development agencies without losing your codebase.
• Architecture notes written as decisions. Not a diagram. A short record per significant choice: what was decided, the alternatives, why the loser lost, and what reversing it would cost. A tenancy model is the classic example, and the reasoning behind one is the shape we set out in choosing a multi-tenant architecture.
• A runbook that has been tested. Deploy, roll back, rotate a secret, restore a backup, re-run a failed nightly job, and who to contact at each vendor on which plan. The test is the part that matters: in week one the new engineer performs a deploy and a restore from the runbook alone, with the studio engineer watching and not touching the keyboard.
• A paid overlap, four to eight weeks. The new engineer writes and the studio reviews, the reverse of the arrangement until then. It is the only mechanism we know that reliably transfers the why rather than the what.

One more, and the cheapest: ask for the list of things the studio knows are wrong, so the new engineer does not spend a month finding the shortcuts one at a time.

What this costs on our side

Our published rate card, not a range invented for this article. A scoping sprint is $3,500 for a week, credited in full against a build that starts within thirty days. Our minimum for a build is $7,500, and most projects we take land between $18,000 and $45,000. After a build, a support retainer starts at $2,500 a month and ongoing product work runs $3,500 to $6,000 a month. Those figures are estimates in US dollars, not quotations; the quote that follows scoping is fixed in writing before kickoff.

The part relevant here is what should happen to that retainer after you hire. It should shrink each quarter, from delivery to review to occasional advice, and then stop. If it has not moved a year after your engineer started, either the hire is not working or we have made ourselves comfortable. Ask which. A retainer nobody has audited in a year is a subscription rather than a service, and that applies to ours.

The compressed decision

Hire when three or more small changes a week would ship same-day with someone in the building, when briefs have become mostly context, when the system is what the company reads to know what is true, and when a compliance answer in hours has revenue attached. Wait when the build has an end, when nobody can review an engineer’s work, when there is one stable surface and under a year of real work, or when cost in year one is the argument.

Then plan fourteen weeks to a start date and another quarter to autonomy, keep the maintenance floor running through the search, and buy the overlap. Take repository and account ownership now rather than at the end.

If you are somewhere in the middle, the useful thing to send is not a job description. Send the four-week log of small changes and tell us what is actually urgent, and we will say whether the honest answer is a hire, a smaller retainer, or two more quarters of the same. How we engage is on the services pages, the builds on our work page.