What is custom software? The part your tools can't do

The SaaS covers 80% of the need. The other 20% lives in a spreadsheet only the planning lead can edit without breaking it. That is where custom software usually enters the conversation in a Belgian SME: not through strategy, but through a file nobody else dares to touch.

The textbook definition is correct and not very useful. Custom software is an application built for one company's own processes rather than bought off the shelf. What matters for a manager is narrower: which part of the business it should cover, when it pays off, what it costs after launch, and where projects go wrong.

This guide answers those four questions. Where a question deserves a full article, the section links to it.

Custom software doesn't replace your tools. It encodes what they can't do.

What is custom software? Custom software is an application designed for one organisation's own rules, workflows and data, and owned by that organisation. In an SME it rarely stands alone. It sits next to the ERP, the CRM and the accounting package, and covers what they cannot model: the exceptions, calculations and sequences specific to how that company works.

Belgian SMEs are not starting from a blank page. According to Statbel's 2025 survey on ICT use in enterprises, three companies in five use an ERP and two in five use a CRM. The real question is what to do with the part those tools leave on the table.

What custom software does well

It models your exceptions instead of asking you to drop them: a tariff grid negotiated client by client, a purchase that needs two signatures above a threshold. It owns its data model, and the data stays with you. And it connects what you already have. Since 1 January 2026, structured B2B e-invoicing through Peppol is mandatory for VAT-registered companies in Belgium: a small tool that feeds clean order data into accounting often beats a large one that tries to replace it.

What it never fixes

A process nobody has written down. If three people do the same task three ways, the software picks one and the other two route around it. The same limit applies to ERPs, as we detailed in ERP for SMEs: what it solves, and what it never will.

💡 You probably already run custom software. It is called a spreadsheet with macros, or a chain of no-code automations built by someone who left last year. Specific, but with no tests, no documentation and nobody accountable. Replacing it is often the first real custom project.

Most SMEs don't need custom software. Four signals say you might.

Payroll goes to a social secretariat, accounting to a certified package. Building those yourself would be a waste of money.

The gap between companies that build and those that don't is rarely a budget gap. In Belgium, 34.5% of companies used at least one AI technology in 2025, against 76.4% of those with more than 250 staff, and the Conseil supérieur de l'emploi found that lack of skills is the barrier companies cite most. Custom software follows the same pattern: the hard part is knowing what to build.

1. Your margin depends on a process no SaaS models

A transport company in Liège pricing multi-drop routes with its own grid. A food producer in Hainaut tracking lots the way its auditor asked. 🔍 Test: would you email that spreadsheet to a competitor? If not, the logic inside it is an asset.

2. Your rules have exceptions inside exceptions

"Apply the framework grid, unless the order is below the minimum, in which case sales approves." Standard tools break on nested conditions, and the breakage shows up as manual corrections.

3. The same data gets typed twice

Every client number entered by hand is an integration point. Often the first custom project is simply the connection between two tools you already pay for.

4. Your context imposes rules the market ignores

Sector traceability, data residency, a specific approval chain. Test the SaaS against your three hardest cases before signing, not after.

Is custom software better than SaaS?

For generic functions, SaaS wins on cost and speed. For the process that differentiates you, custom wins on fit and ownership. The decision is made process by process, as we detailed in Custom or SaaS software: the math has changed.

⚠️ Watch out: building to avoid a decision. If two departments disagree on a process, software will not settle it. It will freeze whichever version the person writing the specification preferred.

Three custom builds, three different starting points

Custom software is also the product that has aged, or the first version a market needs. These three cases come from Nightborn client work.

1. Replacing a manual control process: MediCheck

An end-to-end tool built around MediCheck's own medical control workflow.

• Back-office application and automations
• Process time reduced by 75% (case write-up)

2. Rebuilding a product that had aged: Monizze

A mobile app more than ten years old, already used across Belgium.

• Revamped and redeployed to more than 700,000 users in three months

3. Shipping a first version fast: Rosa

A doctor-patient booking system, built jointly with Rosa's team.

• Mobile app and platform published in less than two months

💡 The common thread is not the technology. Each scope was set by one measurable outcome, and everything else waited for the next build.

What custom software costs, from scoping to year three

The quote covers the build; the real cost covers the tool's whole life. AI has pushed build figures down, as we showed in Custom or SaaS software: the math has changed. It did not remove the other lines: hosting and maintenance run from launch, and changes keep coming as fast as the process itself changes.

There is also a deliberate ceiling on a single build. Past a certain size, untested assumptions pile up faster than anyone can check them. Two sequenced builds carry less risk than one large project.

Can a Belgian SME get the project subsidised?

Partly. In Wallonia, the chèque maturité numérique covers 50% to 75% of an approved consultant's fees, up to €50,000 excluding VAT over three years. But Digital Wallonia specifies that development costs, licences and configuration are not eligible.

💡 Pro tip: in Wallonia, the diagnosis can be subsidised; the build cannot. Plan scoping as a separate step with a labelled provider, and check the conditions in force when you file: the scheme is being reformed.

One honest limit: a fixed price fixes the frame, not the scope. What fits inside it is decided at scoping, and revisited at every Friday demo.

Five ways a custom software project goes wrong

None of these is a coding problem. All are decided before the first line of code.

1. Writing the specification without the people who do the work

Software built on the process as management describes it gets bypassed by the process as it actually runs.

2. Using the project to empty the backlog

Each postponed request is reasonable; together they turn six weeks into nine months.

3. Treating launch day as the end

A tool with no maintenance budget from day one starts decaying on day two.

4. Skipping the handover

If only the provider holds the code, the documentation and the access, you own a tool you cannot run.

5. Building what the ERP already does

Check what a proper configuration of your current tools covers before commissioning anything new.

👉 Where speed misleads. AI makes the build fast enough to skip these decisions unnoticed, until production. More in Building fast isn't enough to make a custom software project work.

How we scope and build custom software at Nightborn

Each step ends with something the client keeps, whether or not the next step happens.

Step 1: a paid scoping workshop, four hours at most

We arrive with the data analysed, competitors reviewed and hypotheses written down. Deliverables: an aligned problem statement, success criteria and a PRD. Details on our Product Discovery page.

Step 2: a fixed-price build, two to four weeks

The scope can move; the frame does not. A demo every Friday, with design, development and QA included, as on our web app development page.

Step 3: a complete handover

Code, documentation and PRD belong to the client. The data stays with the client, and integrations leave existing tools' configuration untouched.

Step 4: small requests, without ceremony

Small changes are billed by the day. Anything past two or three days hides an architecture decision, and goes back to a workshop.

📌 Before you sign with any provider, check: a separate paid scoping step, a fixed budget and duration, working software every week, and ownership of code, documentation and access at the end.

Custom software: a decision per process, not per company

What to remember:

• Custom software covers what your ERP, CRM and SaaS cannot model. It sits next to them.
• Four signals justify it: a margin-making process, nested exceptions, double data entry, rules the market ignores.
• The real cost runs from scoping to year three, and in Wallonia only the scoping can be subsidised.
• Most failures are decided before the first line of code.

So do not ask whether your company needs custom software. Start with the one spreadsheet your team is afraid to break. Bring it to a scoping session, and in four hours you will know whether it deserves a tool, a better configuration, or nothing at all.