Questions we answerHiring and headcount
When should a startup hire its first engineer?
When there is durable technical work, someone who can judge technical quality, and enough definition for an engineer to own something rather than wait to be told.
Free · a few minutes · starts from “We have a capability gap”
The short answer
When the technical work is durable rather than a one-off build, when somebody can judge whether the work is any good, and when there is enough clarity for an engineer to own an outcome rather than wait for instructions. Before that, contract or agency work is usually the better answer: it gets the thing built without committing to a hire you cannot yet assess. The hardest part is not the timing but the judging — a first engineer hired by people who cannot evaluate engineering is a coin toss with a year's salary on it.
The first engineer is a different hire from the second. There is no team to absorb a mis-hire, no existing standard to measure against, and often nobody in the company who can tell good work from work that merely runs.
That makes the sequencing question — when — less important than the assessment question. Most first-engineer regrets are about evaluation rather than timing.
Is it really this?
Worth checking before you spend anything. These are the signals that tend to tell the two apart.
Signs it is
- Technical work is continuous and on the critical path rather than occasional.
- You are losing more to context-switching with an external team than you gain in flexibility.
- Someone in the business can tell whether technical work is done well, or you have arranged for someone who can.
Signs it's something else
- The immediate need is one defined build with a clear specification and an end.
- Nobody can describe the technical direction, so the role would be direction-setting and not engineering.
- The product is still changing shape weekly and the specification would be obsolete before the notice period ends.
What's usually behind it
- A product that has outgrown no-code tools or an agency's attention span.
- Founders spending their week on delivery rather than on customers.
- A technical roadmap that now has more on it than one contractor can hold.
What people usually get wrong
- Hiring a generalist engineer to also be the technical leader, and getting neither.
- Assessing on enthusiasm and availability because nobody in the room can assess on craft.
- Handing the first engineer an undocumented agency codebase and no context, then wondering why the first quarter is slow.
The options, and when each one fits
In no particular order. Which of these fits depends on your situation, not on the question you typed.
Hire a permanent engineer
Technical work is durable and central, and quality can be judged somehow.
Contract or agency build
The need is a defined piece of work with a specification and an end.
Fractional technical leadership
The gap is judgement about what to build and who to hire, not building it.
When doing nothing is the right call
If the product is still changing shape weekly, waiting a quarter usually costs less than a mis-hire. Use it to get someone technical to review the current build and help define the role — that alone changes most first-engineer hires for the better.
What the diagnostic asks
- Whether the gap is capability, capacity or both.
- How central the work is to what the business does.
- Whether it could realistically be done outside the team.
- Whether a permanent hire is fundable, and how soon it is needed.
“I don't know” is always an answer. Nothing is assumed on your behalf.
The routes it weighs
Every diagnostic weighs all ten routes. These are the ones that tend to matter for this question — a description of the rules, not a promise about your answer.
Recruit
Recruit a new person for a durable, sizeable need that is central to the team.
Specialist support
Bring in a freelancer, consultant or specialist for a defined piece of work.
Outsource
Hand a defined, ongoing scope of work to an external provider.
Do nothing yet
Record the issue, set a revisit date, and decide what would change your mind.
Develop
Build the capability in someone already in the team, with time and support.
What changes the answer
- Work that is central and continuous strengthens the case for a permanent engineer.
- Work that is a defined build with an end date points at a contractor or an agency.
- Having nobody who can assess technical quality is an argument for getting help with the hire, not for delaying indefinitely.
Get your own read
A handful of short questions, then the strongest route for your situation, what's also credible, what we still don't know and what would change our view. No account, no setup.
Related questions
- Do I need a CTO or a lead developer?One sets technical direction and builds a team; the other builds the product well. Most early companies need the second and advertise for the first.
- Should I hire in-house or use an agency for development?An agency is right for a defined build with a specification and an end. In-house is right when the product is continuous and the context has to stay.
- Do I need a CTO?Not always, and not always yet. The question is what technical leadership the business needs over the next year or two — and whether that is a permanent seat, a fractional or interim leader, or capability grown from inside.
- We have a skills gap. Should I train, hire or bring someone in?It depends on how long you need the skill, how soon, and whether anyone in the team is close to it. Each answer points at a different route.
- Should I hire full-time or contract?Contract buys speed and information; permanent buys accumulation. The right answer depends on how durable the need is and whether you need the knowledge to stay.
- Can I afford to hire right now?Affordability is not the salary. It is the salary plus recruitment, onboarding, management time and the months before the person is productive — against what happens if you do not.