Custom software vs off-the-shelf: how to decide what to build
Most of what your business runs on should be bought. Accounting, payroll, email, a CRM for a sales team that sells the way most sales teams sell: these are solved problems, and paying a developer to solve them again is a poor use of money. We build custom software for a living and we still say this in most first conversations.
The interesting decisions sit somewhere else. Most companies run on a set of SaaS tools held together by spreadsheets, exports, copy-paste and one person who knows how it all fits. That middle layer is where custom software usually earns its keep, and it is rarely where people start looking.
Buy what is commodity, build what makes you different
If a process works the same way at your competitors, buy software for it. If the way you do it is part of why customers choose you, or the off-the-shelf version forces your team to work around it every day, that process is a candidate for custom software. Most decisions come down to that test.
A useful question to ask about any process: if we did this exactly the way everyone else does, would a customer notice?
For invoicing, the answer is almost always no. For the engine that prices a job the way your best estimator would, it might be yes. The same goes for a scheduling system that knows which crews hold which certifications, or a client portal that shows the three numbers your customers call you about every week. Those are the places where generic software makes you more like everyone else.
The real cost of SaaS is licences you do not use and work you do by hand
Subscription costs are easy to see and easy to underestimate. Zylo’s 2024 SaaS Management Index, built from its customers’ spending data, found that organizations used only 49% of the licences they paid for. For the large companies in that dataset, unused licences averaged $18 million a year.
The same report counted an average of 15 duplicate apps for online training, 11 for project management and 10 for team collaboration inside a single organization. More than a third of the apps were shadow IT, adopted without IT’s involvement.
Smaller companies have the same pattern at a smaller scale. A second project tool appears because one team did not like the first. A forms product gets added for one workflow and never removed.
The cost that never shows up on an invoice is the workaround. Each tool does most of the job. The rest happens in exports, spreadsheets and data typed from one screen into another. It costs staff hours, and it produces errors that customers see: a wrong delivery date, a quote built on last month’s prices, an invoice sent twice.
Run a workaround audit before deciding anything
Spend a week listing every place where someone moves information between systems by hand. That list tells you more than any feature comparison, because it shows where your current tools stop and your team’s effort begins.
For each item, write down:
- Which systems the data moves between.
- Who does it, and roughly how many hours a week it takes.
- What breaks when that person is on holiday.
- Whether a customer sees the result, for example in a quote, a delivery date or an invoice.
Sort by hours and by customer impact. The top five are your shortlist.
Some of them will turn out to have cheap fixes: a setting nobody switched on, a native integration between two products you already pay for, a better template. Fix those first. What is left after that is the honest case for building something.
Most good answers are hybrid
Keep the system of record and build around it. Your accounting platform, CRM or ERP stays where it is, and custom code connects it to the rest of the business through its API: an integration, an internal tool, a customer portal or an automated workflow. The vendor maintains the commodity part, and your own logic lives where it matters.
This is the shape most of our custom software and API work takes. A small service that syncs orders between two systems and applies your pricing rules can remove hours of rekeying a week without replacing anything.
Before committing to this approach, read the vendor’s API documentation closely. Check rate limits, which records are exposed, whether it supports webhooks, and whether API access sits on a higher pricing tier. A weak API can turn a two-week integration into a fragile one.
When a full custom build makes sense
A full build is worth it when the process is central to how you compete and the market does not offer a good fit. In practice we see a handful of signals, and two or more of them together usually justify a serious look.
- The process is your product, or a large part of why customers buy from you.
- You have outgrown configuration. You moved to an enterprise tier to unlock customization and you still work around the tool.
- Per-seat pricing grows faster than the value, especially when customers or field staff need access.
- Data residency, retention or audit requirements are hard to meet with the vendors available to you.
- The glue between your tools has become larger and more fragile than the tools themselves.
When it does not
Custom software freezes a process into code. If the process is still changing every few weeks, wait. Run it on a spreadsheet and existing tools until it settles, then build the version you know works.
Two other situations call for caution. The first is when nobody inside the company will own the software after launch. Custom systems need someone who decides what changes, a budget for maintenance and a clear path for bug reports. Without an owner, a good system decays into the next legacy problem.
The second is when an existing product does nearly everything and the gap is preference. Learning to work the way a well-designed tool expects is often cheaper than building your own version of it.
Answer these questions before talking to a developer
A developer can only scope what you can describe. Clear answers to the questions below will make any conversation with a software team faster and any estimate more reliable, whoever you end up working with.
- What task or decision gets faster, and for whom?
- How is it done today, step by step, including the workarounds?
- What does the current way cost in hours, errors or lost deals?
- Which systems does the new software need to read from and write to?
- What is the smallest first release that would be useful on its own?
- Who owns it after launch?
If you have worked through these and want a second opinion on what to build and what to keep buying, tell us about it. We will be straight with you if the answer is a better-configured SaaS tool.
Sources
- Zylo, 2024 SaaS Management Index, via PR Newswire, 2024.