When Outsourcing Software Development Works, and When It Doesn’t

Three quotes are open on your desk for what you described in the same 400-word email. One is $18,000 in six weeks. One is $61,000 over four months. One is $185,000 and comes with a discovery phase you pay for before anyone writes code. You are not an engineer. You cannot tell whether the cheap one is a bargain or a disaster, and the expensive one has not explained why it costs ten times more.

So the question you typed into Reddit at 11pm was the blunt one: is outsourcing software development good or bad?

It is neither, and the honest answer is more useful than either. Outsourcing software development works when the software supports your business, and fails when the software is your business and nobody on your side can judge the output. Those two variables decide it. Not the country, not the rate card, not the agency’s case-study page. If your software is the product and you cannot tell good work from bad, you are not buying development. You are buying a lottery ticket.

The two questions that decide it

Is the software the product, or does it support the product? A booking system for your three physiotherapy clinics supports the product. The product is physiotherapy, and if the booking system is mediocre but works you still have a business. A scheduling SaaS you intend to sell to 4,000 clinics is the product, and every architectural shortcut becomes a ceiling on the company itself.

Supporting software has a “good enough” a non-technical person can verify: bookings go in, confirmations go out, nothing double-books. Product software has no such ceiling. It gets extended weekly for years by people who did not build it, and that quality stays invisible from outside until roughly month nine.

Can you write a specification, and can you judge the result? Two separate skills, and you need someone with both on your side of the table, paid by you. Not necessarily a co-founder; a fractional CTO at six hours a month qualifies. It cannot be the vendor, because asking them to grade their own homework is not a control.

Answered “supports the product” and “yes, or I can rent that judgement”? Outsource with confidence. Answered “the software is the product” and “no”? Fix the second answer before signing anything.

Where outsourcing software development reliably works, and where it fails

It works when:

  • The software supports the business. Internal tools, back-office automation, a CRM-to-accounting integration, a customer portal on an existing operation. Scope is knowable, done is testable by a normal human, and a 7-out-of-10 build is fine.
  • The thing already exists in a known shape. Rebuilding a legacy app whose behaviour is documented by the app itself, porting a web product to mobile, integrating a documented API.
  • You have technical judgement on your side. A first engineering hire, a fractional CTO, even a senior friend paid properly to read pull requests.
  • It is capacity, not ownership. You already have a team, standards, a repo and a definition of done, and need three more pairs of hands inside that system.

It fails when:

  • The product is software and nobody on your side reads code. You get something that demos beautifully, then learn its real quality when you try to change it.
  • You are still discovering what to build and you bought fixed-bid. Pre-product-market-fit work changes weekly, and a fixed price turns every change into a negotiation.
  • Cost is the entire reason. “I can’t afford a developer, so I’ll outsource” usually means the budget is too small for the outcome regardless of geography.
  • Nobody on your side owns it daily. Outsourced development consumes founder time, not zero time. Budget five to ten hours a week; allocate two and you get software that reflects two hours a week of thought.

You cannot outsource what you cannot specify

This produces most of the angry threads. Not fraud, not incompetence. A founder knows what they want, writes three paragraphs, and gets a literal implementation of those three paragraphs, which is not the thing in their head.

The scale is measurable. Bent Flyvbjerg and Alexander Budzier studied 1,471 IT projects and found an average cost overrun of 27%, which sounds survivable. The distribution is the problem: one in six was what they called a black swan, averaging a 200% cost overrun and a schedule overrun of almost 70%. The risk is not going slightly over. It is that a minority go catastrophically over, and nothing in the quoting process tells you which kind you bought.

You will also get Standish CHAOS failure statistics quoted at you. Treat those carefully. Eveleens and Verhoef showed in IEEE Software that the CHAOS definitions measure estimation accuracy rather than success, and can be gamed by inflating budgets: the same organisation with its forecasting bias inverted flips from a 5.8% success rate to 94.2%.

What to do instead of writing a longer feature list:

  • Buy discovery as a separate, small contract. Two to four weeks, its own price, its own deliverables, no obligation to continue, and you own the output. It is the cheapest test of these people, and the cheapest way to learn your idea needs reshaping.
  • Write the problem, not the solution. One page: who the user is, what they do today, what it costs them, what has to be true for this to be worth building. A vendor worth hiring pushes back. One who accepts your feature list without comment will build exactly it, then invoice you for the rework.
  • Define done in things you can personally test. “A receptionist with no training books a recurring weekly appointment for an existing patient in under 60 seconds on an iPhone” is an acceptance criterion. “Build appointment module” is a wish.
  • Rent the judgement, then run a paid trial. A fractional CTO at four to eight hours a month costs less than one bad month of development, and one small real feature built at full rate over two weeks teaches you more than six reference calls.

