What does developing custom software really cost?
It usually starts with something small that outgrows itself. An Excel file nobody dares to touch anymore, data that gets copied by hand from one system to the next every day, or a portal that simply can't keep up. That's the moment the question comes up: what would it actually cost to solve this properly with custom software? For a business-grade custom solution you should count on roughly €10,000 to well over €100,000, excluding VAT. That's a wide range, and it isn't sloppiness. The price follows from the size of the problem, the risks attached to it and the demands your day-to-day work places on it.
A small internal tool with one clear job is a different story than a customer portal that hangs off your ERP, handles payments and has to stay up around the clock. A fixed price that lands on the table without a sharp scope offers little certainty. In practice a number like that tends to spark debate the moment the project gets going.
What does custom software cost per type of project?
The figures below are realistic guidelines for an experienced Dutch team. They don't replace a technical assessment, but they do help you have the budget conversation at the right scale.
- A focused internal tool or automation: usually €10,000 to €25,000. Think of an application for planning, quote management, quality checks or automating away the tasks that come back every week.
- A business application or customer portal: often €25,000 to €75,000. Count on user roles, an admin environment, a pleasant interface and one or more connections to existing systems.
- A mobile app for Android and iOS: quickly €30,000 to €100,000, and sometimes more. What pushes the price up are features like accounts, push notifications, offline use, location data and integrations.
- A complex platform or SaaS product: from around €75,000, with larger projects running well past €200,000. Here scalability, multiple customer environments, fine-grained permissions, security and ongoing development all weigh in heavily.
Those amounts usually cover far more than programming alone. A solution that's genuinely usable calls for analysis, technical design, testing, coordination along the way and a clean handover. Anyone who only counts the screens misses where most of the hours go.
So where does that price actually come from?
How sharp is the scope?
A clear problem doesn't mean a clear scope. “We want a portal for our customers” could be a simple document overview. It could just as easily be a full self-service platform with invoices, orders, support, reports and all sorts of per-user permissions.
The more concretely you describe the processes, the exceptions and the desired outcome up front, the better a supplier can estimate. You don't need to nail everything down. But it has to be clear what the first version solves and what you're deliberately pushing to later.
An MVP, in that light, isn't a stripped-down version that helps no one. It's a first version that does one important business process well. That choice lowers the investment at the front end and shows you sooner how the software gets used in practice.
Integrations and the quality of your data
Integrations are the item that gets underestimated most often. An API that's well documented and runs reliably connects relatively quickly. But an outdated package without an API, data full of gaps or customer numbers that aren't the same everywhere: that calls for extra logic, checks and error handling.
Take a webshop whose orders need to flow into an inventory package while the customer data comes from a CRM. A working connection is only the start. You also have to settle which system takes the lead, what happens when something goes wrong, and how you deal with duplicate or missing records. Those exact choices decide whether automation saves you time or introduces fresh errors.
Users, roles and exceptions
An application for five colleagues makes different demands than a platform for thousands of customers. More users doesn't automatically mean more development hours, but it does mean more attention for performance, authorisation, logging and support.
And then there are the exceptions, which pile up. Can a manager still adjust an order after it's been approved? What happens when an employee leaves? Should a customer be able to manage several branches? It's precisely those practical questions that decide whether you have a nice demo or software that survives the daily rush.
Quality, security and availability
Software that's on for a few hours a week doesn't need the same availability as an ordering platform or a scheduling tool for field staff. The moment downtime touches your revenue, your customers or your internal processes, investing in monitoring, backups, recovery procedures and a hosting environment that can take the load becomes unavoidable.
Security isn't something you tack on afterwards. Two-factor authentication, role-based permissions, encryption, audit logs, careful handling of personal data: which measures you need depends on the risk. An internal registration app calls for different choices than an environment full of customer data, payments or sensitive documents.
Not just building, but the whole lifespan
The invoice for building is visible. The costs that come after are at least as important. Software wants to be hosted, watched, updated and adjusted the moment processes, browsers, devices or connected systems change.
So set aside budget for maintenance and further development. A common rule of thumb is 15 to 25 percent of the initial development cost per year, depending on usage, complexity and how quickly you expect a response. For an application of €40,000 that works out to roughly €6,000 to €10,000 a year for hosting, technical maintenance, support and small improvements. Big new features come on top of that, of course.
The cheapest builder is rarely the most economical choice. If development, hosting and support sit with different parties, a single outage can turn into a round of finger-pointing. The host points at the software, the builder points at the integration, and your team is left waiting. One technical point of contact takes that delay out and makes clear who owns the problem.
How to keep a grip on budget and planning
A good project doesn't start with a long wish list, but with the question of which bottleneck needs to go first. A short analysis phase brings the processes, integrations, risks and priorities into view. Out of that comes a technical plan with a bounded first release and a budget that holds up.
After that, work in phases. First a working base that people can genuinely use, then extensions based on what actual usage teaches you. That takes discipline, because not every wish can go in straight away. In return you see value sooner, sink less money into assumptions and decide more sharply about the next step.
When you get a quote, also ask how the supplier handles changes. A serious proposal shows which assumptions it rests on, what's included and how extra work gets assessed. A low final price with not a word about testing, handover, maintenance or integrations gives you little to build on.
What to watch for when comparing quotes
Don't line up total amounts without comparing what's inside them. Check whether analysis and design are included, how much testing is budgeted, which integrations are covered and whether maintenance after go-live has been accounted for. Also find out who's responsible if an integration or server environment starts playing up later.
Pay just as much attention to the way you'll work together. Do you get direct contact with people who understand the technology? Are risks named before they turn into delays? And is it clear who stays reachable after handover? For organisations that lean on their systems, those aren't side issues but plain conditions for keeping things running.
At LJPc a reliable estimate therefore starts with the business process behind the request. Only once it's clear which actions, data and dependencies a solution has to carry can an investment be properly justified.
Custom software doesn't have to do everything at once. Pick the first step that demonstrably saves time, prevents errors or helps customers faster. If that step delivers results right away, you stand on much firmer ground when you decide to keep building.