Sooner or later a growing business hits the same question: do we buy software that already exists, or pay for something made for us? The honest answer is that there are three options, not two. You can buy a product and use it as it comes, you can keep a standard product and configure it and connect it to your other systems, or you can build custom software. Many poor decisions come from treating it as a choice between only the first and the last.
What are the three options, really?
- Buy: you adopt a product such as an accounting package, a booking tool or a CRM, and change your habits to match it where it differs from how you work
- Configure and integrate: you keep a standard product for the parts that are the same everywhere, then adjust its settings, add extensions and connect it to your other systems so data moves without retyping
- Build: you commission software shaped around a process that no product handles the way you need
The middle option is the one people skip, and it is often the right one. A standard product carries the heavy, boring parts: tax rules, payment handling, security updates, years of fixes. A small amount of custom work around it can then cover the one thing that does not fit. The service page on custom software development compares these routes factor by factor.
How standard is the process?
Start with the work, not the software. Payroll, bookkeeping, email, scheduling and invoicing are done in much the same way by thousands of businesses, and products for them have been refined against all those businesses. If your process looks like the common one, a product has probably solved it better than a one-off build could, and building your own is rarely worth it.
Ask how your process differs, and be specific. "We do things our own way" is not an answer. "Every job has a three-stage approval that depends on the customer's contract terms" is. When the differences are small, change the process. When the differences are the reason customers choose you, keep reading.
Is it part of what makes your business different?
Software that supports a competitive difference is worth owning. Software that merely keeps the lights on is not. A distributor with a unique way of quoting custom orders has a reason to build the quoting tool. The same distributor has no reason to build its own email or accounting.
A useful test is to imagine a competitor using the same product you are considering. If that would cost you nothing, the product is a utility and you should buy it. If it would erase an advantage, you are looking at something to keep control of.
What does it have to connect to?
Integration needs often decide more than features do. Count the systems the new software must exchange data with, and check how each one allows it: a documented interface, scheduled exports, or only a screen a person looks at. A weak interface leaves staff copying figures between windows, the problem you meant to remove.
This is also where the hybrid option earns its place. Connecting two good products with a small custom layer is usually a smaller and safer job than replacing both. If you are weighing automation on top of those connections, how to find business processes worth automating with AI helps you rank the candidates first.
Who owns the data, and how do you leave?
Ask this of every option, including a build. For a product, find out how you export your data, in what format, and whether the export includes history and attachments or only the current records. For a build, the equivalent is whether the source code, the documentation and the hosting accounts are in your name. A tool you cannot leave is a dependency, whoever made it.
Try the exit before you need it. Export a sample from the product you are considering and open it. If the result is unreadable, or cannot be loaded into anything else, you have learned the real cost of switching.
What does it cost over time, and who keeps it running?
The price on the first quote is the smallest part of the story. We do not give prices in articles like this, because the same label covers very different projects, but we can list the factors that belong in any comparison:
- Subscriptions that grow as you add people, records or features, and how often the vendor changes its terms
- Setup, configuration and the staff time spent learning a new tool
- Integration work, and the upkeep when either side changes its interface
- For a build: hosting, security updates, backups and the support arrangement after launch
- The cost of changing your mind: migrating data out, retraining and any period of running two systems
Maintenance deserves its own question. A product has a vendor whose job is to keep it current. Custom software has whoever you arrange: the firm that built it, another developer, or your own staff. If the answer is "nobody in particular", do not build. Insist on a repository you control and written operating notes, so another developer can pick the work up. How much custom software development costs goes deeper on each factor.
How do the three options compare?
| Factor to check | Buy a product | Configure and integrate | Build custom |
|---|---|---|---|
| Choose it when | Your process is common and a product matches it | A product covers most of the work and one or two gaps remain | The process is a competitive difference and nothing fits |
| First step | Trial it with real data and your real staff | List the gaps and the systems that must exchange data | Write down the users, workflows and what is out of scope |
| Main risk | Staff work around it and keep the old spreadsheet | Connections break when either side changes | Scope grows, and nobody is left who understands it |
| Who keeps it running | The vendor, plus your administrator | The vendor for the product, someone you name for the connections | The builder or another developer, under a written arrangement |
| Sign you chose wrong | Daily workarounds and an exported copy of the data in spreadsheets | More time spent on the glue than on the work | You rebuilt something a product already did well |
What are the warning signs on each side?
You are probably buying something you will fight when:
- The demo needed a long list of "we can set that up" answers to cover your core process
- Your best staff keep a private spreadsheet beside the product to get real work done
- You pay for features nobody uses so that one feature can be switched on
- Exporting your own data requires a support ticket or a fee
You are probably building something you could have bought when:
- The first requirements list reads like the feature page of an existing product
- The process is the same as everyone else's, and only the screens would look different
- The reason is dislike of a subscription and not a gap in what the product does
- No one can say who will maintain it in a year
We build custom software, so you could fairly suspect us of leaning toward a build. We try not to. Our service page says plainly that if a product already covers nearly all of your needs, you should buy it and spend the difference on configuration.
What if you built something and it is not working?
It happens, and it is rarely a reason to start over. Our write-up of an internal project, how we built our own client portal, covers a system Credantic built for itself, not for a client. It lists the questions to put to any custom build: how the data of one customer is kept apart from the rest, how sign-in works, what is recorded and how the system is run.
For software that already exists but is struggling, the safer pattern is to replace one piece at a time while the rest keeps running, starting with the part that causes the most pain. A review of the code, the hosting and the documentation tells you what to keep. Sometimes the answer is to retire a custom tool for a product that has caught up, which is a fair outcome.
What should you do next?
Write a one-page answer to each question above for the process you are worried about, then place it in the table. Most processes land clearly in one column. If yours sits between two, that usually points to the hybrid option. When you want an outside view before committing, our custom software development page explains how we scope a project, including how we tell you when the better answer is to buy.