In-House vs Outsourcing Software Development: Hire, Freelancer, Agency or No-Code
In-house vs outsourcing software development, decided with numbers: break-even hours for a hire, who owns the code by default, and a decision table.
Luka Abramovic13 min read

On cost, in house vs outsourcing software development comes down to one number: the hours of steady work a single skill set will have each year after launch. Above that number, a hire costs less per hour than buying the same hours. Below it, buying them from a freelancer or an agency costs less. At the US median wage for software developers, $135,980 in May 2025 (Bureau of Labor Statistics), one hire costs about $198,500 a year once benefits are added. That equals 1,324 hours bought at $150 an hour, about 25 a week. The option that looks cheapest also has a legal default worth knowing before you pay anyone. In the US and the UK, code a freelancer writes for you belongs to the freelancer until a signed document transfers it.
This compares four ways to get business software or a product built: hiring employees, hiring a freelancer, hiring an agency, and building it yourself on a no-code platform. Cost figures are from the US, the ownership and contractor rules cover the US and the UK, and the hourly rates in the examples are illustrative inputs, not quotes from anyone.
The break-even hours for an in-house hire
A hire costs the same whether or not there is work that week. An outside rate is paid only for the hours used. So divide the loaded annual cost of a hire by the outside rate you were quoted. The result is the number of hours a year at which the two cost the same.
Loaded annual cost = salary × 1.46 + other annual costs
Break-even hours per year = loaded annual cost ÷ outside hourly rate
The 1.46 comes from the Bureau of Labor Statistics. In June 2026, employers paid full-time private-industry workers $54.00 per hour worked in total compensation, of which $36.97 was wages and salaries (Employer Costs for Employee Compensation). That ratio covers benefits and payroll costs for the average full-time worker, not developers specifically, so use your own payroll figure if you have one. "Other annual costs" covers what the ratio leaves out: recruiting fees, equipment, software licenses and the manager's time.
| Outside rate (illustrative) | Break-even hours a year | Hours a week | Share of a 2,080-hour paid year |
|---|---|---|---|
| $75 | 2,647 | 50.9 | 127%. On cost alone, a hire never breaks even against this rate |
| $100 | 1,985 | 38.2 | 95% |
| $150 | 1,324 | 25.5 | 64% |
| $200 | 993 | 19.1 | 48% |
The 2,080 hours are 40 a week for 52 weeks. Holidays and leave come out of that, so a hire's cost per productive hour is higher than the table implies, and the real break-even is harder to reach.
A build followed by maintenance is not steady work
An illustrative example. A first release needs 2,000 hours over 26 weeks, about two people full time, followed by eight hours a week of changes. In house, that means two hires at $397,062 a year, assuming both start on day one. Bought at $150 an hour, year one costs 2,208 hours × $150 = $331,200, about $66,000 less. Year two, at eight hours a week, costs 416 × $150 = $62,400, against another $397,062 to keep both hires.
Change one input and the answer flips. If the roadmap after launch keeps two people busy for 60 hours a week between them, buying year two costs 3,120 × $150 = $468,000, and the two hires are about $71,000 cheaper. The decision rests on what the work looks like after launch, not on the size of the first release.
To run it on your own numbers, type the labels into column A of a blank sheet and the values and formulas into column B. It works in Excel and Google Sheets.
| Row | Column A | Column B |
|---|---|---|
| 1 | Salary | 135980 |
| 2 | Total compensation ÷ wages | 1.46 |
| 3 | Other annual costs per hire | 0 |
| 4 | Outside hourly rate you were quoted | 150 |
| 5 | Steady hours a week for this skill after launch | 8 |
| 6 | Loaded annual cost | =B1*B2+B3 |
| 7 | Break-even hours a year | =B6/B4 |
| 8 | Break-even hours a week | =B7/52 |
| 9 | Cheaper on cost alone | =IF(B5>B8,"Hire","Buy the hours") |
Fill it in once for each skill the work needs, such as design, engineering and testing, rather than once for the whole project. A skill below its break-even is one to buy, even when the project as a whole is large.
Who owns the code when nobody signed anything
Copyright in code belongs first to the person who wrote it, unless the law gives it to an employer. That default decides what you own when the paperwork is missing, and it differs by option.
| Who wrote it | United States | United Kingdom | What to get signed |
|---|---|---|---|
| Your employee, as part of the job | You. Work prepared by an employee within the scope of employment is a "work made for hire" (Copyright Office Circular 30) | You. The employer is first owner of work an employee makes in the course of employment, subject to any agreement to the contrary (CDPA 1988, s.11). Computer programs are literary works (s.3) | Scope is the weak point. The Copyright Office's factors include whether the work was created during work time and as part of the person's usual tasks, so cover side projects in the employment contract |
| A freelancer | The freelancer. Commissioned work is made for hire only if it falls into one of nine categories, such as a contribution to a collective work, a translation or a test, and a signed agreement says so. A custom business application doesn't obviously fit any of them | The freelancer, as author and first owner (s.11) | A signed assignment of copyright. Both countries require a transfer in writing, signed by the owner (17 U.S.C. § 204, CDPA s.90) |
| An agency | The agency, for code its employees wrote. Code its subcontractors wrote belongs to them unless they assigned it to the agency | The same | A chain of title. The agency can only assign what it holds, so use the clause below |
| You, on a no-code platform | The platform's terms set what you hold, and the logic runs only on that platform | The same | Nothing to sign, but read the terms on ownership and export before building, and find out what still runs if you stop paying |
The practical trap is a freelancer contract that only calls the work "made for hire". For a commissioned work that label works only if the work also falls into one of the nine categories, and Circular 30 is blunt: "If a work fails to satisfy any of these requirements, it is not a work made for hire." Check that the contract also assigns the copyright. The milestone wording in our guide to choosing a development partner does that, and ties each transfer to a payment.
For an agency, add a chain-of-title warranty, because its assignment to you is only as good as the assignments it collected. This is a starting point for your lawyer, not legal advice:
The Supplier warrants that every person who contributed to the
Deliverables is either an employee of the Supplier acting within the
scope of their employment or has assigned to the Supplier, in a signed
writing, all rights in their contribution, so that the Supplier can
assign those rights to the Client under this agreement. The Supplier
will name each subcontractor in writing before that subcontractor
starts work and will provide copies of the signed assignments on
request.
If a freelancer already wrote code you rely on and nothing was signed, ask them to sign an assignment of the work already delivered, listing the repositories it covers. Do it now, while the relationship is good, and before anyone else relies on your ownership, such as a buyer or an investor.
When a long-running freelancer counts as an employee
Tax authorities look at how the work is done, not at what the contract calls it. A freelancer who works your hours on your priorities for years can end up treated as an employee for tax.
In the US, the IRS sorts the evidence into three categories (IRS guidance):
- Behavioral control. Does the business control, or have the right to control, what the worker does and how?
- Financial control. Does the payer control the business side of the job, such as how the worker is paid, whether expenses are reimbursed and who provides the tools?
- Type of relationship. Are there written contracts or employee-type benefits? Will the relationship continue, and is the work a key aspect of the business?
No single factor decides. If it stays unclear, either side can file Form SS-8 and ask the IRS to decide, which the IRS says can take at least six months.
In the UK, the off-payroll working rules, known as IR35, apply when the freelancer works through their own company, and they apply contract by contract (GOV.UK). Unless your business is a small one outside the public sector, you decide the worker's employment status for tax and must give them a status determination statement with your reasons. If they are employed for tax, the deemed employer, the party that pays their company, must deduct Income Tax and employee National Insurance and pay employer National Insurance. HMRC's check employment status for tax tool helps with the decision. For a small client outside the public sector, the worker's own company decides instead.
Run a short review this month. List every contractor with how long they have worked for you, their usual hours a week and who sets their priorities. Start with anyone who has worked near full time for more than a year on priorities you set. That is our rule of thumb for where to look first, not a legal threshold. For each one, answer the three IRS categories, or run the HMRC tool, and keep the answer on file. If the honest answer is that you direct their work like staff, either restructure the work around deliverables they control or make it a hire.
Which roles each option actually covers
A release needs more than one skill. This is who does each part of the work under each option, assuming one person when the option is a single hire or a single freelancer.
| Work | One in-house hire | One freelancer | An agency | No-code |
|---|---|---|---|---|
| Product decisions: what to build and which trade-off to accept | You | You | You, with input from their product lead if the quote includes one | You |
| Screen and flow design | The developer, or a second hire | The freelancer, or a second freelancer you coordinate | Their designer, if the quote names one | You, within the platform's components |
| Engineering | The hire | The freelancer | Their engineers | You or a colleague |
| Testing before release | The developer tests their own work | The freelancer tests their own work | A separate tester, if the quote names one | Whoever built it |
| Code review, meaning a second engineer reads each change | Nobody | Nobody | Inside the team | Not applicable |
| Cover for leave, illness or departure | Nobody | Nobody | The rest of the team | Colleagues, if it is documented |
Two rows matter most. Product decisions say "You" in every column, because no option supplies the person who decides. And with a single developer, whether hired or freelance, nobody reviews the code, since one person can't review their own work. With an agency, check that the people you meet are the people who do the work, using the questions in our partner-selection guide.
If you choose one developer, buy a review from an engineer who didn't write the code, before the first release and again every few months. Give them read-only access to the repository and this brief:
INDEPENDENT CODE REVIEW: [system name]
Time box: [half a day / one day]. Read-only access to [repository].
1. Set up and run the system on your own machine using only the
written instructions in the repository. Note every step that
was missing or wrong.
2. List the three changes you would make first, and why.
3. List anything that would stop you taking over this system if its
author were unavailable from tomorrow.
4. List any password, key or account that appears in the code or
that only the author holds.
5. Name the parts you didn't have time to read.
Item 1 tells you the most. Setup instructions that work only for their author are the first thing to fix, whoever built the system, and a failed setup is a cheap way to find that out before you depend on it.
Decision table: which option to start with
| If this is true | Start with | Why, and what to do first |
|---|---|---|
| Nobody on your side can judge technical work or make product trade-offs | Name the person who decides, before choosing anything else | This row overrides the others. Every option leaves product decisions with you, and a single developer reporting to nobody technical gets neither review nor direction. If nobody inside can take it on, buy that judgment first, from an agency with a product lead or an experienced technical adviser |
| One well-defined task in one skill, and someone on your side can check the result | A freelancer | One skill, a clear finish and a reviewer. Get the copyright assignment signed before the first payment |
| A first release needs product decisions, design, engineering and testing within months, and you have no technical team | An agency, with the product decisions kept on your side | One accountable team covers roles a single hire can't. Add the chain-of-title warranty above |
| One skill set will have steady work above its break-even hours for at least a year, and someone can manage engineers | A hire | Above break-even, the hire costs less per useful hour than buying the same hours |
| The process fits one platform's data model and limits, one person in the business will own it, and a day of failure is an inconvenience | No-code | The owner can change it the same day. Test the platform's record and usage limits against a year of your volumes first, and give every automation a second owner. In Power Automate, a flow whose owner leaves becomes orphaned and can fail if it uses connections tied to that person's account (Microsoft) |
| You want to build now and run it in house later | An agency build with a handover, and a hire who joins before it ends | The person who will own the system takes part in the handover. Make handover documentation a contract deliverable, as our partner-selection guide describes, and have the new owner run a release before the agency steps back |
| Code you rely on was written by a freelancer and nothing was signed | The paperwork, before any other change | A signed assignment of the work already delivered, listing the repositories |
Mixed answers are normal. One workable sequence is the first row, then an agency for the first release, then a hire once one skill set clears its break-even. Revisit the table when the work after launch settles, because that is when the break-even sheet has real numbers to work with.
If your sheet puts each skill below a hire and the first release needs more than one of them, bring the workflow you want to change and the filled-in sheet to a conversation. We'd start with who on your side makes the product decisions, because that answer narrows the options more than any rate does. Our custom business software page describes how we work with established businesses, and product development covers founders building a first release.