When to hire your first full-time engineer

The first engineering hire gets talked about like a milestone, which it is, and like an obviously good idea, which it sometimes isn’t. It’s a commitment of roughly a quarter of a million dollars in year one, a quarter of your calendar to find the person, and a chunk of your equity. Made at the right moment it’s the best money you’ll spend. Made early it’s the most expensive way to feel like a real company.

We sell an alternative to hiring, so we have a horse in this race. We’ve tried to write the version of this we’d want to read anyway, including the part where the answer is “hire.”

What the hire really costs

Quickly, because we’ve done this math in detail elsewhere: a $170k senior engineer costs about $236k in year-one cash once employer taxes, benefits, gear, and recruiting are in, plus 0.5% to 1% equity, plus two to three months of your attention to run the search, plus two to three months of ramp before full speed. And if the hire misses (some do), unwinding it costs a further quarter.

None of that is an argument against hiring. It’s the price tag that the signals below have to justify.

Signals you’re ready

The work is daily and permanent. Not “we have a lot to build this quarter.” Every quarter, from now on, indefinitely. Look at your roadmap 12 months out: if every month needs someone heads-down, the utilization math favors employment and you should act on it.

Somebody has to hold the whole system in their head. Products past a certain complexity need a person who wakes up owning the architecture, notices when a decision made in March starts hurting in August, and carries the context between everything. That continuity is the thing employment uniquely buys. You can rent capacity; owning context is harder to rent.

Speed of iteration is your strategy. If your plan is out-shipping incumbents with daily product changes informed by daily customer contact, you want that loop inside the building, full-time.

You can survive being wrong. A miss costs roughly $80k and a lost quarter. If that outcome dents but doesn’t threaten the company, you can afford the bet. If a miss would take a third of your runway with it, you’re gambling, not hiring, and there are better tables.

Signals you’re not

You’re hiring to feel legitimate. Investors, customers, and your own nerves all push toward headcount as proof of seriousness. Headcount is a cost, not a proof. Shipped product is the proof.

The work is a series of projects. Rebuild this, integrate that, launch the next thing, breathe. Project-shaped work has gaps, and with a full-time hire you pay retail through every gap. Priced honestly, spiky workloads favor booking capacity against need; the runway difference is worked out in burn rate math.

You can’t yet describe what they’d do in month four. Month one is always vivid: the rebuild, the launch. If month four is “uh, more features I guess,” you have a project, and projects end. Hire for the job that exists after the project.

You’re pre-product-market fit and burning to find it. This one’s uncomfortable. A full-time hire lengthens your monthly burn exactly when you most need runway to survive the search. Plenty of companies died with great teams and eleven months less runway than the pivot needed. Not a universal rule (see “speed of iteration,” above), but the default at pre-PMF should be keeping fixed costs mean and low.

The false choice worth naming

The question isn’t really “hire or don’t.” It’s “which parts of engineering need to be owned, and which need to be available?”

Ownership is architecture, context, judgment about what to build. Availability is hands: the six weeks of build, the deploy pipeline, the design pass, the QA sweep before launch. Founders who conflate the two either hire five people to secure availability (expensive) or try to rent ownership by the hour (doesn’t work; nobody rents caring).

A pattern we see work: secure ownership first, in whatever form fits your stage. Sometimes that’s a technical founder. Sometimes it’s the first hire, chosen for judgment rather than typing speed. Sometimes, for a while, it’s a fractional CTO. Then rent availability against the actual shape of the roadmap until the daily-and-permanent signal fires, and hire when it does. (The rent-a-team mechanics are covered in how to hire engineers by the week.)

This sequencing also quietly fixes the worst first-hire failure, which is hiring a great engineer and handing them a job that’s 40% product management, 30% infrastructure, and 30% talking to customers. Renting the overflow keeps the owned job coherent.

If you’re close but not sure: the two-quarter test

Write down what the engineer would ship in the next two quarters, month by month. Be specific enough that you could hand it to a stranger.

• If you filled six months easily and could keep going: hire. The utilization is there, and every month you wait costs you compounding context.
• If you filled two months and started padding: it’s a project. Book the project. Rerun this test in a quarter; the honest version takes twenty minutes.
• If you couldn’t fill month one concretely: the bottleneck isn’t engineering capacity yet. It’s usually clarity, and that’s cheaper to fix.

The test works because it prices the hire in the only currency that matters, which is work that needs doing. Salaries are abstract. “What ships in April?” is not.

In the meantime

Whatever you do about the hire, keep the bar high for what enters your codebase in the interim, because your first employee inherits it. Written briefs, reviewed PRs, a deploy pipeline, decisions recorded somewhere findable. That discipline costs little, transfers to every future team shape, and makes the eventual hire’s ramp weeks shorter.

If the interim answer involves booked capacity, the first week is priced to be a cheap experiment: scope one real deliverable, watch how it goes, and you’ll learn more about what your eventual hire needs to be than another month of job-spec polishing would tell you.