Every day, LinkedIn delivers a fresh batch of software companies from India, Pakistan, Cambodia and various other corners of the world into my inbox.
The messages are usually remarkably similar.
Their teams are highly skilled and their rates are highly competitive. They can build websites, mobile apps, enterprise software, AI platforms, cloud solutions and, if given sufficient notice, probably a replacement for the International Space Station.
The only small issue is that they are pitching all of this to somebody who already sells software development, IT consulting and digital projects himself.
In other words: I am not their customer, I am their competition.
At the very least, I would recommend spending thirty seconds reading a LinkedIn profile before launching the sales pitch.
But the funny thing is that these messages do not actually annoy me because they are sales messages. They annoy me because they remind me of a rather expensive lesson I learned more than twenty years ago.
Been there, done that ?
Back in 2004, I spent several months in India trying to do exactly what many European companies were dreaming about at the time.
The idea seemed brilliant. Build a development operation, leverage highly skilled local developers, reduce costs and scale software delivery. Everybody wins.
At least that was the theory.
The reality eventually cost me around €100,000, but looking back, I would call the project not a failure.
Expensive, certainly. Frustrating at times, absolutely. But failure implies that nothing useful came out of it, and that would not be true. What I learned during those months still influences how I think about software projects today.
The interesting part is that the problem was never technical competence. Quite the opposite.
Many of the developers I worked with were exceptionally intelligent, motivated, very professional and hard-working. No doubt about that.
If you put them in a room with a difficult technical challenge, they would often find solutions I would never have considered myself.
And yet the collaboration slowly drifted into a swamp of misunderstandings, rework, assumptions, lots of crying and everly increasing frustration.
At first I blamed language, that seemed logical. After all, English was not my native language and it was not theirs either. Surely, that had to be the problem.
But after a while I realized language was only the visible part of the iceberg. The challenge was cultural. Not better, not worse, just different.
Different assumptions about how requirements should be interpreted, and especially different way to communicate about them. Their views on what constituted a MVP and approach to planning, architecture and decision making.
The strange thing was that nobody was wrong.
If you asked either side why they had done something a certain way, the explanation usually made perfect sense. Unfortunately, software projects are pretty backfiringly when everybody is making perfectly reasonable assumptions, that happen to be different.
What I discovered is that software is not really built from code, but built from shared understanding.
Code is the easy part, but understanding what the client actually wants, is where projects succeed or fail.
And that is exactly where my grand outsourcing adventure ran into a wall: I could not successfully transfer twenty years of accumulated assumptions, instincts and working methods into another culture, another language and another way of thinking.
Nobody was at fault, it simply did not work.
Re-try in 2026
Twenty-two years later, I find myself wondering whether I should try again.
Artificial Intelligence has changed everything. Translation is better. Documentation is better. Communication is faster.
Requirements can be refined, reviewed and challenged before they ever reach a developer. In theory, many of the barriers that existed in 2004 should be significantly smaller today.
In fact, I already have a potential lead, and yet I hesitate. Surely, because I am a burned child (?).
Or maybe because every single LinkedIn message I receive from an offshore software company somehow manages to reduce my confidence instead of increasing it.
If your sales process cannot distinguish between a potential client and a direct competitor after a brief profile review, what exactly happens when somebody hands you a 50-page requirements specification?
That question keeps coming back to me.
The blant truth today is an Irony
The truly ironic part is that I need fewer developers today than I did back then. Where I once needed teams, I now often need two AI systems, a browser and enough coffee. AI has dramatically reduced the distance between idea and execution. That means, offshore development has become simultaneously more attractive and less necessary.
And perhaps that is the biggest irony of all.
Twenty-two years ago I was convinced that offshore development was the future. But today I am no longer sure.
What I am sure about is this: Cheap software is rarely expensive because of the code.
Cheap software becomes expensive because understanding is expensive.
And understanding remains the hardest thing to outsource.