In June 2026 the founder of Callidus took development in-house. I had built that platform solo between 14 February and late April, a multi-tenant clinic SaaS for UK aesthetic clinics running on React, TypeScript, Firebase and Stripe Connect, then kept it in production through the handover. The transition landed at the right moment, and the reason had almost nothing to do with revenue.
Most writing about the first engineering hire for a SaaS company comes from people who sell recruiting. It anchors on MRR bands and headcount ratios, which are the two variables that tell you least about whether you are ready. The useful question is narrower and more uncomfortable. What specific thing has stopped happening because one person can only hold so much of the system in working memory at once?
When should you make your first engineering hire?
Hire when your shipping cadence has visibly slowed for two consecutive months and you can name the exact release the founder is personally blocking. Cadence is the right signal because it moves before revenue does. A product that shipped something every three or four weeks and now ships every nine has already lost the compounding value of frequent releases, and a good MRR month will not tell you that happened.
You know the feeling. A pull request sits for eleven days because you are the only person who can review it, and by the time you get to it the branch has drifted far enough that reviewing it properly means rebuilding the context you had when it was opened.
CRV's founder guide lists four readiness triggers and advises hiring when two or more appear at the same time: funding closed, founder bandwidth exhausted, the problem validated with clear 90-day metrics, and a technical roadmap past what the current team can execute. The pairing rule matters more than the list itself. Exhausted founder bandwidth on its own is a scheduling problem you can solve by cutting scope. Exhausted bandwidth plus a validated roadmap you cannot execute is a hiring problem, and cutting scope only postpones it.
Six months of revenue stability belongs on the list too, but as a floor rather than a trigger. Stable revenue never tells you to hire. It tells you that hiring will not kill you if the person takes four months to become genuinely useful, which is roughly what happens.
The hire makes you slower before it makes you faster
Your first engineer will reduce total team output for about a quarter, and planning around that is the difference between a hire that works and one that gets reversed. First Round Capital's ramp research, collected in OnboardingCost's 2026 engineering calculator, puts a typical software engineer at 50% productivity in month three, 75% in month six, and full productivity somewhere near month nine.
That is only half of the cost. The same research puts senior mentor drag at 20% to 40% of the most experienced engineer's working hours across the first three months. In a company where the most experienced engineer is the founder, those hours come straight out of the thing you were trying to fix. You hired because you were the bottleneck, and for one quarter you are a narrower bottleneck with a queue behind it.
Which is why the sprint you are currently behind on is the wrong reason to hire. A first engineer earns their cost on month-six throughput and later. If the pain has a horizon shorter than that, a contractor closes it faster and reverses more cleanly, and knowing what it costs to outsource SaaS development gives you a number to compare against a full-time offer instead of a feeling.
What AI tooling changed about the threshold
The threshold moved up rather than down, because the work one person can hold has grown faster than the work a second person removes. The VC Corner's argument that most founders hire too early points at the leanest startups reaching $1M ARR on one or two engineers, a configuration Ruben Dominguez calls implausible in 2020. He also prices a San Francisco senior engineer between $250,000 and $450,000 fully loaded, up to a fifth of a $2M pre-seed round spent before the product is proven.
Team shape shifted alongside team size. Value Add VC's 2026 analysis of headcount decisions reports new-grad engineering postings down 28% from the 2022 peak, with senior-to-junior ratios inverting from one senior per three or four juniors toward one senior per one or two. Work that used to be delegated downward is now generated and reviewed, which makes review capacity the scarce resource rather than typing capacity.
Two consequences for a founder about to hire. The first is that "we need more hands" has stopped being a coherent reason on its own. The second is that the person worth hiring is the one who can review and integrate code they did not write, including code a model wrote, and that is a different interview from the one most founders run.
Contractor, agency, or first full-time engineer?
Take a contractor for work with a known shape, an agency for a defined build with a deadline, and a full-time hire for open-ended ownership. Each of the three fails in a different way when you pick it for the wrong reason, which is what the table below is really about.
| Option | Best when | Real cost | What you give up |
|---|---|---|---|
| Stay solo, AI-augmented | Roadmap still changes weekly; product still moving | Founder hours only | Parallel workstreams, and any bus factor above one |
| Contractor | Work has a known shape and a finish line | Day rate, no ramp subsidy | Continuity of context between engagements |
| Agency | Defined build with a deadline, design included | Several times a contractor day rate | Direct control over implementation detail |
| First full-time engineer | Roadmap outruns one person for two months or more | $250k–$450k fully loaded in SF, plus ~1.5% equity | Reversibility, and a quarter of founder throughput |
The middle two rows collapse into one decision more often than founders expect, and agency versus freelancer for a SaaS MVP is the comparison that separates them properly. If the real question is internal versus external rather than which external, in-house versus outsourced SaaS development covers the ownership and continuity consequences this table skips.
One caveat on the first row. Staying solo is a defensible position for longer than it used to be, but it stops being defensible the moment a single illness or a single lost laptop can stop your product from shipping. That is a risk decision, not a productivity one.
What equity does a first SaaS engineer get?
The median first-engineer grant sits near 1.5% of the company on a standard four-year vest with a one-year cliff. CRV places that figure in the middle of a range that runs higher at pre-seed and lower by Series A as valuation and validation rise. Anchor on the round you are actually raising rather than on a number quoted by a founder three stages ahead of you.
The profile that survives contact with your codebase
Seniority here means having shipped this specific thing before, not years accumulated on a CV. CRV's phrasing is that a founding engineer already knows their craft, and that you should prefer the candidate who has done exactly what you need over the one whose experience merely looks adjacent. For a SaaS product that means someone who has carried multi-tenancy and billing edge cases in production, not someone who has read about both.
Pear VC's list of fifteen mistakes founders make building early engineering teams contains the one that compounds worst: lowering the bar on the first hire sets the ceiling for every hire after it, because B people know other B people. Your first engineer becomes your first referral source and your first interviewer.
Actually, that overstates the referral half. Plenty of strong engineers arrive through channels that have nothing to do with your first hire's address book. The part that holds regardless is the interviewing, because whoever you hire first will sit in the loop for everyone after them, and calibration is contagious.
The other trap on Pear's list is the premature title. Handing your first engineer the CTO title costs nothing on the day and a great deal eighteen months later, when the role needs someone who has run a team of twelve and the incumbent has run a team of zero. Give a title with headroom above it.
And if the stack itself is still in motion, resolve that before you hire, because onboarding someone into a codebase you are about to replace wastes the expensive months. Deciding which stack to build a SaaS MVP on is a cheaper problem to solve in week one than in month four with someone else's ramp depending on the answer.
How to run the hire without losing the quarter
- Write the 90-day outcome before the job description. One sentence naming what ships by day 90 that would not otherwise have shipped. If you cannot write it, the roadmap is not ready and neither is the hire.
- Source from your own network first. CRV and The VC Corner land in the same place here, and so does every founder I have worked with: warm introductions outperform job boards by a margin that makes the boards feel like a formality.
- Run two working sessions in your actual repository. Not a puzzle, not a take-home about linked lists. Give them a real open issue with real ambiguity in it and watch how they narrow it.
- Add one session that is only about reviewing code. Hand them a pull request with two subtle problems in it, ideally one generated by a model, and see what they catch and what they wave through.
- Design a shippable first week. Something small and in production by Friday. The ramp curve is real, and the first genuine deploy is what starts bending it.
- Put a written checkpoint at day 45. Named outcomes, discussed in advance, with the honest answer allowed. Most failed first hires were visible by week six and acted on in month six.
Step four is the one founders skip, and it is the one that has changed most. When the Callidus rebuild inherited a failed FlutterFlow attempt with around 200 unresolved errors, the expensive skill was never producing code. It was reading code that already existed and deciding which parts deserved to survive.
The number to write down this week
Open your commit history and find the dates of your last four releases. Write the gap between each pair. If those gaps are growing and you can point at the specific pull request that has been sitting for three weeks because only you can review it, the hire is already late and the ramp cost starts from a worse position every week you wait.
If the gaps are flat, the honest next move is a contractor for the next defined chunk of work and another look at this in a quarter.
So which release are you personally blocking right now, and what would have to be true for someone else to ship it without you in the loop?
