Why I won't outsource software development (again)
Reflections on building a software company
Happy Sunday!
If you’re like me, you can’t code much but want to build a software company.
And you’re going to quickly realize that building a good software product is so much more difficult than it seems. Software is complicated, nuanced, counterintuitive. Things that seem like they should be doable in a day take months. “Simple” adjustments break everything. It’s hard for non-technical and technical people to work together. And there’s a lot of BS out there - consultants writing about things that work in theory but not practice.
Still want to build a software product? You should. If there’s a the 21st century superpower, it’s the ability to lead product teams and build great software products. (Plus, software margins = $$$)
I’ve been in the early-stage software game for a few years after getting my MBA from Harvard. I’ve figured out everything I know about software from running face-first into problems. It’s the most effective way to learn, if not the most pleasant.
This week, I figured I’d rant about why I’m probably not going to outsource software development ever again.
As always, share your war stories and other topics you’d like me to cover.
The case against outsourcing your minimum viable product
Basically every piece of feedback I got from founders about last week’s article (What I wish I’d learned at Harvard Business School) referred to one sentence I wrote as an afterthought:
[Founders waste] thousands of dollars on contract engineering firms who prey on first-time founders.
One example is a text I got: “I wasted $150k in India on outsourced software development in my first startup and $50k in Ukraine on my second startup.”
Why doesn’t outsourcing work?
Understand this and you’ll avoid some pain on your own startup journey :)
TLDR: When I was 19, I used my broken Swahili to find a guide who’d help me climb Mount Kilimanjaro for cheap. I ran out of food before summiting and nearly died after going 72 hours on the mountain without calories. Don’t buy a service you don’t understand in a language you don’t know.
Reason #1: Outsourcing prevents responsiveness
Extreme luck aside, the first version of any product is going to be the wrong thing. Expect to learn something that invalidates at least one of your assumptions:
You didn’t understand the problem well enough when you started building
You’re solving the wrong problem
You’re solving the right problem the wrong way
You’re solving for the wrong buyer
etc.
This will happen. And when it happens, your success depends on how effectively you can respond.
But outsourcing prevents responsiveness. When I’ve outsourced product development, Step 1 has always been creating detailed product specifications: What should the developers build?
The problem is - I never really knew. But… designing interfaces was fun. Talking about user experience was fun. Nodding like I understood authorization was fun.
I’d invest weeks building the right specifications for that beautiful product. It was fun, exhausting, and totally counterproductive.
I’d wasted hours and dollars on unimportant details because outsourcing requires detailed specifications. At such an early stage, specifications are just flimsy hypotheses. And the second those hypotheses are invalidated, the resulting specifications are (mostly? entirely?) useless.
“Hey, Product Manager from Outsourced MVP Inc. Know those really detailed specifications we confirmed last week? And, know how we’re a startup that’s still searching for product-market fit? How much of a pain would it be if we totally redid 40% of our spec?”
Then come the spec rewrites (again, too detailed), sprint readjustments, invoice approvals… all the things that prevent rapid adjustment. And I’d begin to consider throwing everything out and starting from scratch… that might be faster.
In the early stages, responsiveness is survival. And outsourcing prevents responsiveness.
Reason #2: Software development is nearly unmanageable (for non-developers)
The only way I’ve been able to describe it is that software is complex in a non-linear way. The same feature can be designed and implemented in thousands of ways that can range from one day of development time to one year of development time. This complexity layers: Early choices make future features 10x easier or 1,000x harder to build.
I know all this. I also know that I can’t effectively assess how long a feature should take. I won’t know if a decision I’m making on Screen A will cause Screen B to take 20x as long to build. And my eyes glaze over whenever I hear the words “database structure” and “authorization”.
Worse, the curse of partial knowledge means the more I learn about software, the more likely I am to be wrong but think I’m right.
And yet I think that paying someone by the hour to build my software product is a good idea?
I can’t manage a software development team, and neither can you. The best we can do is trust smart developers to make good decisions when they’re fully informed.
Outsourcing to a development shop is attempting to manage the unmanageable. It’s information asymmetry on steroids. Paying a dev shop by the hour is the textbook definition of moral hazard.
Instead: How to build a software product
As a nontechnical founder, you can either hack together a MVP using mostly no-code tools or find a knowledgeable engineer you can trust.
No-code tools like Bubble are increasingly accessible and powerful. They’re also really cheap and fast ways to help you realize you don’t really understand what you think you’re building, you don’t know where the value is. You can also hack together different tools using Zapier, Google Sheets, etc. etc. etc.
If you can’t build your MVP in Bubble for a reason OTHER than Bubble’s technical or security limitations, you don’t know enough to be building a product at all.
On the other hand, if you decide to go the route of hiring a knowledgeable engineer you can trust, the surest way to make them hate you is to give them detailed specifications and treat them like “their job is to build, not think”. For some reason, developers don’t like being treated as if they’re working on a factory floor in the early industrial era.
A smart developer with enough context on what the customer is trying to achieve and the latitude to solve problems how she sees fit is a force to be reckoned with. More on working with developers in coming weeks.
Next week, I’m thinking about writing about agile, scrum, and other development management processes that work in theory but rarely in practice.
Send me your war stories in advance!
Rob