Custom software development starts making sense for a small business when a process is already well defined and nothing on the market covers it. Before you get there, it is worth checking whether part of the problem could be solved by getting the tools you already use to talk to each other.
And if a build turns out to be the right call anyway, there are a few things worth examining before you sign. Some details buried in the quote will decide what you actually own three years from now.
What can be solved without building anything
When a business owner says "we need software", they usually mean one of two quite different situations.
The first is a plumbing problem. The tools already exist, they just do not talk to each other, so someone spends their week copying records from one system into the next.
The second is different: nothing on the market really covers the need.
In the first case, you are not necessarily looking at a new tool. You may just be looking at connecting the ones you already pay for.
At Numinam, a first automation project starts at around €2,380 for one or two workflows in production. A targeted internal tool starts closer to €7,140. The gap is wide enough that it pays to work out which situation you are in before commissioning a build.
One of my own companies, Coddy, runs across nine countries with no central piece of software. Bookings come in through the website, and a series of automations then take over to qualify requests, handle payments and send out whatever the customer needs.
Before you write a spec, go back through your list of needs. For each line, ask whether the data already exists somewhere in your stack, or whether it does not exist at all yet. If it does not, the question stops being technical: you first have to decide how that information gets produced.
Three questions that can put a project back on the shelf
Before you even start comparing suppliers, take the time to answer three questions.
- Can you describe your process from start to finish? Who does what, in what order, with what information? If you get stuck halfway through, that is usually an organisational problem rather than a software one. Building at that stage tends to mean paying for a first version, then a second one once the way of working is finally clear.
- Who will own the tool internally? Someone has to arbitrate changes, answer users and decide what gets built next. Without a clearly named person, teams tend to drift back to their spreadsheets at the first obstacle.
- Can you fund the years after the project? The build is only part of the cost. Maintenance typically runs somewhere between 10% and 25% of the initial cost every year, which is what the published ranges from Sparkle (10 to 20%) and Lonestone (15 to 25%) suggest. On a €16,660 business application, that comes to somewhere between €1,700 and just over €4,100 a year.
What custom software really costs
Suppliers who publish their rates land on fairly similar ranges.
| Item | Published range | Who publishes it |
|---|---|---|
| Simple build, one module | €8,000 to €20,000 | Sparkle |
| MVP | €15,000 to €50,000 | Lonestone |
| Full business application | €30,000 to €50,000 | Sparkle |
| Maintenance, per year | 10% to 25% of initial cost | Sparkle (10 to 20%), Lonestone (15 to 25%) |
| Day rate, France | €500 to €700 excl. VAT | Lonestone |
Those figures mostly cover the build phase. Maintenance comes back every year, so check that it appears on the quote before comparing two proposals.
Another quick sanity check: divide the quoted amount by the stated day rate. That gives you the number of days billed. Then compare it against the scope on the table.
At Numinam, for instance, a client tracking module is costed at twelve days of work on the pricing page. If a quote comes back at forty days for a similar scope, that does not automatically make it a bad quote, but it does deserve an explanation. And if there is an AI component in the mix, what AI integration actually costs is worth reading before you set a budget.
If your company is based in Belgium, look at the funding available too. The Brussels digitalisation grant can cover between 25% and 70% of eligible spend, and Sparkle mentions support of 30 to 50% through the Walloon chèques-entreprises scheme. Check that your project qualifies before you build those amounts into a budget.
What you actually get on delivery
Three parts of the contract deserve a close read.
The first is code ownership. Once the project is paid for, who owns it? If the contract says nothing, it is worth asking for that in writing. Numinam, for example, states on its internal tools page that the code and the documentation go to the client.
The second is hosting. Are the servers and the database running on your own account, or on the supplier's? It can look like a detail at the start, and it makes changing supplier considerably harder a few years later.
Third, check the handover terms. If another developer picks the project up, will they get the repository, the documentation and every credential they need? That list is far easier to obtain before signature than on the day you decide to move.
What custom software will never do
Software applies rules. It does not invent them.
If your process is not defined, the tool will simply automate the vagueness.
It will not repair data that is already wrong either. An incomplete customer file stays incomplete, just behind a more modern interface.
In the same way, software does not make decisions for you. With no clear business rules, it speeds up a way of working that still lacks a shape. It is the same reasoning as the four conditions for automation.
A project also never really ends on delivery day. Users will have questions, change requests and new needs. That time has to be planned for from the start.
And there is one case where the question answers itself: if your need is the same as most companies in your sector, a market tool will almost always work out cheaper. Its development cost is spread across the vendor's whole customer base.
Key takeaways
- Before commissioning anything, separate what is a connection problem between your existing tools from what genuinely needs new software.
- If you cannot yet describe your process from end to end, take the time to write it down before asking for a quote.
- Plan for an annual maintenance budget of 10% to 25% of the initial cost, and check that it appears on the quote.
- Divide the quoted amount by the day rate to get the number of days billed, then compare that against the scope. It is the fastest check you can run on a proposal.
- Read the clauses on code ownership, hosting and handover carefully. Those are usually the ones that make the difference a few years down the line.
And if you are still weighing up connecting your existing tools against building something custom, a 25-minute audit is usually enough to tell which option makes more sense.
