Ask a few agencies for a quote on a web application and the numbers vary widely. That difference rarely comes down to the hourly rate. It comes down to what gets developed: how many screens, how many exceptions to the rule, how much custom work in places where an existing building block would have done the job. And putting that quote next to the monthly fee of an off-the-shelf package compares an upfront investment with a subscription that never stops.
The price of custom software is therefore less erratic than it seems. Most of your investment is decided by a handful of choices you make before a single line of code is written. We go through those choices, clear up a few persistent misconceptions along the way, and end with how to draw up a realistic budget.
Cut scope before development starts
The biggest cost driver in a web application is functionality that never needed to be there. Every extra page, field and exception to the rule has to be designed, developed, tested and then maintained for years. The cheapest feature is the one you don’t have made.
So draw a clear line upfront between what the system must do and what would merely be nice to have. A tight scope isn’t a limitation, it’s a saving: anything that can wait for a later version doesn’t need paying for now. After a few months of use, your team will know far better which wishes on that list still stand.
Custom doesn’t mean everything is made from scratch
A persistent misconception is that custom development means every feature is built from zero, at full price. Logging in, permission management, payments, invoices as a PDF: proven frameworks and ready-made components already exist for this. An experienced development partner builds on those instead of reinventing the wheel, which saves development time, testing effort and maintenance.
Custom work earns its keep where your process differs from the rest of the market, because that’s where your edge lies. There, every feature has a clear reason to exist: a step that costs time, a place where errors creep in, an insight that is missing. So don’t just ask an agency what it develops, ask what it reuses too.
Off-the-shelf software looks cheaper, until you count everything
The best-known misconception is that custom software is by definition more expensive than an off-the-shelf package. But the monthly fee isn’t the whole bill. Licences keep running for as long as you use the package, extra users and premium features cost more, and the moment the package doesn’t quite fit your process, your team pays the difference in working hours. The biggest hidden cost often sits between the systems: data retyped from one screen into another, with errors and duplicate work as a result.
So never compare entry fees; compare total cost over several years, including the hours your team currently loses to workarounds. Sometimes the answer isn’t even a new application, but a proper connection between the systems you already have; that’s the territory of data integrations. When an off-the-shelf package is the better choice, and how to tell that your process doesn’t fit, is covered in when a custom web application beats SaaS.
Develop in phases and expand on evidence
Projects that ended up costing twice the estimate do exist, and those stories travel far. Look at the causes and you see almost the same pattern every time: too much was locked in upfront, and what was actually needed only became clear once development was underway.
That pattern can be broken. A web application doesn’t have to be finished in one go. Start with a first version that properly supports the core process, put it into use and see what happens. Users will tell you, without fail, which extensions add value and which only looked good on paper. How to define that first version is covered in the differences between an MVP and fully built software.
Developing in phases also spreads out your investment. You only spend money on extensions once the foundation has proven itself, and you can adjust course without losing months of work. For whoever holds the budget, that’s arguably the biggest saving: not paying less per feature, but never paying for something whose value hasn’t been demonstrated. So ask a development partner not just about price, but how they phase the work and how they handle insights that come up along the way.
Count the years after launch
The development cost isn’t the whole story. A web application then runs for years, and in those years hosting, updates, security patches and monitoring are part of the investment. Cut corners there and you pay it back later in outages, emergency fixes and a system nobody dares touch any more.
When comparing quotes, look beyond the figure for delivery. Press for answers on three points:
- what hosting and maintenance cost per year, and what that actually covers;
- who steps in when something goes wrong, and how quickly;
- how the application scales as the number of users grows.
A vendor who answers this clearly has thought about the years in which the system has to earn its keep, precisely the period in which a solid foundation pays for itself. What those years involve is described under ongoing development and maintenance.
How to arrive at a realistic budget
A good budget doesn’t start with quotes, but with your current costs. Three steps take you a long way:
- Map out what you currently pay: licences, the hours spent on manual work and fixing errors, and the workarounds your team takes every day. That is the figure you measure every quote against.
- Separate what the application must do on day one from what can come later. The first group sets your starting budget, the second your roadmap.
- Leave room for insights that emerge along the way. Development always teaches you something about your own process, and you want to be able to act on that without a discussion over every single change.
With that groundwork done, a quote conversation becomes a conversation about substance rather than a price negotiation. You know what the application needs to deliver to justify the investment, and what you are deliberately leaving for later.
We develop web applications for organisations that take this trade-off seriously, and prefer to have that conversation before anything gets made. Read how we develop web applications and portals, or put your wish list in front of us. There’s a good chance we’ll start by asking what can come off it.