Sooner or later every growing business asks the same question: should we buy software that already exists, or have something built for us? Both can be the right answer, and both go wrong when chosen for the wrong reason. This note gives a way to decide that does not depend on a salesperson's opinion. We build custom software, so you should weigh our view with that in mind; the checklist below is written so that it can tell you to buy.
Start with the job, not the tool
Write down, in plain sentences, what the software has to do and for whom. Include the unglamorous steps: who enters the data, who approves it, what happens when something is wrong. A tool is only a good fit if it fits the real process, not the one on the sales page. If you cannot describe the process yet, the first step is not to buy or build anything. It is to map how the work happens today.
Is this work a commodity, or does it set you apart?
Some work is the same in every business: accounting, payroll, email, a basic website, scheduling a meeting. Many mature products do these well, they are maintained by someone else, and building your own would be a poor use of money. Other work is how you win customers: a particular way of quoting, a booking flow that suits your trade, a rule set that is unlike anyone else's. When the process is part of your advantage, forcing it into someone else's idea of the workflow can quietly remove that advantage.
A useful rule: buy what is common, build what is yours, and connect the two.
Questions that decide it
How well does the product fit today?
List your must-have needs and test them against a trial of the product, with your own data and the people who will use it. If it covers most needs and the gaps can be handled by a small change in how you work, buy it. If you would have to bend core processes around it, or the gaps need workarounds in spreadsheets, that is a signal.
What is the real cost over time?
Compare the total cost over three to five years, not the first invoice. For a product, count the per-user subscription as the team grows, paid add-ons, setup and training, and the work of connecting it to other tools. For custom software, count design and build, hosting, security updates, support and the changes you will certainly want later. Neither is always cheaper: a subscription is cheap to start and can grow steadily, while a custom system costs more at the start and then follows your needs.
How often will the process change?
If your rules change every few months, you need software you can change quickly, either a configurable product or something built to be changed. If the process is stable and standard, a product will do.
Where will your data live, and can you leave?
Ask how you export all of your data, in what format, and what happens to it when you stop paying. Lock-in is not only a technical risk; it changes the balance when the supplier raises prices or closes the product. With custom software, ask the same about the build: who owns the code, who can run it, and whether another team could maintain it if you part ways. Agree this in writing before work starts.
What does it have to connect to?
Software that cannot exchange data with your other tools creates double entry and mistakes. Check for a documented API, the integrations you need and the cost of building the missing ones. Sometimes the right answer is a product plus a thin piece of custom integration.
Who will look after it?
Every system needs an owner on your side, and a plan for security updates, backups and support. A product has a supplier doing this for you. A custom system needs the same care from whoever built it, or from your own team, and that cost belongs in the comparison.
The middle routes
- Configure a product. Many tools allow custom fields, rules and workflows that cover most of what a business needs without any code.
- Product plus integration. Keep the standard parts in a product and build only the missing connection or report.
- Start small. Build the first version of the one process that matters most, learn from real use, and add to it. This limits risk much better than a big specification for everything.
- Prototype before you commit. A clickable design, tested with the people who will use it, is far cheaper to change than finished code.
Warning signs on either side
- A product demo that never uses your data or your hardest case.
- A vendor who cannot say how you export your data.
- A quote for custom software with no description of what you will see, and when, along the way.
- A request to build everything at once rather than in steps you can try.
- A decision made because "everyone uses it" or because "we want it to be ours", with no description of the problem.
A short decision guide
- Describe the process and who uses it.
- Decide whether it is a commodity or a source of advantage.
- Trial the best two or three products against your hardest real cases.
- Estimate three to five years of cost for the best product and for a custom build.
- Check data export, ownership and integration for both.
- If a product fits with small changes, buy it. If the process is yours, or the workarounds cost more than a build, plan a small first version.
If you want a second opinion before you spend, that is a good moment to talk to someone who builds and does not only sell. Advice should be yours to use with any team, including the one you already have.