When do you need your own engineers?

The decision

You built your product with a vendor. It worked. Now you have real users, a roadmap, and a growing feeling that every change takes too long or costs too much. The question is whether it's time to hire your own engineers, and it's high-stakes in both directions: hire too early and payroll eats runway the vendor would have spared you; hire too late and your product calcifies inside someone else's backlog while the market moves.

The questions that actually determine it

How often do you want to change the product — and how often do you actually get to?

This is the clearest ceiling signal there is. Count the product changes you wanted in the last three months. Count the ones that shipped. A small gap means the arrangement still works. A large gap means you've hit a ceiling — but check whether the ceiling is the vendor's capacity or your contract's change-request process. One of those is fixed by hiring. The other is fixed by a phone call.

What does a month of vendor engineering cost you now, honestly?

Most founders have never done this sum, and it decides more than any feeling does. Add three numbers: the retainer, the change-request invoices, and the hours you spend managing the vendor — priced at what your own time is worth. Typical vendor totals at this stage run ₹1.5–5 lakh/month ($1,800–6,000), and founders commonly spend 15–25 hours a month on top managing the relationship. Price those hours honestly. That line is often the largest one, and it never appears on an invoice.

Where does the knowledge live?

If every technical question routes through the vendor — why is the app slow, what would this feature cost, can we integrate with that — you don't own your product. You license it, emotionally if not legally. Knowledge concentrated outside your company is a risk that grows quietly and presents suddenly, usually the week the vendor reassigns the one developer who understood your system.

Can you feed a full-time engineer for the next twelve months?

A hire is a roadmap commitment, not a task list. Three months of backlog followed by silence is a firing, not a hiring. So write down, specifically, what your engineer would be doing in month 7. If you can't produce a credible answer, you're not ready — and it's better to learn that now than after the offer letter.

Your options, with honest costs and risks

Stay with vendors, renegotiated

Right when the ceiling is contractual, not structural. If changes are slow because every request crawls through an approval process or a retainer sized for maintenance, renegotiate first: a dedicated developer, weekly releases, direct access instead of an account manager. Cost stays in the ₹1.5–5 lakh/month ($1,800–6,000) band, probably at the upper end. The risk is what doesn't change — the knowledge still lives outside your building, and the vendor's incentives still favour billable change requests over iteration speed. This is the honest answer when your iteration gap is small and your monthly sum is well below an engineer's cost.

The first in-house engineer alongside the vendor

The overlap play, and my default. You hire engineer #1 while the vendor stays on, and for 1–3 months you pay both. A senior engineer in India costs ₹25–50 lakh/year ($30,000–60,000) plus 0.5–2% equity; in the US, $140,000–200,000 plus the same equity band. Add roughly 20% fully loaded for tools, recruiting, and overhead. Expect 2–4 months to hire and another 1–2 months to real productivity. The overlap window is double cost, and it's worth it — the alternative is your new engineer reverse-engineering a codebase with nobody left to ask. The risk is the hire itself: it's slow, and you can pick wrong. Hire for breadth and judgment, not stack keywords.

The full switch

In-house team, vendor exits. This is two projects, not one: the hiring project above, plus a handoff project — code, accounts, credentials, deploy process, tribal knowledge. I've written a separate guide on that handoff; the short version is that it needs its own plan, its own timeline, and a paid knowledge-transfer window. The failure mode is treating the switch as an event: vendor gone Friday, engineer starts Monday. That's how products end up undeployable for a quarter.

The math that decides it

Put the two numbers side by side. Fully loaded, engineer #1 in India is roughly ₹2.5–5 lakh/month ($3,000–6,000). If your honest vendor sum — retainer plus change requests plus your management hours — already sits in or above that band, and the iteration gap is real, the hire pays for itself before speed and ownership even enter the argument.

What I'd recommend

If the gap between wanted and shipped changes is large, your honest monthly sum is at or above a fully-loaded engineer month, and you can write a real month-7 job description — hire now, with 1–3 months of vendor overlap. Never a hard cutover.

Make engineer #1 a broad owner, not a specialist. You need a senior generalist who can deploy, debug, talk to users, and say no — someone who will own the whole machine. A brilliant narrow specialist is your third hire, not your first. When I ran my own SaaS company I made this hire with the vendor still on retainer, and it was the overlap, not the hire itself, that kept the product alive through the transition.

Watch for one trap: hiring to fix a vendor relationship that actually needed managing. If changes are slow because requirements arrive vague and decisions take two weeks on your side, an in-house engineer inherits the same problem at a higher fixed cost. Fix your side first; then re-run the numbers.

And if the month-7 test fails — if you genuinely cannot write down what the engineer does in month 7 — it's too early. Renegotiate the vendor deal, name a trigger ("when the sum crosses the engineer line for three straight months"), and revisit when it fires.

When this doesn't apply

• Pre-revenue with no iteration pressure. If the product changes once a quarter and no user is waiting, vendors are fine. Don't buy payroll to feel like a real company.
• Maintenance mode by design. A product you're deliberately keeping stable — cash cow, sunset, side business — doesn't need an owner on salary.
• A technical co-founder already in the building. That's a different question about roles, equity, and leverage, not about whether to hire — see the co-founder guide.
• Acqui-hire or venture-studio arrangements. A studio's team is structurally different from a vendor; the ownership and incentive questions change entirely.

In any of these, the framework above will give you a misleading answer. Get a human read on your specific situation instead.