Two companies can ask for a client portal and receive very different quotations.
That does not necessarily mean one supplier is expensive and the other affordable.
It may mean they are pricing two completely different systems.
One portal allows clients to view documents and check a project’s status.
The other manages quotations, approvals, payments, access permissions and connections to existing software.
The name is the same.
The work behind it is not.
This is why a meaningful software budget starts with understanding what the system needs to do—not simply what it is called.
There is no useful price without a defined scope
“How much does custom software cost?” is a reasonable question.
But custom software describes an approach, not a fixed product.
It could mean a focused tool that prepares a weekly report.
It could mean a client portal connecting customers to an existing project-management system.
Or it could mean an operational platform managing planning, projects, documents and internal approvals.
Those projects have different requirements, risks and responsibilities.
A useful estimate should therefore explain:
- which processes the system will support;
- who will use it;
- which information it will handle;
- which existing tools it must connect to;
- what is included in the first version;
- and what is deliberately left out.
Without those boundaries, a price can look precise while remaining difficult to interpret.
The first objective is not simply to obtain a number.
It is to understand what that number includes.
What does custom business software cost in Belgium?
There is no standard price list for custom software, but publicly available pricing from Belgian software providers gives some useful reference points.
For a small or medium-sized business, a focused internal tool addressing one clearly defined process can often fall around €3,000–€10,000.
A more complete business application—with several workflows, different user roles, reporting or connections to existing software—often falls around €8,000–€30,000.
Projects can go beyond €30,000 when they combine several departments or processes, significant data migration, complex permissions, multiple integrations or broader operational requirements.
These ranges overlap deliberately.
A client portal, for example, is not automatically a €20,000 project.
A relatively focused portal for sharing documents and following requests may sit at the lower end, while one that also handles quotations, approvals, payments and connections to other systems can require a much larger budget.
Published Belgian examples also vary considerably between providers. Some position focused internal applications from approximately €3,000–€5,000, while others start more substantial custom projects around €15,000.
These figures should therefore be treated as market reference points, not as a price list.
The useful question is not only:
“What type of software are we building?”
It is:
“What does the software actually need to do?”
What actually affects the development budget?
The number of pages or screens is only part of the picture.
A simple-looking screen can contain complicated business rules. A larger interface can support a relatively straightforward process.
Several factors deserve particular attention.
1. The process behind the interface
Consider a quotation approval.
In one company, a manager reviews it and clicks “Approve”.
In another, approval depends on the amount, department, client type and availability of a second reviewer. Rejected quotations return for revision. Changes must remain traceable.
Both systems have an approval button.
They do not have the same underlying requirements.
The important question is not just what users see.
It is what must happen when they act.
2. Connections to existing software
Keeping tools that already work can be a sensible decision.
But connecting them requires understanding how information will move between them.
Which system holds the correct client details?
What happens when a record changes?
What happens if a transfer fails?
A connection is not complete simply because information moves successfully once.
It also needs a defined way to handle errors, duplicates and interruptions.
3. Existing data
A new platform may need information currently stored in spreadsheets, shared folders or another application.
Importing that information is one task.
Preparing it can be another.
Duplicate clients, inconsistent dates, missing fields and outdated records all require decisions.
Who will clean the information? What should be transferred? What should remain archived?
Those responsibilities should be clear before development begins.
4. Access and reliability
An internal tool used by two colleagues is different from a portal used by employees, external partners and clients.
Different users may need different permissions.
Clients must not see one another’s information. Former employees should no longer have access. Important records may need a history of changes.
Testing, backups and recovery also belong in the discussion.
These are not decorative features.
They help determine whether the business can depend on the system.
A concrete example: the same quotation process, three different projects
Imagine a service company where quotations are currently prepared in spreadsheets, converted to PDF and sent manually by email.
The company asks for a quotation management system.
That description alone is not enough to estimate the project.
Version 1: remove the repetitive work
The system stores client details, allows an employee to prepare a quotation from predefined services, calculates the totals, generates a branded PDF and keeps a record of quotations that have been sent.
This is one focused workflow.
Depending on the exact requirements, a project of this type could reasonably sit in the €3,000–€8,000 range.
Version 2: manage the quotation process
Now add different employee permissions, automatic numbering, reusable templates, email delivery, status tracking, reminders and an approval step for quotations above a certain amount.
The system is no longer simply generating documents.
It is managing the process around them.
A project with this level of scope could move into approximately the €8,000–€15,000 range.
Version 3: connect quotations to the rest of the operation
Now suppose an accepted quotation should automatically create a project, notify the appropriate employee, update the CRM, transfer information to the accounting system and give the client access to relevant documents through a portal.
The original request is still “a quotation system”.
But it has become part of a broader operational platform, and the budget could move beyond €15,000, depending on the integrations, business rules and existing systems involved.
The important point is not that every quotation system belongs in one of these price ranges.
It is that scope changes the project much more than its name does.
Starting with Version 1 or Version 2 may also be perfectly reasonable even if Version 3 is the longer-term objective.
The business can solve the immediate problem first and expand the system when there is a demonstrated reason to do so.
The development price is not the total cost
A quotation for building software does not necessarily include everything required to operate it.
Depending on the project, additional costs may include:
- hosting and data storage;
- third-party subscriptions;
- usage-based services;
- maintenance and security updates;
- support;
- training and documentation;
- and future changes.
There is also an internal cost.
Someone in the business needs to explain the process, answer questions, test the system and help colleagues adopt it.
That time should be planned.
A useful comparison therefore looks beyond the launch date.
What will this system cost to build, operate and maintain over the period you expect to use it?
The answer does not need to predict every future expense.
It should make the known commitments and remaining uncertainties visible.
What makes custom software unnecessarily expensive?
Not every increase in a software budget creates additional value.
Some costs come from complexity that the business does not actually need.
Trying to solve everything in the first version
A company may eventually want quotations, planning, project management, invoicing, reporting and a client portal in one system.
That does not mean all six need to be built at the same time.
Starting with the workflow creating the greatest operational problem can reduce the initial investment and provide useful information before the next part is developed.
Rebuilding tools that already work
Custom does not have to mean replacing everything.
If the company’s accounting software, CRM or payment system already performs its role well, connecting to it may make more sense than recreating the same functionality.
Automating an unnecessarily complicated process
Software can make a process faster.
It can also make a bad process faster.
If information passes through four people when only two are actually required, reproducing those four steps in software preserves the inefficiency instead of removing it.
Sometimes part of the work should therefore happen before development: deciding which steps are genuinely necessary.
Designing for hypothetical future requirements
It is reasonable to consider growth.
It is less useful to build features today because the company might need them several years from now.
Future possibilities should influence important architectural decisions without automatically becoming features in the first version.
Changing fundamental requirements during development
Some changes are normal once people begin interacting with a system.
Repeatedly changing the underlying workflow is different.
If important operational decisions remain unresolved when development starts, parts of the system may need to be redesigned or rebuilt later.
A good discovery process is therefore not additional bureaucracy before development.
It is one way of avoiding unnecessary development.
A lower quotation is not automatically better value
Imagine receiving two proposals.
One includes data migration, testing, deployment, documentation and a defined support period.
The other includes development, with those items priced separately.
The second proposal may still be the right choice.
But comparing only the final figures would be misleading.
Before comparing prices, compare responsibilities.
What will be delivered?
Who will prepare the data?
How will acceptance be agreed?
What happens if a problem appears after launch?
Also clarify access and continuity.
Who controls the hosting accounts?
Can your data be exported?
What source-code access or ownership is included?
Could another provider maintain the system later?
These questions are easier to resolve before the business depends on the software.
How do you decide whether the investment is worthwhile?
Start with the process being improved.
Consider a hypothetical business spending ten hours each week consolidating project information.
At an assumed internal cost of €35 per hour, over 46 working weeks, that represents:
10 hours × €35 × 46 weeks = €16,100 per year
That is not automatically an amount software can save.
Some checks will remain necessary. People will still handle exceptions. The new system will have its own operating costs.
Suppose the business estimates that a better process could realistically recover half of that time.
The potential capacity released would represent:
5 hours × €35 × 46 weeks = €8,050 per year
These figures are illustrative, not a pricing benchmark or a promised result.
The distinction matters.
Recovered time does not automatically become cash savings.
It may allow employees to serve more clients, follow up sooner, reduce overtime or handle additional work without immediately increasing administrative capacity.
A simple starting calculation is:
Annual process cost = hours spent each week × internal hourly cost × working weeks
Then estimate conservatively how much of that work could realistically be removed or redirected.
Time is also not the only possible return.
A better operational process may create value through:
- time recovered — employees can spend more time on higher-value work;
- errors avoided — less correction, duplication and rework;
- faster operations — quotations, approvals, onboarding or projects move sooner;
- additional capacity — the business can handle more activity without immediately increasing administrative resources.
A credible investment case connects the proposed improvement to a practical outcome.
Starting smaller can make the decision clearer
A company may eventually benefit from a broader operational platform.
That does not mean every feature needs to be included at launch.
The first version could address one complete workflow:
a request arrives, the right person reviews it, the status is updated and the necessary information reaches the next step.
That may be more useful than launching several partially connected modules.
A focused first version also creates an opportunity to check assumptions.
Do people use it?
Does it remove the expected manual work?
Which exceptions occur in practice?
What should be improved before expanding further?
However, “smaller” should mean a narrower scope.
It should not mean removing essential access controls, testing or backups.
When spending less means building nothing
Sometimes the most sensible result of an initial review is that custom development is unnecessary.
An existing application may already support the requirement.
A configuration change may remove the problem.
An integration may connect two tools without creating a new platform.
A focused automation may eliminate the repetitive work at a fraction of the cost of a larger system.
Or the process itself may need simplification before any technology is introduced.
Custom software should not be the predetermined answer.
It should be one possible response to a clearly understood need.
If you are still determining whether your company needs custom development at all, read our guide onwhen a custom business platform is actually necessary for a Belgian SME.
What should you prepare before asking for a quotation?
You do not need a technical specification to begin.
A clear description of the operation is more useful than a long list of imagined features.
Prepare answers to these questions:
- Which process needs to improve?
- Who uses it, and how frequently?
- Where does work slow down or get repeated?
- Which tools and information are involved?
- Which exceptions must the system handle?
- What must the first version achieve?
- What can wait?
- How will you judge whether the change was worthwhile?
This gives the discussion a practical starting point.
It also helps distinguish essential requirements from additions that increase the budget without improving the result.
The right budget follows the problem
For a Belgian SME considering custom software, the objective should not be to buy the largest platform the budget allows.
Nor should it be to find the lowest development price in isolation.
The objective is to choose an appropriate solution, understand its ongoing cost and identify the improvement it should create.
So when asking:
“How much will this software cost?”
ask another question alongside it:
“What will change in the business when it works?”
A useful proposal should help you answer both.
Before asking for a software quotation, understand what is costing you today
If you’re considering custom software, automation or an integration, start by identifying where time is currently being lost.
The BrandLabel Operational Diagnostic helps you estimate the cost of repetitive work and identify which processes may be worth improving.
You may discover that you need a custom platform.
You may discover that a smaller automation or integration is enough.
Or you may discover that changing the process itself should come first.
Start the Operational Diagnostic →