Why outsourcing might be slowly killing you

The Weekly Roast is back. This week I’m burning down the outsourcing (body leasing) model that most software houses live by – and asking whether they’re building companies or just managing spreadsheets.

First, let’s define what a software project actually is – because the industry loves to blur these lines.

(1) PMI-based definition of a software project: it is a unique, time-bound effort undertaken to create a defined software product, service, or result – with clear scope, resources, and measurable outcomes.

(2) ISEE-based definition of a software project: it is a planned undertaking with defined objectives, constraints, and deliverables – governed by scope, schedule, budget, and quality standards- aimed at producing a functional software system.

(3) SWEBOK-based definition of a software project: it is a coordinated set of activities designed to deliver working software within agreed constraints of time, budget, and scope – with clear ownership and a measurable definition of done.

Notice what’s in that definition: ownership, accountability, outcome (and no word about outsourcing). Now look at how most software houses operate. And notice what’s missing. Go ahead. I’ll wait.

The bench problem: capitalism’s awkward silence

You hired 40 engineers. You have work for 31 of them. The other 9 are on the bench – drinking coffee, doing “internal projects” that will never ship, and quietly updating their CVs. The bench is expensive. So what do you do?

You panic. You take any client. At any price. On any terms. Outsourcing yuupi!
And that’s where the trouble begins.

Outsourcing: the “We’ll figure it out” model

Outsourcing sounds great in a sales pitch: We take full responsibility for your product. End-to-end. Turnkey. You sleep, we ship.

The reality?

• Your developer is embedded at a client for 18 months
• They know the client’s codebase, culture, and lunch preferences
• The client makes them a job offer
• You find out on a Friday afternoon via a resignation email
• Congratulations, you just trained someone for your competitor
• Of course, you can protect yourself with penalties for switching to a client. But can you really track down where your former programmer is currently working?

The risks nobody puts in the brochure:

• Brain drain – your best people get poached by the very clients you served
• Invisibility – as a company, you have no idea what your developer is actually doing day-to-day
• No product identity – you’re building someone else’s dream, not yours
• Single point of failure – one developer, one client, one relationship. When it breaks, it all breaks.

Body leasing vs. outsourcing

At least body leasing is honest about what it is. This is nicely named outsourcing 😛 There is no body leasing vs. outsourcing – there are the same. 🤣 You’re just a talent marketplace. A human API.

But let’s ask the uncomfortable question: if your business model is “we find smart people and rent them to others”… are you a software company, or a staffing agency with a GitHub account?

So how should the market actually work?

Here’s the roast’s real point – and it’s not just criticism, it’s a challenge.

The market should reward:

1. Product thinking over billing hours

Software houses should be building expertise in domains, not just stacking developers. A company that deeply understands e-commerce, or fintech, or logistics – and builds repeatable solutions – is infinitely more valuable than one that outsourcing “senior React devs.”

2. Defined project ownership

A real software project needs:

• a Product Owner (with actual authority)
• a defined scope (that everyone agrees on before the first line of code)
• a success metric (not “the client is happy”)
• post-delivery accountability (you ship, you own the outcome)

If a project is a collection of outsourcing developers or managers from different companies, what are the chances of success?

3. The consultant model, not the contractor model

The best software companies are moving toward being trusted advisors – shaping what gets built, not just building what they’re told. This protects the developer, the company, and honestly, the client too.

The uncomfortable truth about outsourcing

Most software houses aren’t really building a company. They’re building a spreadsheet – headcount in, billing rate out, margin in the middle. And when the market shifts, when a client leaves, when developers get poached – the spreadsheet falls apart.

The ones that survive? They stopped renting people and started building something. Because the bench problem is real. But the solution isn’t to rent your people out faster. It’s to build something worth staying for.

We believe that every software house should have at least one internal product. It forces you to think like a real company, gives developers something to be proud of, and creates an asset that doesn’t walk out the door when a contract ends. 

So… check out one of our products → sandtime.io
(Spoiler: we’ll be showing more soon.)

Ready to stop renting and start building?
So are we. Reach out. –> enterbeachmode@sanddev.com

PS. Click here if fancy to know more how we get stuff done.