Companies that outsourced software development did so at two very different moments, and conflating them is why most example lists teach nothing useful. A founder paying a dev shop to build a first product and a corporation moving three thousand staff to a supplier are not the same decision, and the lesson you can take from one does not transfer to the other.
The other problem with these lists is that the claims get repeated until nobody checks them. Every case below names the vendor, the year, the arrangement and what the company did afterwards, and each one is attributable to a primary source or a named piece of reporting. One widely circulated example has been removed because it turned out not to be outsourcing at all.
Which startups outsourced their first build?
Four well-documented startups used outside builders before they had an engineering team: Slack had MetaLab design the product and brand, Calendly had the Ukrainian firm Railsware build its early product, WhatsApp used a contract developer found on RentACoder for the iPhone side, and AppSumo paid a low-cost contractor to wire existing code to PayPal.
What unites them is scope rather than ambition. In every case the founder knew precisely what they wanted built and contracted a narrow, well-defined piece of it. None of them delegated the decision about what the product should be, which is the distinction that makes these examples repeatable.
| Company | Who built it | When | What was delegated |
|---|---|---|---|
| Slack | MetaLab | circa 2013 | Product UI, brand, mobile app, marketing site |
| Calendly | Railsware, Ukraine | 2013 to 2014 | Early product development |
| Contract developer via RentACoder | 2009 | iPhone client, while the founder built the backend | |
| AppSumo | One low-cost contract developer | circa 2010 | Connecting found PHP code to a PayPal flow |
Calendly is the most instructive of the four because the founder has described it in his own words. Tope Awotona told the SaaS Club podcast that the engineers he first brought on were in Ukraine, that it was a dev shop, and that he flew out to meet them, and Forbes reported that he emptied his savings to fund it rather than raise first.
Why delegation works at this scale, and where it stops working, is argued properly in our guide to the benefits of outsourcing.
Which enterprises outsourced at scale?
Five large organisations moved substantial technology operations to suppliers: Nokia to Accenture, Citigroup to TCS, Unilever to Accenture, Toyota Motor Europe to Infosys, and the BBC to Siemens. These were not product builds. They were transfers of existing operations, usually including the people who ran them.
The numbers are the point. Nokia announced plans to move about 3,000 employees, as recorded in Nokia's SEC filing from April 2011. Siemens acquired BBC Technology and around 1,400 of its employees under a ten-year framework Siemens valued at 2.7 billion euros in its own annual filing.
| Organisation | Supplier | Year | Arrangement |
|---|---|---|---|
| Nokia | Accenture | 2011 | Symbian software activities, about 3,000 staff, announced via letter of intent |
| Citigroup | TCS | 2008 | Sale of its India BPO captive, plus $2.5bn of services over 9.5 years |
| Unilever | Accenture | 2006 | Seven-year master services agreement across 25 European countries |
| Toyota Motor Europe | Infosys | 2013 | Four-year managed service, 150+ applications, pan-European support |
| BBC | Siemens | 2004 | Ten-year framework, BBC Technology sold with about 1,400 staff |
A correction worth noting, since the error is widespread. The Citigroup arrangement is routinely described as application development. The TCS announcement describes process outsourcing attached to the sale of a BPO captive, which is a different kind of deal with different lessons.
What did these companies do afterwards?
The startups brought the work in-house once the product mattered enough to own, while the enterprises kept their suppliers for the contracted term and renegotiated rather than reversing. Neither group treated the arrangement as permanent, and neither treated it as a failure to be corrected.
That asymmetry is the most useful thing on this page. For a startup, external building is a bridge across the period when the product is uncertain and an engineering team is unaffordable. For an enterprise, it is a transfer of something that already works and is no longer differentiating. The exit looks different because the purpose was different.
The pattern in each case:
- Slack, Calendly and WhatsApp all built internal engineering teams once the product found its market
- The external work was replaced or absorbed, not discarded as a mistake
- Nokia, Unilever, Toyota and the BBC ran multi-year contracts to term
- Enterprise deals transferred people rather than merely tasks, which makes reversal expensive by design
What separates the startup pattern from the enterprise pattern?
Startups outsource what they cannot yet afford to own, enterprises outsource what they no longer need to own, and the risk sits in opposite places. A startup risks delegating the thing that was supposed to differentiate it. An enterprise risks losing the operational knowledge that made the transferred system maintainable.
The practical implication is that advice drawn from one group misleads the other. "Start with a small pilot" is sound startup guidance and almost meaningless to an organisation moving 3,000 staff. "Protect the knowledge transfer" is essential enterprise guidance and irrelevant to a founder paying for an MVP.
Which arrangement fits which situation, including where staff augmentation sits against a full project transfer, is covered in our comparison of delivery model choices.
Why do these examples get misquoted?
They get misquoted because the lists circulate faster than anyone verifies them, and a claim repeated across enough pages starts reading as established fact. Skype is the clearest case. It appears on most outsourcing example lists, including the earlier version of this page, and it does not belong on any of them.
The Estonian engineers behind Skype were co-founders holding equity, not an external supplier under contract, and Skype's own filing ahead of its planned public offering makes no mention of Estonia. Calling that outsourcing stretches the word past usefulness. The same looseness produces the Citigroup error above, where a process outsourcing deal becomes an application development deal through repetition.
A test for any example you are shown. Ask who the supplier was, what year it happened, and what document says so. An example that cannot survive those three questions is a story, not evidence, and it should not be in a business case.
What can you take from these cases?
Take the shape of the arrangement rather than the outcome, because the outcomes depended on circumstances you do not share. What transfers is the discipline: a narrow defined scope, a named supplier, a known duration, and a decision made in advance about what happens at the end of it.
Every case above shares those four properties, which is precisely why they are documented well enough to verify. Engagements that go badly tend to be the ones where scope was open, duration was indefinite, and nobody decided in advance who would own the result. The mechanics of running the arrangement are covered in our outsourcing guide.
Finding a partner with comparable evidence
The useful question to ask a prospective partner is not whether they have case studies but whether those case studies name the client, the year and the scope. Most do not, for reasons that are usually contractual and occasionally not.
Our matching process evaluates partners on delivery evidence of that standard and returns one whose record genuinely matches the work you described.
