Hiring vs. outsourcing software development comes down to the shape of the work. Hire when you have two-plus years of continuous development that is core to how you win business; outsource when the work is project-shaped, spiky, or needs specialties you will use once. Most SMBs get the comparison wrong by weighing a salary against an hourly rate instead of fully loaded cost against total project cost. Run the honest numbers and the answer usually stops being a debate.
The Fully Loaded Cost of a Software Hire
A competent mid-level developer in the US runs roughly $120,000 to $160,000 in salary depending on region and specialty, and salary is the floor, not the cost. Payroll taxes, benefits, equipment, software and cloud spend, and workspace push the fully loaded figure to 1.25 to 1.4 times salary: call it $160,000 to $220,000 a year for someone senior enough to work without close supervision.
The one-time costs stack on top. A recruiter takes 20 to 25 percent of first-year salary, easily $30,000, or you spend months of internal time screening, and screening developers without a developer already on staff is its own famous trap. Then comes ramp: three to six months before a new hire is fully productive in your domain, at full pay the whole time. A realistic first-year figure for a $140,000 hire lands above $250,000 once recruiting and ramp are counted, and the recurring cost continues indefinitely around $180,000, rising with the market.
The harder problem for an SMB is not the money. It is that one developer is a fragile system. A solo hire means no code review, no coverage for vacations or departures, and an architecture that lives in one head. Median developer tenure across the industry runs only a few years, so plan on re-recruiting on that cycle. The real unit of a durable in-house capability is two people, which puts the honest ongoing commitment near $350,000 a year. That is the number to compare against, not a salary line.
What Outsourcing Actually Costs
Rates spread wide. Independent US contractors with real experience run $90 to $180 an hour. Established US firms bill $150 to $250. Offshore teams quote $25 to $75, with the caveat that the rate is not the cost, because communication overhead, timezone latency, and rework live outside the invoice. A meaningful build, a production-grade internal system or a customer-facing v1, typically prices in the tens of thousands to low hundreds of thousands depending on scope. That sounds enormous next to a salary until you notice it is bounded and stops when the project does.
Comparing hourly rates to salaries misleads in both directions. An in-house developer at $180,000 fully loaded costs about $87 per paid hour, cheaper than any agency on paper, but you pay for every hour: the slow weeks, the meetings, the ramp. Outsourced hours cost more each, and you buy only the ones you need, from a team rather than an individual, with no severance when the work ends. Neither option is cheaper in general. The volume and continuity of your work decides which is cheaper for you.
Two outsourcing costs belong in every estimate and rarely appear in one. Specification: someone on your side must know what the software should do, in detail, and the meter runs while you figure it out. And the afterlife: software needs maintenance forever, so a bid without a credible answer for who fixes bugs in month nine is not a complete bid.
Hiring vs. Outsourcing Software Development: When Does Each Win?
Hiring wins when the work is continuous, cumulative, and close to the business. If software is your product, or the plan genuinely calls for shipping improvements every week for years, in-house wins on iteration speed alone: the loop between a user complaint and a fix is measured in hours instead of a change-order cycle. Domain knowledge also compounds in employees in a way it never quite does in vendors. If you can write down two years of full-time work you are confident about, and fund two seats, hire.
Outsourcing wins when the work has edges. A defined build with a beginning and an end. A specialty you need once: firmware for one product, a machine-vision cell, a mobile app alongside your core system. Demand that spikes, where the alternative is hiring people you cannot keep busy in month eight. It also wins earlier than most SMBs expect, before the first hire, because an experienced outside team will choose the architecture and stack soberly, while a first hire tends to choose whatever they happen to know, and the company inherits that choice for a decade.
There is a tie-breaker people underweight: management capacity. An in-house developer needs technical management, someone to review the work, set direction, and notice a quietly failing project. If nobody in your company can do that, hiring imports a risk you cannot see. A good outside firm brings its own review structure, and that is part of what the higher hourly rate buys.
The Failure Modes of Each Path
The in-house disasters are predictable. The wrong first hire, usually a specialist where the role needed a generalist, discovered a year in. The solo developer who leaves with the system's logic undocumented, turning every future change into archaeology. The unreviewed codebase that works until it does not, with nobody left who can say why.
The outsourcing disasters rhyme with them. The specification thrown over the wall that returns months later as software that does what you said instead of what you meant, because nobody was checking weekly. The firm that sells you its senior people and staffs your account with juniors. The handoff that never lands: code in the vendor's repository, deployed on the vendor's accounts, documented nowhere, which converts a project relationship into a hostage situation. Every one of these is avoidable through contract terms, your repo, your accounts, work-for-hire IP from day one, plus a weekly demo cadence. But they are only avoidable before signing.
The Hybrid Most SMBs Actually Land On
The strongest pattern for a first serious system is sequenced rather than either-or: outsource the build with the handoff designed in from the start, then hire one person to own a working system instead of hiring them to create one from nothing. Owning is a smaller, cheaper, easier-to-hire-for job than building. The contract should read as if you will insource someday even if you never do: your repository, boring technology choices, written runbooks, and a vendor who expects to hand over the keys.
Between full-time and project-shaped sits ongoing fractional engineering, a reserved slice of a team's week indefinitely, which fits SMBs whose software needs are real but not forty hours wide. We compared these models in detail in contract engineering vs. hiring, and our engagement models page shows how we structure that spectrum ourselves. The decision, stripped to its bones: count the years of work you are sure about, price the two-seat commitment honestly, and let the shape of the work pick the model.
FAQ
How much does a full-time developer really cost per year?
Take salary times 1.25 to 1.4 for the recurring fully loaded cost, then add recruiting, often 20 to 25 percent of salary, and three to six months of ramp in year one. A $140,000 hire realistically costs over $250,000 in the first year and around $180,000 each year after. A durable capability usually means two people, not one.
Is offshore outsourcing worth the lower rates?
Sometimes, and it depends on the shape of the work more than the country of the vendor. Well-specified, self-contained builds can go well offshore. Exploratory work that needs daily conversation with your operations suffers, because the cost moves off the invoice and into slow iteration and rework. Whatever the rate, the same contract rules apply: your repo, your accounts, weekly demos.
Who owns the code when we outsource?
Whoever the contract says, which is why the contract must say you: work-for-hire IP assignment, code in a repository you control, deployments on accounts you own. Treat a vendor who insists on hosting everything under their own accounts as a red flag that has been priced into a low bid.
Can we outsource first and hire later?
Yes, and for most SMBs that is the right order. An outside team establishes the architecture, tooling, and documentation, and your eventual hire inherits a working, reviewable system instead of a blank page. Make the future handoff an explicit deliverable in the first statement of work.
If you are weighing a job posting against a project quote, the cheapest next step is a conversation about the shape of your work. Willowark's software engineering practice is built for exactly this middle ground, project builds designed for handoff plus ongoing fractional support, and we will say so when the honest answer is to hire. Contact us with what you are trying to build and the years of work you can see from here.
Relevant for Manufacturing, SaaS & Software Products, Local Service Businesses · Software Engineering
Engineering notes, monthly
One article like this a month. No pitch.
What we're building across the digital/physical boundary, what we learned, and one thing you can use. Double opt-in, one-click unsubscribe.

