Custom software versus off-the-shelf is the decision business owners get wrong in both directions. Some pay a developer to build what a CAD 40-a-month product already does. Others spend years bending a product to a process it was never designed for, and pay for it in staff time every single day. I build custom software for a living, so I have an interest here. I also turn down about a third of the projects that reach me, because a product would serve them better. This is the framework I use.
Buy it when
- The process is generic. Accounting, payroll, email, calendars, basic CRM, file storage. Thousands of businesses do these the same way, and the products are excellent and cheap.
- You are small and the pricing is flat. Per-seat pricing at five users is a rounding error.
- You have not done the process long enough to know what you need. A product teaches you the shape of the problem. Build later, once you know.
- It is not core. If a competitor using the same tool would not worry you, buy the tool.
Build it when
- The process is your business. How you quote, schedule, intake, fulfil or report is what customers actually pay for, and no product fits without contortions.
- You are paying for several tools plus a person to glue them together. That person is the real cost, and a small custom system usually replaces both the glue and one or two of the tools.
- Per-seat pricing has outgrown the value. Fifty users on a CAD 60 seat is CAD 36,000 a year, every year, for a tool you use a third of.
- You need it to connect things that do not connect. Custom integration is often the whole project, and products are bad at it by design.
- The workarounds have become a job. If someone's role is "making the software work", the software is not working.
The five-year comparison
Upfront, custom software is more expensive. Almost always. The honest comparison runs over the period you expect to use it, and includes the costs that do not appear on an invoice:
| Cost over five years | Off-the-shelf | Custom |
|---|---|---|
| Licence or build | Monthly fees, rising with seats and tiers | Build cost upfront, then hosting |
| Maintenance | Included, on the vendor's schedule | A few hours a quarter to a small retainer |
| Staff workaround time | Often the largest hidden cost | Near zero if built to the process |
| Integration | Limited to what the vendor offers | Whatever you need, priced in |
| Change | Wait for the roadmap, or cannot | Pay for the change, get it |
| Risk | Vendor price rises, feature removals, shutdown | Developer availability, unless handover is clean |
For a handful of users on a generic process, the product wins every time. For twenty people running a process that defines the business, the custom column is frequently cheaper by year three, and the staff time line is why.
The question I ask every business owner is: "Show me the spreadsheet." There is always a spreadsheet, the one that holds the business together, that only one person understands, and that every product you have bought fails to replace. That spreadsheet is the specification for your custom software. When it is small, leave it alone. When three people depend on it and it breaks monthly, that is the moment to build.
The hybrid most businesses end up with
This is rarely an either-or decision. The pattern that works: products for the generic functions, accounting, email, payments, storage, and a small custom core that holds the process nobody else has, connected to those products through their APIs. The custom part stays small, which keeps it cheap to build and maintain. The products stay in their lane, which keeps them cheap to license. Most of the systems I build for businesses are this shape, and the automation guide shows how the connections are usually where the first value appears.
If you build: how to not regret it
- Start with the smallest version that would genuinely be used. One role, one workflow, live in weeks. Grow it from real feedback.
- Choose boring, durable technology. Mainstream stacks like .NET, with a large pool of developers who can maintain them. The .NET guide explains why that matters.
- Own everything. Source code, hosting accounts, domains, credentials, in your name from day one.
- Insist on handover quality. Documentation and clean structure so another developer could take it over. This is the single control that removes the "depends on one person" risk.
- Budget for year two. Software that is used gets changed. A small support arrangement is normal and healthy.
If you buy: how to not regret it
- Check the export. Can you get your data out in a usable format? If not, you are renting your own information.
- Check the API. A product with a good API can be part of a hybrid later. One without is a dead end.
- Model the price at three times your current users. Tiers have cliffs.
- Ask who else in your industry uses it. Niche products for your sector often fit far better than general ones.
Related
I will tell you when a product is the right answer, because a client who buys the right tool on my advice comes back when they genuinely need something built. If you are stuck on build versus buy, describe the process and I will give you an honest read. Bring the spreadsheet.
Questions people ask
When is custom software worth it for a small business?
When the process it supports is how you make money and no product fits it without contortions, when you are paying for several tools plus a person to glue them together, or when a tool's per-seat pricing has grown past what building would cost. Custom software is rarely the right first move and often the right third one.
Is custom software more expensive than SaaS?
Upfront, yes. Over five years, frequently no, especially for businesses with more than a handful of users or a workflow that forces expensive tiers. Compare total cost over the period you expect to use it, including the staff time spent working around a tool that does not fit.
How long does custom software take to build?
A focused internal tool from an experienced developer often takes four to twelve weeks. Systems with many roles, integrations and edge cases take longer. The fastest projects are the ones that start with a small, real version and grow.
Who maintains custom software after it is built?
Whoever you agree with, so agree before you start. Many freelancers offer a support arrangement; others hand over clean code and documentation so any competent developer can pick it up. Avoid anything that only its author can maintain.
Can custom software integrate with the tools I already use?
That is usually the point. Modern custom systems connect to accounting, CRM, Microsoft 365, payment providers and almost anything with an API, which is how a small custom core can replace a tangle of disconnected products.