Companies search for custom web app development when an idea needs to become a real digital product: a customer portal, an internal tool, a SaaS platform or a workflow system. The most important point first: a web app is not a website with a login. It is software that represents processes, changes data, manages roles and must run reliably.
That is why cost cannot be answered with a single fixed number. In 2026, specialized agencies in the DACH region bill hourly rates between 120 and 180 EUR — so the real lever is not the rate, but the scope. This article explains, with current figures, what a web app costs, how long it takes and which architecture decisions shape the budget early.
A web app is a product, not a larger website
The most expensive misconception is budgeting a web app like an extended website. A website displays content; a web app changes data. As soon as users log in, edit records, trigger workflows, upload files or collaborate, you create requirements for authentication, permissions, data modelling, security, performance and operations.
Typical web apps are customer portals, SaaS products, booking platforms, internal dashboards, CRM or ERP extensions and workflow software for teams. They share one trait: the visible part in the browser is only the tip. Beneath it sit business logic, a data model and an operations concept that determine maintainability and follow-up cost — and that is what effort is measured against, not the number of screens.
What does custom web app development cost?
Cost depends mostly on complexity, risk and integrations — not the number of pages. As a rough orientation for professional custom development in the DACH region:
| Project type | Typical scope | Realistic range |
|---|---|---|
| Validation prototype | clickable or partly functional prototype, few core flows | 10,000–25,000 EUR |
| MVP | login, core feature, data model, admin area, deployment | 25,000–80,000 EUR |
| Production web app | roles, integrations, tests, monitoring, privacy, operations | 80,000–200,000 EUR |
| SaaS platform | multi-tenancy, billing, permissions, reporting, support | from 150,000 EUR |
These figures are planning ranges, not a price list. A tightly scoped MVP can cost less; a regulated product with sensitive data can cost more. The important part is to budget beyond version one: operations, maintenance and ongoing development, security updates and support are part of the real economics of a web app. A rule of thumb: budget roughly 15–25% of the initial build per year for ongoing operations.
Four factors drive effort most: product scope (every role and edge case costs), the data model that carries all future features, integrations to payment providers, CRM, ERP or SSO (the biggest uncertainty), and security and compliance (audit logs, encryption, backups, deletion concepts). All are cheaper planned from the start than retrofitted later.
How long does development take?
A realistic timeline is measured in months, not weeks — and plans for operations from day one. A typical flow:
| Phase | Duration | Result |
|---|---|---|
| Discovery | 1–3 weeks | goals, user roles, core processes, risks |
| UX and prototyping | 2–5 weeks | information architecture, wireframes, clickable flow |
| MVP development | 6–12 weeks | first product-like version |
| Hardening | 2–6 weeks | tests, performance, security, migration |
| Launch and operations | ongoing | monitoring, support, product iteration |
A first production version often appears in three to five months. It moves faster when decisions are clear, data sources are available and scope is ruthlessly prioritized. It slows down when stakeholders are unclear, integrations are untested or the product changes direction constantly during development. How an MVP fits cleanly into a roadmap is covered in building an MVP.
Architecture: the decisions that save money later
The most expensive mistakes are not in the code but in early architecture decisions. The data model, role model and operations concept are hard to change after launch. A proven, durable default stack for SaaS web apps looks like this in 2026:
On the frontend, React and Next.js 16 are a strong base — server rendering, routing, metadata APIs and, since version 16, the React Compiler and Turbopack by default. The backend is best organized API-first: frontend, admin, mobile app and integrations talk to documented endpoints. For the database, PostgreSQL 18 is a highly reliable standard with relational integrity, transactions, full-text search and JSON fields. Auth and roles are not a form but architecture: roles, invitations, password reset, SSO, 2FA and often multi-tenancy. Hosting and operations cover deployments, rollbacks, backups, logs and monitoring — on Vercel, Hetzner, AWS or Kubernetes. How we set up the data model and interfaces cleanly is shown in our backend development.
Performance, SEO and accessibility
Not every web app needs SEO — but every publicly reachable one must be measurably fast and accessible. An internal admin area does not need SEO; public landing pages, product pages and documentation do. Google measures loading, interactivity and visual stability through the Core Web Vitals: LCP, INP and CLS. Since 12 March 2024, INP has replaced the old FID metric — an INP of 200 ms or less counts as good. Poor values usually come from large client bundles, blocking scripts or layout shifts.
There is also a legal duty: since 28 June 2025, Germany's Accessibility Strengthening Act (BFSG) has been in force. Web apps offered as an electronic service to end consumers must meet EN 301 549 / WCAG 2.1 AA; micro-enterprises with fewer than 10 staff and at most 2 million EUR annual turnover are exempt for services. Accessibility is far cheaper when designed in from the start — more in our BFSG and WCAG checklist.
MVP or the full platform right away?
An MVP is not a cheap product but a focused one. It makes sense when market, process or business model still need validation — but it should not be disposable. It should be technically clean enough to evolve. The wrong question is "What can we remove to make it cheap?" The right one is "What is the smallest version that proves the most important value?"
For a SaaS web app, that often means starting with one core workflow, a simple role model, manual billing and a few integrations. Billing automation, reporting and deeper integrations follow once value is proven. How an MVP turns into a viable platform is described, with a Hamburg case, in web app development in Hamburg.
Next steps
Three questions sharpen the plan faster than any feature brainstorm:
- Users and roles: Who works with the application, and which permissions do they need?
- Data and integrations: Which data changes, and which existing systems must be connected?
- Version one: What is the smallest version that proves the most important value — and what can deliberately wait?
The clearer these answers are, the more accurately cost, timeline and architecture can be planned. We usually start web app projects with a short product and architecture workshop. See our web app development or book a first call.
