Should you hire a developer or hire a firm?

Most articles answer this with a cost comparison. A salary on one side, an hourly rate on the other, and whoever wrote the article wins.

Ignore all of it. Both sides fudge the math, and cost isn't the thing that determines whether this works.

Why the cost comparison is a trap

The in-house number looks clean. Salary, benefits, done. Except it isn't clean. There's recruiting time, the months before someone is productive in a codebase they've never seen, the equipment, the tools, and the manager's hours. According to Carta's compensation data, the average new engineering hire at a startup was around $189,000 in salary as of mid-2025. Every real cost sits on top of that.

The firm number looks worse. An hourly rate times hours is a big number, and it arrives as an invoice you actually have to approve, which makes it feel bigger still.

But here's the thing nobody puts in the comparison. When you hire a person, you are buying capacity. When you hire a firm, you are buying capacity plus the fact that they've already made expensive mistakes on somebody else's project. That never shows up in the build. It shows up in the week something breaks.

So let's ask a better question.

The question that actually matters: what happens when they leave?

Not if. When.

If one developer builds your system, that person becomes the system. They know why the invoice logic has that strange exception. They know which part of the database can't be touched. They know the workaround nobody wrote down.

When they leave, and people do leave, that knowledge leaves with them. What's left behind is code nobody can safely change, which is a much more expensive problem than a salary.

That risk is structural. It has nothing to do with how good the developer is. Excellent developers create this problem just as reliably as mediocre ones, and sometimes faster, because they build more.

This is the actual difference between the two options, and it's why the decision should be made on continuity rather than on rate. If you're already living this, our guide on what to do when a developer disappears covers the recovery steps in order.

When hiring in-house is right

Genuinely, sometimes it is.

If software is your product, hire. If you sell software, the people who build it are your company, and outsourcing that is outsourcing your business.

If the work never ends, hire. Continuous work is cheaper as a salary than as a rate. Any firm that tells you otherwise is selling.

If it's core to how you compete, hire. Your pricing algorithm, your proprietary process, the thing that makes you different. Own that.

When it's wrong: when you can't evaluate the person you're hiring. This is the trap for a non-technical owner. Your first developer is the one hire you're least equipped to judge, and you'll be judging them alone, with nobody to check their work. A wrong senior hire costs you the salary and then costs you a year.

When hiring a firm is right

When the work has a shape and an end. A system to replace, an integration to build, a mess to clean up.

When you need more than one skill. A real project needs someone who knows databases, someone who knows the front end, and someone who thinks about security. One person is rarely all three, and you can't hire three people for a six-month project.

When you need it to still work in year four. This is the one people underestimate. A firm that's been around a while is still there when something breaks in month forty.

We've been doing this since 1987, and the most common call we get isn't from a company starting something new. It's from a company whose system has outlived the person who built it.

When it's wrong: when nobody on your side can tell whether what's being delivered is any good. Handing your system to a firm you can't evaluate is the same trap as hiring a developer you can't evaluate, with more zeros. A good firm should tell you when you've reached the point where a salary is cheaper than their invoice.

The third option almost nobody writes about

The choice is usually presented as one or the other. It isn't.

You can have a developer and still bring in a team.

This is the arrangement that works best for a lot of companies your size, and it's strangely absent from the internet's advice. Your in-house person owns the day to day, knows your business, and answers the phone when someone needs a report changed. An outside team comes in for the things one person shouldn't do alone.

That looks like:

Your developer is good but alone. Nobody reviews their code. Nobody catches the thing they missed. Bringing in a second set of eyes isn't a criticism of them, it's how every functioning engineering team works.

A project too big for one person. They keep the business running while a team handles the replacement, instead of both things being half-done for a year.

Skills nobody has. Your developer is excellent at the thing they do and has never set up a database migration. That's normal. Nobody is good at everything.

Coverage. Your one developer takes a vacation, or leaves, and the business doesn't stop.

The best version of this is when the outside team's job is explicitly to make your in-house person better rather than to replace them. That means writing things down, reviewing their work honestly, and being clear that you're there to leave. That's what our staff augmentation work is for.

How to tell which one you are

Four questions, and answer them honestly.

Is software what you sell, or what runs your business? If you sell it, hire. If it runs the business, a firm is usually the better trade.

Could someone else pick up this work tomorrow if your developer quit? If no, you have a continuity problem, and hiring a second developer isn't the fastest fix.

Does the work have an end? A project ends. A product doesn't. Match the arrangement to the shape.

Can you tell good work from bad? If you can't, buy an assessment before you buy anything else, whether that's a person or a firm.

What we'll tell you

If you call us and describe a situation where hiring someone makes more sense than hiring us, we'll say so. We would rather tell you that than take on work that should be a salary, because the version of this that goes badly is the one where nobody says the quiet part.

A firm that will never tell you to hire someone is a firm that's optimizing for its own invoice. You'll find that out in month eight.

Frequently asked questions

Is it cheaper to hire a developer or a software firm?
It depends entirely on whether the work ends. Continuous, never-ending work is cheaper as a salary. A project with a defined shape and an end is usually cheaper as a firm, because you're not carrying the cost between projects. The comparison people usually run is misleading, because the in-house side leaves out recruiting time, ramp-up months, tools, and management hours, while the firm side arrives as one invoice that feels larger than it is.

What happens if our only developer leaves?
Whatever they knew and didn't write down leaves with them. What remains is code nobody can safely change, which is a far more expensive problem than a salary. This risk is structural rather than a reflection on the developer, and excellent developers create it just as reliably as anyone else.

Can we hire a firm and keep our in-house developer?
Yes, and for many small companies this is the arrangement that works best. Your in-house person owns the day to day and knows the business. An outside team handles what one person shouldn't do alone: code review, a project too large for one person, skills nobody on staff has, and coverage when that person is away. The best version has the outside team explicitly working to make the in-house person more effective rather than to replace them.

How do I hire a developer if I'm not technical?
This is the hardest version of the problem, because your first engineering hire is the one you're least equipped to evaluate, and once hired there's nobody to check their work. Either have an independent technical person sit in on the evaluation, or buy a short technical assessment before you buy anyone at all.