Custom or SaaS software: the math has changed

A Brussels-based technical installation company, heating and electrical work, about forty field technicians, runs a SaaS CRM for client management and invoicing. It works well. What doesn't work is scheduling interventions: no standard tool handles the specific logic their teams operate under (skills, zones, urgency levels). The real planning still lives in a shared spreadsheet, updated by hand every morning, sitting right next to the CRM that was supposed to centralise everything.

That's the symptom of a question every company digitising its processes eventually runs into: buy an existing solution, or build something custom. The question isn't new. The answer has changed.

Buying feels safe. Until it doesn't.

SaaS is available immediately, requires no large upfront investment, and maintenance is included. For a lot of processes, that's the right call, and no one should feel bad about buying a standard CRM or invoicing tool.

The problem shows up on the processes that make a company what it is. Using the same tool as every competitor, on the exact process that differentiates you, means by definition that you're not differentiating. And bought software comes with its own constraints: you don't control the vendor's roadmap, you adapt to their calendar, not the other way around.

💡 The right question isn't whether a tool is good or bad in the abstract. It's whether it touches what actually makes the business different, or something that's identical everywhere else.

Building custom isn't what it used to be

The classic objection to custom software used to be three words: too expensive, too slow, too complex. That no longer holds the way it used to. Stanford's 2026 AI Index Report measures roughly 26% productivity gains in software development driven by AI, one of the clearer figures in the report (Stanford HAI, AI Index Report 2026). Projects that used to take months now ship in weeks.

The upside doesn't stop at timeline. Custom software becomes an asset the company owns, not a license it rents indefinitely: full control over data, over the user experience, and over what gets built next.

⚠️ An honest limit to that productivity gain: it doesn't apply evenly. A 2025 controlled study by METR measured the opposite effect among experienced developers working on old, complex codebases: they were 19% slower with AI assistance, while believing they were 20% faster (METR, 2025). The speed gain is real on a fresh, well-scoped build. It's a lot less reliable once you first have to understand a complex existing system before touching it.

The smart move: don't choose, combine

In practice, the companies that get this right don't pick one side. They buy what's generic (CRM, invoicing, authentication), and build custom what makes them different. That avoids paying twice for the same thing, gets the standard part live faster, and keeps control over what actually matters.

For the technical installation company from the opening example, the right answer isn't to ditch the CRM or rebuild everything: it's to keep the CRM for clients and invoicing, and build only the scheduling tool that reflects how their teams actually work, connected to the CRM rather than sitting next to it.

🔍 The test before deciding: does this process look like whatever every competitor does (invoicing, contacts, authentication), or does it reflect a way of working that's specific to the company? In the first case, buy. In the second, that's where custom software earns its cost.

Three common mistakes at this stage

1. Wanting to rebuild everything at once. Custom software works best when it stays focused on the one process that genuinely differentiates the business, not the entire toolbox.
2. Still paying for a generic tool on a need that no longer is one. That's a sign a process has become strategic, not a detail to ignore.
3. Neglecting the connection between the two worlds. A custom tool that isn't linked to the existing CRM or ERP just recreates another silo, exactly the problem you were trying to avoid.

The Nightborn approach

The first step is a simple diagnostic: identifying, among the company's processes, which ones genuinely differentiate it and which don't. That happens in a 30-minute conversation, not a multi-thousand-euro audit.

For the custom-built part, the approach always starts with a tight scope: an MVP on the exact process that's causing friction, measured before and after, rather than a sprawling project that pulls in the whole team for months. When the need touches an existing tool rather than something entirely new, that's the role of Product Re-Design: evolve what's there instead of rebuilding from zero.

That's the same principle that let Medicheck build the automations specific to its business without throwing away what already worked.

Key takeaways

• Buying a generic tool is never the problem by itself. It becomes one when that tool touches what actually differentiates the business.
• Custom software has genuinely changed cost and timeline, but the gain isn't uniform: it depends on how complex the existing system is, not just which AI tool is used.
• The real question isn't buy or build, it's where to draw the line between what's generic and what isn't in your processes.

The process your team is currently working around with a shared spreadsheet is probably the one that already answers that question.