A corporate spin-off happens when a company builds, in-house, a solution to one of its own problems and then gives it a life of its own, as a product, a business unit or a separate company. The best-known case is Amazon Web Services, AWS: the infrastructure Amazon built to support its own e-commerce became one of the company's most profitable businesses.
The lesson goes beyond the giants. Every company that has operated for years accumulates internal solutions to real problems, and some of them solve the same problem for other companies. Below, we explain what a spin-off is, what is publicly known about the history of AWS and how to look at the technology in your operation through that lens.
What a corporate spin-off is
The term is used in two senses. In financial markets, a spin-off is the formal separation of part of a company into another company, with its own shares. In the broader sense, which is what matters here, it is the path of an internal capability that gains autonomy to serve the market.
What characterizes that path:
- It starts from real pain. The solution was built to solve a problem the company itself had.
- It has already been tested in use. Before becoming a product, it ran in the operation, under volume and pressure for results.
- It gains its own focus. It leaves the position of a support function and gets its own goals, team and positioning.
An internal department serves the parent company. A spin-off serves outside customers, and that changes how it is managed, priced and developed.
How AWS was born inside Amazon
In the early 2000s, Amazon was growing fast and needed infrastructure that could keep up. According to the account the company and its executives have repeated in interviews and public writing, Amazon began organizing its technology into standardized services that internal teams could use without rebuilding everything for each project.
At some point it became clear that other companies had the same problem. They needed servers, storage and databases, and spent time and money setting all of that up on their own. In 2006, Amazon publicly launched AWS, with services such as S3, for storage, and EC2, for on-demand servers.
The rest of the story is well known. AWS became the leader in cloud infrastructure, a position that market research firms such as Synergy Research Group have recorded for years, ahead of Microsoft Azure and Google Cloud. And, according to the financial statements Amazon itself publishes, the segment accounts for most of the company's operating income, even though it is a much smaller slice of revenue.
It is worth noting the order of events. AWS came from the need to get Amazon's own house in order, and only later became a market opportunity. The product came from a solved problem, and not from a business plan drawn up on paper.
Why it worked
Seen from the outside, three factors stand out:
- The problem was common. Almost every company with a digital presence needed infrastructure. Amazon's pain was the pain of thousands of others.
- The solution had already been proven. It supported one of the largest e-commerce operations in the world before it was sold to anyone.
- The technology was built as a service. Standardized, documented and accessible through an API, it was ready to be used by people who did not know Amazon from the inside.
The third point is the one that matters most to anyone who is not Amazon. An internal solution only becomes a product when it was built with standards, documentation and a clear separation from the rest of the operation.
Other spin-off examples
AWS has company. Expedia started as a Microsoft division, launched in 1996, and became an independent company in 1999. Agilent Technologies came from the separation of Hewlett-Packard's measurement instruments businesses in the late 1990s. PayPal, bought by eBay in 2002, became an independent company again in 2015.
The cases have different origins. Expedia looks most like AWS: an initiative that grew inside the company and took on a life of its own. Agilent and PayPal are separations of businesses that already existed, done to give each side focus. In all of them, the logic was to give autonomy to something that needed its own focus to grow.
What a mid-sized company can learn from this
No mid-sized company is going to build the next AWS. The principle, however, holds at a smaller scale: technology built well for your own operation can become an asset, beyond a cost.
Technology as strategy, beyond support
When a company's system is treated only as an IT expense, the decision always goes to the cheapest option. When it is treated as part of the strategy, the question changes: does this system give us an advantage our competitor does not have? That question is at the heart of the choice between an ERP or custom software.
Not every system needs to be strategic. Payroll and accounting rarely set one company apart from another, and off-the-shelf software handles them well. The process that makes customers choose you, though, deserves technology designed for it.
Where to look for internal opportunities
A few questions help find candidates:
- Do we have an internal tool that solves a problem common in our sector well?
- Have customers, suppliers or partners already asked to use something we built?
- Is there a process where we are far better than average, supported by our own system?
- Have we solved an integration or a calculation that the market handles poorly?
A hypothetical example: a distributor that built its own delivery routing system, tuned to the rules of its sector, may find that other distributors in the region would pay to use the same tool.
What needs to be in place first
Turning an internal solution into a product requires a foundation:
| Requirement | Why it matters |
|---|---|
| Owned, documented code | Without it, you cannot sell it or evolve it with another team |
| Architecture separated from the operation | The product cannot depend on rules that only exist in the parent company |
| Security and data separation between customers | Each customer must see only what belongs to them |
| Dedicated team and budget | The product competes for attention with the core operation |
| Validation with outside customers | Internal use does not prove the market will pay |
The first item catches many companies off guard. A company that hired its system without securing ownership of the code cannot turn it into a product, and we explain what to check in our article on source code.
The possible formats
Not every spin-off needs to become a separate company. The most common formats, from lightest to heaviest:
| Format | How it works | When it makes sense |
|---|---|---|
| License to partners | The company grants use of the tool to a few customers or partners | To test whether anyone pays, without building a structure |
| Business unit | Its own team and goals, inside the same company | When there is demand and the product still depends on the parent company |
| Separate company | Its own legal entity, partners and management | When the product has a clear market and needs independent investment or focus |
Starting with the lightest format reduces risk. You can move up a step as demand appears.
The risks along the way
A spin-off also has costs. The team that looks after the product stops looking after the operation. Outside customers ask for support, contracts, service levels and constant evolution. And a product that goes badly can pull focus from the core business. That is why the safe step is to validate with a few outside customers before building a structure, just as AWS ran inside the house for years before going to market.
The question that remains
The AWS case shows that technology can leave the cost column and become the business itself. For most companies, the immediate gain lies halfway: systems built with standards, documentation and an owner make the operation faster today and keep open the possibility of becoming a product tomorrow.
Looking inward comes before building something from scratch. Which internal solutions already solve real problems, and which of them could serve other companies?
