"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 engineering time to build: a lean first release takes 2–3 engineers over 8–14 weeks, and a product with several roles, real integrations and the reporting a business runs on takes 3–4 engineers plus a delivery lead over 12–20 weeks. What moves the number is roles, integrations and how live the data has to be.
Indicative 2026 figures, not a quote. Your quote comes in writing, at a fixed price, within three working days of the free 4-hour workshop; only when the scope is still open does a paid discovery sprint come first, credited in full. Swiss and EU clients get it in francs or euros from their 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 |
|---|---|---|
| Lean MVP — one core journey, proven off the shelf where it can be | 2–3 engineers | 8–14 weeks |
| Standard product — several roles, real integrations, admin and reporting | 3–4 engineers + delivery lead | 12–20 weeks |
| Complex platform — multi-tenant, regulated data, migration beside a live system | 5+ engineers, multi-discipline | 20+ weeks |
Indicative 2026 figures, not a quote. What moves the number is complexity — integrations, compliance, data migration and the reliability bar you need on day one. After a free 4-hour workshop, you get a written scope and a quote within three working days; for a clearly defined scope, that quote is a fixed price. If the scope is still open, a short paid discovery sprint comes first, credited in full against the build, and the fixed price follows it.
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 comes a support plan sized in hours per month. Our cost calculator sizes your specific shape in team and weeks 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 takes four hours and costs nothing; within three working days of it you have the scope and a quote in writing. Then:
- Discovery sprint, 1–2 weeks, if the scope is still open. 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.
What we need from you at each of those steps for the timeline to hold is written up from the delivery side by Minakshi: custom software development, process and costs.
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 the normal case, but only after the workshop: 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 companies that host those fridges for their staff had no screen of their own. Every request (extra food for a team event, the office closed next week, more staff starting on Monday, what sold at site B) meant writing to FeelEat. Internally there were dashboards. Partners had email.
We built a multi-tenant portal: React on the front, Node.js with NestJS behind it. In it, a partner company places special orders, marks the days its office is closed, raises or lowers its staff numbers, creates vouchers for its employees, books FeelEat's tasting event and sees the sales from its own fridges. One detail from it, because it is typical of web apps: tenant separation sits in the database as well as the code. Row-level security in MySQL means 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.
Since then, partners do all of that themselves in the portal. 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.
