Should I build or buy software?
Buy when the problem is common and an existing product fits your process well enough, such as accounting, email or a standard CRM. Build when the workflow is what makes you different, when no product fits without heavy workarounds, or when per-seat or per-use fees grow faster than the cost of owning it.
Last updated
A simple test
- 1Is this workflow part of how you win customers? If yes, lean build.
- 2Does a product cover most of what you need without changing how you work? If yes, lean buy.
- 3Will licence or usage fees grow sharply with users or volume? Compare the total cost of ownership over several years.
- 4Do you need control over data, hosting or compliance that products do not offer? Lean build.
- 5Do you have, or can you hire, people to run and change it after launch? If not, lean buy.
The middle path
Most systems mix both: buy the commodity parts, like login, payments, email and analytics, and build the part that is specific to you on top. Another common path is to start with a product, learn what you really need, then build once the workarounds cost more than the build.
Check it for your case.
Common follow-up questions.
Is building always more expensive?
Up front, usually. Over time it can be cheaper if licence fees scale with your growth or the product forces costly workarounds.
What about AI tools: build or buy?
Buy general assistants. Build when the AI must use your own data, follow your process or run inside your product.
What hidden costs does buying have?
Integration work, customisation, training, price rises and the cost of switching later.