Co-founder, agency or contractor: what each actually costs

Hiring in-house in the US. The Bureau of Labor Statistics puts the median annual wage for software developers at $135,980 as of May 2025, salary alone. Its Employer Costs for Employee Compensation release for June 2026 shows benefits at 30.0% of total compensation for private industry workers ($14.07 of $46.89 per hour worked). Gross the median up on that basis and you are at roughly $194,000 a year loaded, before recruiting fees or equipment. For one developer.

Outsourcing. Accelerance’s 2026 rates guide, a survey of 60 software development partners worldwide, puts senior developer rates at roughly $31 to $41 an hour in Asia, $60 to $75 in Latin America and $64 to $76 in Central and Eastern Europe, with juniors at $24 to $31, $33 to $45 and $31 to $39. It is a vendor-run survey of self-reported agency rates, so treat it as a benchmark rather than gospel. It also reports rates falling year on year in all three regions.

Turn it into a year. A senior through an Asian partner at $36 an hour for 2,000 hours is about $72,000; the same seniority in Central Europe at $70 is about $140,000. Against $194,000 loaded for a US employee, the offshore gap is two to three times, not the ten times people imagine, and the nearshore gap nearly disappears once you stop carrying the hiring risk.

For a first version, a two-person pod for four months is 1,280 developer hours: $40,000 to $50,000 at Asian senior-plus-mid rates before design, QA and project management, so the engagement lands between $55,000 and $80,000. At Latin American rates the same pod runs $100,000 to $130,000. When a quote for a real multi-user product with payments and accounts arrives at $18,000, the arithmetic says someone is building far less than you think, staffing entirely with juniors, or planning to fund the rest through change requests.

The US independent contractor. To clear the BLS median while paying their own benefits and self-employment tax at a realistic 65% billable utilisation, an independent needs roughly $140 an hour. Anyone far below that is subsidised by other income, quietly offshoring your work, or about to take a salaried job mid-project.

The technical co-founder. Cheapest in cash, most expensive in every other currency: equity, control, and the inability to undo the decision cheaply. Carta’s analysis of 7,764 companies and 18,228 founders incorporated from 2019 onward found only 41% of two-founder teams split equity equally, so the folk wisdom about an automatic 50-50 is not what cap tables show. The real argument is not cost. It is that someone with ownership-level stakes is present for every decision, including the ones made at 2am in month fourteen. No contract buys that.

The hardest thing to find is someone who will tell you no

Founders who say the hardest thing to find is “a good developer” have misdiagnosed it. Competent developers are not scarce. Three other things are.

Someone who will tell you your idea is wrong. An agency is paid to build what you ask for, so every hour spent arguing you out of a feature is revenue they talked themselves out of. The default commercial behaviour is enthusiastic agreement, and enthusiastic agreement is the most expensive thing you can buy. Describe your scope and watch: a shop with real product people starts cutting.

Product thinking rather than ticket execution. A ticket executor asks what the button should say. A product thinker asks why the user is on that screen at all, and sometimes says the screen should not exist. Count the questions in your first call: forty minutes on your customers and ten on your stack is a different species from the reverse.

Continuity. Not the company surviving. The same individuals staying on your codebase, because institutional memory is most of what you are buying after month six, and it disappears without anyone breaching a contract. Get names, notice periods and a paid handover overlap in writing.

Five questions that reveal a shop’s real seniority

  • “What would you remove from this scope, and what is the riskiest assumption in it?” A senior answer cuts something and names an assumption worth testing cheaply. A junior answer restates your scope back to you.
  • “Tell me about a project where you advised a client not to build something.” Real shops have this story ready.
  • “In week six we find a core requirement was wrong. Walk me through what happens.” Listen for a conversation or a change-request process. Only one suits early product work.
  • “What is not included in this price?” The good answer is long and specific: hosting, third-party licences, app store fees, post-launch support, bug fixes after the warranty window, security testing.

Own the assets, and structure the deal so you can leave

