Custom software beats SaaS in three cases: when the process it supports is part of what makes your business better than its competitors, when off-the-shelf tools force you to work around them, or when depending on a vendor costs more over time than owning and maintaining your own code. For everything else, such as payroll, email and standard accounting, buying SaaS is usually the right call. Most businesses end up with a mix: they buy the commodity layers and build the parts that set them apart.
Start with one question: does this function set you apart?
The most useful framing comes from software author Martin Fowler, who splits business software into two kinds: utility and strategic. Utility functions are things every business needs and simply wants to work. His example is payroll. For these, his advice is to buy the package and change your business process to match the software. Strategic functions are the ones where how you do the work is part of why customers choose you. For those, using the same software as your competitors limits how far you can pull ahead.
Fowler suggests strategic projects are a small minority, closer to 5 in 100 than 20 in 100, and that many organisations label too much as strategic. That is a useful check against over-building. If your team argues that every workflow is special, most of them probably are not.
He also notes that the categories shift. A strategic activity can become a utility once the market matures. More rarely, a utility becomes strategic when a company finds a way to compete on it. Review the split every year or two, not just once.
Questions to sort your functions
- Would a customer notice, or pay more, if you did this better than competitors?
- Is the process part of your sales pitch or your reputation?
- Do your staff keep spreadsheets or manual workarounds next to the SaaS tool because it does not fit?
- If a competitor bought the same SaaS product tomorrow, would you lose an advantage?
Answering "yes" to two or more suggests the function is strategic and worth a serious build assessment.
When buying SaaS is the better choice
SaaS is the better choice more often than custom software is. Buy when:
- The process is standard. Accounting ledgers, HR records, email and document storage work the same way across most businesses. Vendors spread development costs across many customers, and you benefit from that.
- Compliance is built in. Payroll tax rules, payment card handling and e-invoicing formats can change. A specialist vendor tracks those changes so you do not have to.
- You need it working soon. A configured SaaS tool can usually go live much faster than a custom system, which needs discovery, design, build and testing first.
- You have no one to own it. Custom software needs someone accountable for hosting, security updates and changes. If nobody will take that role, buy.
When custom software wins
Custom software is worth its cost in a narrower set of situations:
- The workflow is your advantage. If your quoting method, matching logic or style of talking to customers is why you win business, putting it into a generic tool flattens it into what everyone else does.
- You are gluing several tools together by hand. When staff copy data between a CRM, a phone system and a spreadsheet, the cost sits in the gaps between tools. A custom integration layer can remove that work without replacing the tools themselves.
- The vendor controls behaviour you need to control. Many platforms decide how a process behaves and let you adjust only the settings they expose. If you need logic they do not offer, you are stuck waiting on their roadmap.
- Per-seat or usage pricing scales badly for you. A tool priced per user or per transaction can become expensive as volume grows, while the cost of running your own code may grow more slowly.
- Data ownership matters. If the data a process produces is a core asset, you may want it in a system and format you control.
The real costs on each side
Both options cost more than their headline figure. Compare total cost of ownership over several years, not the first-year price.
Hidden costs of SaaS
SaaS spending is rising and is often poorly controlled. Zylo's 2025 SaaS Management Index covers more than 40 million licences. It found that average SaaS spend reached $4,830 per employee, up 21.9% year on year. The same report found that organisations wasted an average of $21 million a year on unused licences, and that two-thirds of IT leaders reported unexpected charges from consumption-based or AI pricing models. Smaller firms will see smaller absolute numbers, but the pattern applies at any size: subscriptions pile up, seats go unused and pricing models change underneath you.
Other SaaS costs to count:
- Price rises at renewal, when switching is hardest.
- Workarounds: staff time spent on spreadsheets, manual exports and entering the same data twice where the tool does not fit.
- Paid add-ons or higher tiers needed to unlock integrations or API access.
- The effort of switching if the vendor is acquired, changes direction or closes.
Hidden costs of custom software
The build is only the start. An article from the International Software Benchmarking Standards Group (ISBSG) cites the widely held estimate that maintenance accounts for between 65 and 85 percent of an application's total ownership cost. If that holds for your system, most of what custom software costs comes after launch: fixing defects, applying security patches, updating dependencies, adapting to changes in the APIs it connects to, and adding features as the business changes.
When you get quotes for a build, ask for an estimate of yearly running and maintenance effort as well as the build cost. A supplier who quotes only the build is showing you a small part of the picture.
Lock-in, portability and the right to change your mind
The UK Government's Service Manual gives guidance that applies well outside government. It asks teams to make technology choices that let them change their mind later. It also asks them to keep total cost of ownership down, which includes reducing the risk of being tied into long contracts with specific providers, and to use open standards at the interfaces between systems so that later changes are easier.
Lock-in works differently on each side:
- SaaS lock-in comes from your data, configuration and staff habits living inside the vendor's product. In the EU, the Data Act now reduces part of this risk. Its switching rules have applied since 12 September 2025 and cover SaaS such as CRM platforms and productivity suites. They cap the notice period for switching at two months and set a maximum 30-day transition period for moving data. From 12 January 2027 they largely remove switching and data egress charges. That makes leaving easier, but it does not move your workflows, automations or staff training for you.
- Custom software lock-in comes from depending on the developer who built it. If you do not hold the source code, the documentation and the hosting accounts, you have swapped one vendor dependency for another. Make ownership of all three a condition of the contract.
The middle path: buy the platform, build the edges
Few decisions are entirely one or the other. The most common outcome is a hybrid: buy SaaS for the commodity core, then build custom software around it where your business is different. Typical patterns include:
- Keep your CRM and accounting system, and build a custom integration that moves data automatically between them and your other tools.
- Use a managed AI or speech provider for the commodity capability, and build your own logic for the decisions specific to your business.
- Build a custom front end or customer portal on top of standard back-office systems.
This split shaped the design of an AI voice receptionist we built. It answers every call on the client's existing phone number, and speech-to-text and text-to-speech run through a single provider. A managed voice platform decides how your calls behave, so call classification and routing run on our own server, where the logic is ours to change. You can read more in the AI voice receptionist case study.
The same reasoning applies to AI tools in general. In a sales chatbot we built, the deciding factor was that a generic chatbot does not sound like the business it speaks for. So the system learns from the company's own past sales conversations rather than from a template. What made it valuable was the part specific to that business, not the generic capability.
A practical decision process
- List the functions involved and mark each as utility or strategic using the questions above.
- For utility functions, shortlist SaaS. Check API access, data export formats and renewal terms before you sign.
- For strategic functions, write down what the best SaaS option cannot do. If the gaps are minor, configure the tool and accept them. If they are central to how you compete, cost a build.
- Compare multi-year cost. For SaaS, count seats, tiers, add-ons, likely price rises and time spent on workarounds. For custom software, count the build plus ongoing maintenance, hosting and the internal time needed to own it.
- Test reversibility. Ask how you would leave each option in three years. Prefer the one with the cleaner exit.
- Start small. Build the narrowest piece that proves the value, such as one integration or one workflow, before you commit to replacing a whole system.
Warning signs either way
- You are customising SaaS so heavily that it has become custom software, but without the ownership. This is often the worst of both options.
- The case for building rests on "we are different" with no link to revenue, cost or customer experience.
- No one internally will own the custom system after launch.
- The SaaS vendor's API is limited or paywalled, so every integration becomes a negotiation.
- The build contract does not transfer the source code and accounts to you.
How Khive approaches it
Khive is a software engineering company founded in 2017, with a team of 50 engineers, building production software for businesses in the UK, US and EU. Alongside AI systems, we build integrations and custom software. We build each system in code and hand it over, so the client owns it. That addresses the developer lock-in risk described above.
If you are weighing a build against a subscription and want a second opinion on where the line should fall, send us a brief. Describe the process, the tools you use today and where they fall short, and we will tell you which parts we think are worth building.