You have a process that keeps getting stuck in spreadsheets, scattered emails and manual steps, and you suspect an application would fix it. The next question is usually not what it costs, but how to go about it: what is a web application anyway, do I actually need one, how does a project like this run, and who do I hand it to? This guide answers those questions step by step, without the sales pitch. Want the numbers straight away? They live in our web application cost guide. This piece is about the route toward it.
What is a web application?
A web application is software that runs in the browser and lets users log in to do real work: entering and editing data, handling requests, viewing dashboards. Think of a customer portal, a planning tool or an internal system. The difference from a regular website is the interaction: a website informs, a web application processes.
That distinction sounds subtle, but it drives almost everything about the build. A website has pages you read; a web application has screens you work in, with login, roles and permissions, a database and logic that checks whether what you are doing is actually allowed. It is exactly that processing layer that makes a web application more complex, and therefore a different project from “just getting a site made”.
Web application, website, app or SaaS: what do you need?
The most expensive mistake is often made in the first week: choosing the wrong type. A website, a web application, a mobile app and a SaaS product solve different problems and differ in price, timeline and upkeep. Choose based on what the user needs to do, not on what sounds modern.
| Website | Web application | Mobile app | SaaS product | |
|---|---|---|---|---|
| Purpose | Inform, be found | Do work in the browser | Do work on the phone | Sell software to many customers |
| Example | Company site, blog | Portal, dashboard, internal tool | Delivery app, field app | Your own product with subscribers |
| Users | Anonymous visitors | Logged-in staff or clients | Users on the move | Multiple companies, each their own data |
| Extra at build | SEO, content | Roles, permissions, integrations | App store, offline, device | Multi-tenant, billing, self-service |
For most SME questions a web application is the answer: no app-store hassle, one codebase and accessible on any device with a browser. Torn between a web app, a SaaS and a real platform? Read our comparison of web app vs SaaS vs custom platform. If you mainly need a findable company site, look at what a website costs instead.
When should you have a web application built?
You have a web application built when an off-the-shelf package no longer fits and your process has its own logic that you cannot buy ready-made. Usually one of four situations applies: you are outgrowing your spreadsheets, your customers want their own environment, you need to connect systems that do not talk to each other, or you have a calculation or workflow that is unique to your business.
- Your spreadsheets are breaking down. Several people work in the same file, versions get lost, and one typo has big consequences. An application brings structure, roles and an audit trail.
- Your customers want a portal. An environment where customers view their data, requests or documents lowers your support load. What that looks like in practice is covered in customer portal examples.
- Your systems do not talk to each other. Data you retype daily between two packages is a sign an application with integrations will pay for itself.
- You have your own business logic. A pricing configurator, a scoring model, a schedule with dozens of rules: if your core process is unique, no SaaS exists for it.
Recognise none of the four? First check whether an existing package or a no-code solution is enough. Custom only pays off once you hit a real limit, not before.
The journey from idea to launch
Having a web application built runs in five phases: discovery, design, build, test and launch. The craft is not in the building itself, but in getting sharp on what you are building before a single line of code is written. According to McKinsey, 45 percent of large IT projects run over budget (McKinsey), and the biggest lever against that is tight preparation.
- Discovery (1-2 weeks). Needs, processes, users and data mapped out. Result: a scope document with screens, roles and integrations, plus a fixed price for the build. This is a paid phase, not a free chat.
- Design (1-2 weeks). Wireframes and a clickable prototype. You click through the application before anything is built, so wrong assumptions surface now and not during the expensive build phase.
- Build (2-12 weeks). The actual development, split into two-week sprints with a demo at the end. Insist on seeing a working version every two weeks.
- Test (in parallel plus a final sprint). Automated tests, manual acceptance tests with real users and a security check against the OWASP Top 10.
- Launch and maintain. Go-live with monitoring, a handover document, training and clear maintenance agreements.
What do you supply yourself? The brief
You do not need to write a technical specification. What a build partner really needs is a clear picture of your problem and process: who the users are, what steps they take today, where it goes wrong and which systems it must connect to. A good partner translates that into technology; your job is to sharpen the business side.
A strong brief contains five things. The problem in two paragraphs, not the solution. The main flow: the one task the application really must support. The roles: who sees and may do what (staff, manager, customer). The integrations: which packages, accounting or APIs come into play. And examples of today: screenshots of your spreadsheet, a sample email, an export. Those examples say more than ten pages of text.
Where should you have a web application built?
You can have a web application built by a freelance developer, a small dev studio or a larger software house. For SMEs, a small studio with short lines is usually the best balance: you talk directly to the builders, the price is keener than at a big house, and continuity is greater than with a single freelancer who could fall ill. The trade-off at a glance:
| Type | Strong at | Watch out for | Fits |
|---|---|---|---|
| Freelance developer | Price, speed, direct line | Continuity on illness or exit | Small, well-defined project |
| Small dev studio | Balance of price, quality, continuity | Limited capacity at peak | Most SME applications |
| Larger software house | Scale, formal processes, SLAs | Higher rate, longer lines | Enterprise, compliance, big budget |
More important than the type is what you agree on. Ask every party: do I get a fixed price for a clear scope, do I get the code in ownership, and what stack do you build on? A good partner answers those three without dodging. More on this in software studio vs freelance developer and in our complete guide to having custom software built.
What technology sits under a good web application?
The technology under a web application should be boring and mature, not exciting. A modern, widely used stack means you can easily find developers later who will take over your application, and that you are not locked into one supplier. According to the Stack Overflow Developer Survey 2025, PostgreSQL has been the most-used database among developers for years, and React and TypeScript are among the most-used web technologies (Stack Overflow Developer Survey 2025). That is exactly why they are good default choices.
Two requirements weigh more than the exact names. The first is code ownership: all source code in a Git repository under your account, with deploy instructions another party can follow. Without that, you rent software instead of owning it. Read why that matters in code ownership and vendor lock-in. The second is speed: slow screens cost usage directly. The probability that someone bounces rises by 32 percent as a page goes from 1 to 3 seconds of load time, according to Think with Google (Think with Google). A modern stack meets that bar by default.
How long does it take?
The timeline depends on the scope, not on the studio’s calendar. An MVP with one flow goes live in a few weeks, a standard portal in six to ten weeks, and a complex application in three to five months. The timeline is mainly determined by how fast you make decisions and how sharp the discovery was.
| Type of web application | Discovery + design | Build + test | Total |
|---|---|---|---|
| Internal tool or MVP | 1-2 weeks | 2-4 weeks | 3-6 weeks |
| Standard portal or dashboard | 2 weeks | 4-8 weeks | 6-10 weeks |
| Complex web application or SaaS | 3-4 weeks | 9-16 weeks | 3-5 months |
Want to validate quickly without building everything at once? Start with an MVP. How to phase that is covered in building an MVP: approach and phases. A concrete example of a custom platform from first conversation to production is in the Mastone case study.
The five mistakes that make a web application expensive
Most budget overruns come not from the technology, but from choices around the project. Five mistakes come back most often, and all five are avoidable with an agreement upfront.
- Building straight away without discovery. You build on assumptions and repay it in rework. Prevent it with a paid scope document.
- Wanting everything at once. A large scope in one go is slow and risky. Start with the flow that really matters and expand afterward.
- Asking for an app where a web application is enough. Two codebases, app-store costs and more maintenance, often without need. Weigh this explicitly, for instance against a no-code tool like Airtable or Notion for the first version.
- Not arranging code ownership. Ask before the start what you take with you if you were to leave. No concrete answer within five minutes is a red flag.
- A vague price agreement. An hourly rate without scope is a blank cheque. Ask for a fixed price per phase on a well-defined scope.
What does it cost to have a web application built?
In short: roughly €8,000 to €18,000 for an internal tool or MVP, €20,000 to €50,000 for a standard portal or dashboard, and €50,000 or more for a complex web application or SaaS. The price is driven by the number of screens, roles and integrations, not by the hourly rate alone. On top of that, budget 10 to 20 percent of the build price per year for hosting and maintenance.
That is the short version. The full breakdown per component, the difference from a website and an app, and a 24-month worked example live in our separate web application cost guide.
How do you start, concretely?
Start small and sharp. Write your problem down in two paragraphs, check whether an existing package or no-code is enough, and only then book a paid discovery instead of a free quote based on a hunch. A discovery of one to two weeks yields a scope document that lets you compare every quote on equal footing and makes most hidden extra work disappear.
Book a free intake call if you would like to look at it together. No sales pressure, just grounded advice on the route that fits your goal and budget.
TopDevs is a Dutch software agency that builds custom software, AI integrations and automations.
