When to stop building and buy
The signs that a custom system should give way to a product, how to make the switch without losing what worked, and what to keep custom.
The short answer
Custom software is built because nothing fits. Markets move, and years later a product may fit well, at a fee lower than the cost of keeping the custom system current. The signs that it is time to buy: the process has become standard rather than specific, a mature product covers what matters without heavy customisation, the maintenance and change costs of the custom system exceed the product’s fees, and the team’s time would produce more elsewhere. Keep building where the process is the business, where products would force you into their shape, or where integration and control matter more than features. The usual end state is not one or the other: products for the standard parts, custom for the specific, connected by integrations you own.
Signs it is time to buy
| Sign | What it looks like |
|---|---|
| The process is now standard | What was unusual when you built it is what every business does; products model it well |
| A product fits | Eighty percent covered out of the box; the rest is configuration or small integrations, not customisation |
| Maintenance exceeds fees | The yearly cost of keeping the custom system updated, secure and changed is more than the product would charge |
| Nobody wants to touch it | The custom system is stable but frozen; changes are feared; the builder has moved on |
| Better use of the team | The hours spent maintaining generic functionality could go to what makes the business different |
| Exit is acceptable | The product’s data export and terms let you leave if needed |
Making the switch
- Map what the custom system does: every screen, report, integration and quirk people rely on, from usage logs and interviews.
- Check the product against the map: covered, covered differently, needs a small addition, or dropped deliberately, item by item, with the people who use it.
- Check the exit: data export, terms, price protection, what happens if the product changes.
- Plan the data migration as a project: profile, map, rehearse, reconcile.
- Keep the specific parts as integrations or small tools around the product, in your repository.
- Run in parallel briefly, cut over, retire the custom system and its hosting, and redirect the team.
What to keep custom
The parts that are genuinely yours: the pricing logic competitors do not have, the workflow that is your service, the integration between the product and the other systems, the portal customers see. These are small once the standard functionality is in a product, they live in your repository, and they are where the team’s time now produces something distinctive. Products for the generic, custom for the specific, integrations you own between them.
What this means for you
Review your custom systems against the signs every year or two. Where the process has become standard and a product fits, map, migrate and switch, keeping the specific pieces as small custom parts around it. Where the process is the business, keep building. The best software estate is a set of products for the generic and custom software for what makes you different, connected by integrations you own, and it changes shape as the market and the business move.
Frequently asked questions
We built a CRM years ago. Should we move to a product?
Probably, if what you built is now standard CRM functionality and the product market has matured around it, which for CRM it has. Map what your system does that a product would not, migrate the data, and keep only the genuinely specific pieces as integrations or small tools around the product. The maintenance you free usually pays for the product several times over.
How do we avoid losing the features people rely on?
By mapping them first: every screen, report and quirk people use, checked against the product, with a decision per item: covered, replaced by a different way, rebuilt as a small addition, or dropped deliberately. The map prevents the switch that surprises the team, and it usually shows that the feared losses are fewer than assumed.
Is it a failure to replace something we built?
No. The custom system did its job when nothing fitted; the market caught up. Replacing it with a product and redirecting the team to what is specific to the business is the sensible next chapter, not an admission. The failure is maintaining a custom system out of pride after a product would serve better.