The most interesting question about a web application isn’t what it can do, but what it replaces. A web application is software you work in through the browser: people log in, enter data, and a process runs through it from start to finish. That is something other than your website, which informs and persuades; we set out that difference in the difference between a website and a web application. A web application earns its place only once the work it takes over is already costing you money, in hours, in mistakes or in customers kept waiting.
That moment hasn’t arrived for every business. Almost any process could run better, so that question doesn’t get you far. The questions that matter: how often does the work come back, is the process settled enough to pin down, and doesn’t an existing package already cover it?
Three places where the gains are
A web application almost always pays for itself in one of three places. The first is recurring internal work: data someone retypes from one system into another, quotes pieced together from separate spreadsheets, a schedule rebuilt by hand every week. Each case is small on its own; added up, it costs someone a substantial part of their working week.
The second is customer contact. Customers call or email for a status update, a document or an order they could have handled themselves if they had access to their own data. A portal takes those questions off your team and gives customers an answer when they look for it, outside office hours too. That gain appears on no timesheet, but you notice it in a quieter phone.
The third is work waiting for the next pair of hands. A request sitting in a mailbox until someone approves it, an order that can’t move on until the back office has seen it. Here the gain isn’t fewer hours but shorter lead times: the process moves without anyone having to push it.
Three conditions before the sum can add up
Whether those gains are worth the investment depends on three conditions. They sound obvious, but skip one and the figures flatter you.
The first is repetition. One-off work rarely justifies software, and the same goes for work that is tedious but rare. The sum is how often the work comes back multiplied by what each occurrence costs, and both sides need to carry some weight.
The second is a settled process. Software fixes a way of working in place. If the process still changes every month because the team is still working out how it should run, you lock in something that isn’t finished, and the changes start on the day of delivery.
The third is a process no package covers. For bookkeeping, time tracking or a conventional sales process there are excellent standard packages; custom development is rarely justified there. Custom software wins where the process carries what sets your business apart and a package would force you to bend your way of working around it. Where that line runs is covered in when a custom web application beats SaaS.
Signs that you are better off waiting
Sometimes the honest answer is: not yet. These signs point that way.
- The process runs differently every time and lives mostly in one colleague’s head. What you can’t describe, you can’t have developed.
- The data the application needs isn’t reliably stored anywhere: customer details in three versions, prices in a spreadsheet nobody maintains. An application makes that visible, not better.
- The work comes up a few times a year. However tedious it is, the sum won’t add up.
- A standard package covers the process almost entirely, and what’s missing is a habit, not a requirement.
- Nobody has time to look in and test during development. Software made without the people on the floor rarely fits the work.
If you recognise two or more of these signs, waiting isn’t a delay but a decision. You save the investment and, more importantly, you avoid software nobody uses.
What to do when it is still too early
Waiting doesn’t mean sitting still. First, write down the process as it really runs today, step by step, detours included. That often turns up improvements that need no software, and it is the description a development partner needs later.
Then measure for a few weeks how much time goes into it and how often it goes wrong. How to go about that, and why the hours are only the visible part of the cost, is in manual data copying costs more than the hours you see.
If the process has nearly settled, start small: a first version that covers only the core process, in use by the people who work with it every day. That shows you whether the way of working holds before you have the rest developed. How small such a first version can be is covered in MVP or fully built software.
Only then do you do the sum: the hours multiplied by what an hour costs your organisation, multiplied by how often the work comes back, set against the full investment including maintenance in the years after delivery. A worked example of that sum is in why custom software pays off for mid-sized businesses.
Three questions to test the moment
To establish quickly whether the moment has come, three questions will do.
- How many hours a week go into the manual work the application would take over, and whose hours are they?
- What does a mistake cost, such as data entered twice or a missed delivery, and how often does it happen?
- How many enquiries does your team handle that customers could have answered themselves if they could see their own data?
If all three come out small, a web application isn’t important for your business right now, however convincing a supplier’s pitch sounds. If one of the three produces a figure you don’t want to leave on the table, you have the basis of your business case. Keep those answers: they become your baseline when you later want to measure whether the software is paying for itself.
If you recognise a recurring process like this, run the test first with someone who works in it every day. On our page about web applications and portals you can read what we develop for organisations that have reached that point. And if the answer right now is not yet, we would rather say so at the start of a conversation than at the end of a project.