What a web application costs after launch
The build is the part everyone budgets for. Hosting, fixes, updates and the small changes users ask for in month three are the part that decides whether the app is still useful a year later.
Most quotes for a web application cover one thing: building it. That is reasonable, because the build is the biggest single cost. But an app is not a brochure. It holds data, people log in to it every day, and the business around it keeps changing. The money and attention it needs after launch is smaller each month, but it never stops.
None of this is a reason not to build. It is a reason to plan for the second year before signing for the first, so nobody is surprised when the first small change request arrives.
The four costs that start on launch day
- Hosting: the server or platform the app runs on, the database, file storage, backups and the domain. Small for most business apps, but it grows with users and stored files.
- Third-party services: email delivery, SMS codes, maps, payment gateways, error tracking. Each is cheap on its own; together they are a line on the monthly bill.
- Updates: frameworks, libraries and the operating system all release security fixes. Skipping them for a year turns a one-hour update into a week of work.
- Change requests: the field that should have been a dropdown, the report the accounts team now wants, the new branch that needs its own login. This is usually the biggest of the four, and the most useful.
A rough way to budget
Every app is different, so treat this as a rule of thumb rather than a price list. For a typical business application in steady use, plan a yearly running budget of roughly 15 to 25 percent of what the build cost. The lower end is an internal tool with a few dozen users and few changes; the upper end is a customer-facing app that the business keeps improving.
Where the running budget usually goes for a business web app (rule of thumb, not a quote).| Item | How often | What drives it up |
|---|
| Hosting and database | Monthly | More users, more stored files, video, heavy reports |
| Third-party services | Monthly | SMS volume, maps usage, payment fees |
| Security and library updates | Monthly to quarterly | Old frameworks, many plugins, no automated tests |
| Small fixes and changes | As needed | New processes, new branches, new reports |
| Backups and restore tests | Monthly | Large databases, strict recovery needs |
The build is one tall bar. Running the app is a long row of small ones.Decisions at build time that lower the bill later
Build-time choices
Running costs are mostly decided before launch. A few choices make the difference between an app that is cheap to keep and one that needs a rescue project after eighteen months.
- Fewer moving parts: one well-chosen framework and one database beat five services that each need their own updates.
- Automated tests on the parts that handle money, stock or permissions, so an update can be checked in minutes instead of by clicking through every screen.
- Settings instead of code: tax rates, branch names, email text and price lists that staff can change themselves never become a change request.
- Logs and error alerts from day one, so problems are found by the team before a customer reports them.
- Written handover notes: how to deploy, where the backups are, which accounts own which services.
The cheapest change request is the one staff can make themselves from a settings page.
Questions to ask before you sign
- Who owns the hosting accounts, the domain and the code once the project ends?
- What happens if a security update breaks something six months after launch?
- How long are fixes covered for free, and what does a change cost after that?
- Can we see the backups being restored, not just being taken?
Frequently asked questions
Can we just host it ourselves to save money?
Yes, if someone on your side is comfortable with servers, updates and backups. The hosting bill is rarely the expensive part; the time spent looking after it is.
Is a no-code tool cheaper to run?
Often, at the start. The trade-off comes later: per-user pricing grows with the team, and some processes simply do not fit the tool. It is a good choice for simple internal workflows.
Do you offer support after launch?
Yes. Every project includes a period of free fixes after launch, and after that we work either on a small monthly plan or per change, whichever suits how often the app changes.
Will we need a redesign in a few years?
Rarely a full one, if the app is kept current. Most apps change in small steps: a new report, a faster screen, a new branch. A rebuild is usually a sign the updates were skipped.