"We just need a dashboard." Almost every web app conversation opens that way, and the sentence is almost always wrong. Not out of naivety: the dashboard is the only part anyone can see. Underneath it sit sign-in, roles, permissions, tenants, billing, and the question of who is allowed to see which row.
That invisible part is most of what you pay for.
What it costs to build a web app: the short answer
A web app costs $30,000–55,000 to build for a lean first release in 8–14 weeks, and $55,000–110,000 for a product with several roles, real integrations and the reporting a business runs on, in 12–20 weeks. What moves the number is roles, integrations and how live the data has to be.
Indicative band, not a quote — the fixed number comes out of a paid discovery sprint and is credited against the build. Figures here are in US dollars; Swiss and EU clients are quoted from the Swiss-franc and euro editions of the same 2026 rate card, issued by your contact.
Website or web app? The line decides the price
A website shows content. A web app holds state: you sign in, change something, and on your next visit the change is still there, for you and for the right colleagues. Deciding who counts as one of the right colleagues is the permission model. That is where most of my time at CODT Technologies goes, and it is invisible in every demo.
If you are having a web app built, these are the four things driving the effort, and design is not one of them:
- Roles. Two roles are an if-statement. Six roles with exceptions are a permission model that has to be tested, because a mistake in it shows one customer another customer's data.
- Integrations. Every external system arrives with its own authentication, its own outages and its own rate limit. The integration is rarely the hard part. Coping with its bad days is.
- Live data. "Live" costs a multiple of "current when you reload", and it is a running cost that never goes away.
- Regulated data. Health, payment or HR data bring audit logging, retention periods and a deletion policy with them. None of it ever shows up in a clickable prototype.
If what you have in mind is essentially a form three people fill in each week, with a spreadsheet behind it, buy a no-code tool and keep your money. Don't spend it with us. Building that from scratch is the most expensive option available to you. We've written at length about when building beats buying.
What each project shape costs
| Project shape | Team | Duration | Indicative band |
|---|---|---|---|
| Lean MVP — one core journey, proven off the shelf where it can be | 2–3 engineers | 8–14 weeks | $30,000–55,000 |
| Standard product — several roles, real integrations, admin and reporting | 3–4 engineers + delivery lead | 12–20 weeks | $55,000–110,000 |
| Complex platform — multi-tenant, regulated data, migration beside a live system | 5+ engineers, multi-discipline | 20+ weeks | $120,000–250,000+ |
Indicative 2026 bands, not a quote. What moves the number is complexity — integrations, compliance, data migration and the reliability bar you need on day one. Every engagement is priced fixed and in writing after a paid discovery sprint, and the sprint is credited in full against the build.
Then there is the running cost the first budget almost always forgets. Annual support typically runs at 15–20% of the original build cost. With us the first 30 days after launch are under warranty; after that a support plan starts at $550 a month. Our cost calculator prices your specific shape in two minutes, and if the web app is going to be sold on subscription, the SaaS cost guide is the closer fit. Native apps run on a different calculation, which we set out there.
How the project runs, step by step
The first workshop and a high-level estimate are free — usually back within three working days. After that:
- Discovery sprint, 1–2 weeks, $2,900–4,900. You get a written scope, a system architecture, a costed roadmap and an explicit "won't build" list — yours to keep, and the document the fixed quote is written from. The sprint is credited in full against the build.
- Foundations. Tenants, sign-in, roles, deployment pipeline, staging. For the client this is the dullest stretch of the project, because there is almost nothing to look at. It still decides the next few years.
- Core journeys. A working build on staging every two weeks, one your own people can genuinely use.
- Hardening. Load tests, permission tests, failure paths, restoring from backup. This is the phase that gets compressed first when a date slips.
- Go live, then 30 days of warranty.
Two commercial points worth knowing up front. All work product and source code belong to you on payment. 100% of the IP transfers — no lock-in, no per-seat licence. And a fixed price is available, but only after the paid discovery sprint: a fixed price issued against an enquiry email is guessed rather than calculated, whoever signs it.
A partner portal you can check the maths on
FeelEat runs connected fridges in Switzerland and stocks them from its own kitchen. The B2B partners operating those fleets had no view of their own data. Every question (why did this fridge stock out, what is selling at site B, when should I restock) was a phone call to support. Internally there were dashboards. Partners had email.
We built a multi-tenant portal: React on the front, Node.js with NestJS behind it, per-fridge stock in real time, demand forecasting, revenue analytics by fridge and product. Two details from it, because both are typical of web apps. Hundreds of fridges per partner polling every 30 seconds would have flattened the API, so a Redis-cached read layer went in front, and only the actively watched fridges are pushed over WebSocket. Tenant separation sits in the database as well as the code: row-level security in MySQL, so that even a query missing its WHERE clause cannot return another partner's rows. Platform foundations are what I work on at CODT Technologies, and that doubled-up separation is the one thing I won't trade for delivery speed.
The first version of the demand forecast was worse than the experienced operators. It took seasonality, day of week and per-site demand signals before it reached 94% restocking accuracy.
What we could measure afterwards: support calls down 68%, around 320 calls deflected a month, 180+ daily active partner users, NPS from +38 to +71. The full case study is here.
Three decisions that land in week one
- Multi-tenancy. "We'll do it later" is the most expensive sentence in the project, because the assumption that exactly one organisation exists leaks into queries, caches, background jobs and file paths. Why that becomes a rebuild rather than a refactor.
- Identity and roles. Your own user management, or your customers' corporate login. Adding the second one later is doable, but it touches every permission check written up to that point.
- Billing. If money changes hands, the model belongs in front of the first line of code. Per-seat, per-tenant and usage-based billing each imply a different shape of tenancy and a different set of permission checks, and retrofitting one onto another means reopening every one of them.
How we start
You describe who is going to use the web app and what those people do instead today. On the first call we tell you which part of it you should buy rather than build. An NDA comes before any technical discussion. A DPA and standard contractual clauses are signed as standard. How we build this kind of application is on our web app development page.