The most expensive discovery here is rarely bad code. It is a founder learning, during a dispute or a handover, that they do not control what they paid for. Work through this before the first invoice.

  • Source control and cloud. The GitHub or GitLab organisation under your company account with you as owner, the vendor added as a member. AWS, Google Cloud or Azure under your billing, root credentials with you. Code lands in your repo from day one, not in a zip at the end. If production lives in an agency’s reseller account, they control your uptime and your data.
  • Domains, DNS and app stores. Registered to your company, with your email, in accounts you can log into. Apple Developer and Google Play enrolments under your legal entity.
  • IP assignment that actually assigns. Present-tense language (“hereby assigns”) rather than a promise to assign later, covering every individual and subcontractor who touches the work, surviving termination. US “work made for hire” wording alone is not sufficient for most software and does not travel well to contractors abroad. Check whether assignment is conditional on payment in full, and learn that before a dispute.
  • Licences and dependencies. A written list of every paid component (UI kits, charting libraries, map and messaging APIs) and whose account each licence sits in, plus the open-source inventory. Better you find a copyleft licence in there than an acquirer’s lawyer does.
  • Credentials, design files and AI tooling. Payment gateway, transactional email, SMS, analytics, error monitoring and CI in your company’s name. The editable Figma project, not PNG exports. And ask which coding assistants are used, and what the contract says about anything sent to them.

Then structure the engagement for optionality, because your first vendor choice is a guess. Pay for discovery separately. Tie milestones to acceptance criteria demonstrable in your staging environment, deployed from your CI, not to “Phase 2 complete”. Hold back 10% to 20% of each milestone until a 30-day stabilisation window closes. Write the exit clause while everyone is still happy, naming handover deliverables and a paid transition period at an agreed rate, with final payment contingent on them. And go month-to-month after the initial term, so the vendor earns next month.

Nobody budgets for year two

Your quote covers building the thing. It does not cover owning it, and owning it never stops. Dependency and framework upgrades, OS and browser changes that break code you never touched, security patches, expiring certificates, cloud bills, support for real users doing unexpected things. A common planning assumption is 15% to 25% of build cost per year just to keep software alive, before a single new feature. On a $70,000 build, $10,000 to $17,000 annually.

Decide who does this before launch. A retainer with the same vendor is easiest, which is why the handover clause matters; a different vendor inheriting the code is where every ownership decision above gets graded. The version where nobody does it ends with a founder hearing about the incident from a customer.

Questions founders ask next

Can I outsource the first version and bring it in-house later? Yes, but only if you set it up on day one: your repo, your cloud, a documentation standard, mainstream technology rather than the vendor’s in-house framework, clean IP assignment. Founders who plan it from the start usually manage it. Founders who decide in month ten usually rewrite.

Fixed price or hourly? Fixed price where scope is genuinely knowable: an integration, a migration, a rebuild of something that exists. Time and materials with a capped monthly spend while you are still learning what to build. A fixed price on an unvalidated product buys certainty about the wrong number.

How do I check references properly? Ask for a client whose project was cancelled or went badly, not just the happy ones. Ask what the final cost was against the original quote, who actually did the work, and whether the same people stayed throughout. Then the question that gets the truth: what do you wish you had known before signing?

AB7 Solutions works the staff augmentation side of this rather than the fixed-bid project side: named engineers you interview yourself, working in your repo, your cloud and your definition of done, the structure that stops the ownership and continuity problems above from starting. We also build websites, applications and APIs outright where that fits better. If you have a quote in front of you and want someone to read the scope, the IP clause and the handover terms before you sign, call +1 321 341 7733, email ab@ab7solutions.com or director@ab7solutions.com, or start at www.ab7solutions.com. If the right answer is to hire one person locally instead, that is what we will tell you.

Sources: U.S. Bureau of Labor Statistics, Occupational Outlook Handbook, Software Developers (median wage $135,980, May 2025); BLS, Employer Costs for Employee Compensation, June 2026; Accelerance, 2026 outsourcing rate trends (survey of 60 partner firms, self-reported); B. Flyvbjerg and A. Budzier, “Why Your IT Project May Be Riskier Than You Think”, Harvard Business Review, September 2011; J. L. Eveleens and C. Verhoef, “The Rise and Fall of the Chaos Report Figures”, IEEE Software, 2010; Carta, “How do co-founders actually split equity?” (7,764 companies, 18,228 founders).

Leave a Comment

Your email address will not be published. Required fields are marked *