Web app development: cost, process, internal vs. customer-facing

You want an app built and you keep tripping over the term "web app" — but nobody tells you clearly what it actually is and when it's worth it. The honest short answer: a web app is a full-blown application that runs in the browser — no download from the App Store, on every device, with a single codebase. For most business applications it's the cheaper and faster choice. Only when you need deep device features or maximum performance is there no way around the native route. Let's look at what fits when.

What is a web app — and how does it differ from a website and a native app?

The three terms get mixed up constantly. But the difference is decisive for your budget and your options.

• Website: primarily for reading and informing. Home page, services, contact, blog. The user consumes content but barely interacts. Classic example: the company homepage.
• Web app (web application): an application in the browser that you work with. Log in, enter data, process it, evaluate it. Think of a customer portal, a booking system, an internal tool for order management or a dashboard. The line to a website is fluid — the difference lies in the interaction and the logic behind it.
• Native app: a program you download from the app store that gets installed directly on the device. It has full access to camera, sensors, background processes — and only runs on the platform it was built for.

So a web app is more than a website but less locked-in than a native app. It runs anywhere a browser runs — Windows PC, Mac, iPhone, Android phone, tablet. A link is enough, no download.

When is a web app the smarter choice?

For a large share of all business applications, the web app is simply the more economical decision. These five advantages make the difference.

1. No store gatekeeping, no store commission

A native app has to go through Apple's and Google's approval processes. That costs time, nerves and ongoing fees — and for sales inside the app, Apple takes a substantial cut. A web app you just open via a URL. No review, no rejection over a guideline that changed last week, no revenue share to a corporation.

2. One codebase for all devices

That's the biggest cost lever. Native often means two separate apps — one for iOS, one for Android — plus possibly a desktop solution on top. A web app you build once and it runs the same on every device. One team, one codebase, one maintenance track. That lowers not just the initial investment but above all the running costs over the years.

3. Instant updates, no approval

Want to fix a bug or roll out a new feature? With a native app you build a new version, submit it to the store, wait for approval — and hope your users actually install the update. With a web app you deploy the change to the server, and on the next visit everyone immediately has the current version. That's worth gold especially for business logic that changes often.

4. Nothing to install

The hurdle of downloading an app from the store is real — especially for tools someone might only use a few times a month. A link opens right away. For customer portals, booking flows or applications you share by email or QR code, that's a tangible advantage in adoption.

5. Findable via Google

A web app lives on the web — so it can be found and shared through search engines. A store listing competes with millions of other apps; a well-built web application ranks on Google and is directly reachable via a link.

Internal web apps: what employee tools need that customer apps don't

A large share of the requests that reach us aren't about a customer-facing product at all. They're about an internal tool: order management that currently lives in a spreadsheet that grew out of control, vacation planning by email, quality checks on paper. Technically that's the same web app. In practice it differs in five places — and those five points are missing from a lot of quotes.

1. Roles and permissions, not just "logged in or not". In a customer application, everyone sees their own data. Internally, warehouse staff need different views than accounting, temps shouldn't see margins, and management needs the report across everything. That's not a detail, it's a component of its own — for us an option from €1,400.
2. A login that fits the company. Nobody on your team wants an eleventh password. Signing in with the account that already exists — Microsoft 365, Google Workspace or your directory service — is the sensible route. That integration is real work (our login option, anchor: from €1,400), but it cuts support effort and is what makes point 5 solvable at all.
3. Integration with what's already running. Internal tools rarely stand alone: inventory management, time tracking, accounting exports, CRM. We price each clean interface from €1,900. An internal tool that wants its data maintained twice won't be used after three months — at that point you've just rebuilt the spreadsheet chaos, more expensively. Here's how such an integration actually works: API integration: connecting your systems.
4. No app store — but you need an offboarding plan. This is the advantage nobody internally wants to give up: no store approval, no users refusing updates, one link on the intranet, done. The flip side: when someone leaves the company, access has to be gone immediately — including open sessions and API tokens. That's why permissions hang off one source of truth (see point 2), why access gets logged, and why you decide up front what happens to that person's data. Retrofit it and you pay for it twice.
5. Built for heavy users, not first-time visitors. A customer application has to be self-explanatory the first time. An internal tool gets used eight times a day — keyboard operation, bulk editing, sensible defaults and fast search matter more than a pretty landing screen.

The starting point for these projects is almost always the same, by the way: a spreadsheet that got too big. We've written up how that switch works and how you know it's due: replacing Excel with custom software.

Your website as an app: PWA, wrapper or native?

One question comes up almost every time the word "app" is mentioned: "Can't we just publish our website as an app?" There are three technical routes — and one of them is a trap.

• PWA (progressive web app): your web app gets an icon on the home screen, opens full screen and works to a degree offline. No store, no fees, no approval. For tools that employees or regular customers use routinely, this is usually the right answer.
• WebView wrapper: an app shell that does nothing but display your website in a browser window. Sounds cheap, but it's risky: Apple's App Review Guidelines, section 4.2 "Minimum Functionality", explicitly require features, content and UI that elevate an app beyond a repackaged website, and apps that don't differ enough from mobile browsing get rejected — a few bolted-on push notifications aren't enough (source: Apple Developer, App Review Guidelines 4.2, accessed 09/2026). Take that route anyway and you often pay twice: once for the shell, once for the real app.
• Native: the right call when you need things the browser doesn't offer — reliable push on iOS, background transfers, deep camera or sensor use, widgets. How to decide that properly is in our comparison: native app or cross-platform.

The order we recommend: check whether a PWA is enough first. If it isn't, build native deliberately — but on the same backend, so you don't pay for anything twice.

Progressive web app: the best of both worlds

The line between web app and native app is softer today than many think — thanks to progressive web apps (PWA). A PWA is a web app that feels almost like an installed app.

Concretely that means:

• On the home screen: the user can put your web app on their home screen with its own icon. It then opens full screen, without a visible browser bar — visually hard to tell apart from a native app.
• Offline capability: via a so-called service worker (a small script in the background) a PWA can cache content and keep working without a stable connection. A field service worker can capture data even when there's no signal in the customer's basement.
• App feel: fast load times, smooth transitions, an icon, a splash screen. For many use cases that's entirely enough — without the effort of real app development.

For many companies the PWA is the sweet spot: the reach and simplicity of a web app, combined with the app experience users expect.

Where a web app hits its limits

Honest stays honest: a web app can't do everything. There are clear cases where we'll advise you to go native — even though that takes more effort.

• Push notifications on iOS: for a long time there were no web push notifications on iPhone at all. They're possible now, but only if the user has added the PWA to their home screen first — and with limitations. If reliable push notifications are central to your concept, a native app is the safer choice.
• Deep device features: Bluetooth peripherals, NFC, background location tracking, demanding camera processing or Face ID — the browser has deliberately tight boundaries here. Standard camera and GPS work, exotic stuff mostly doesn't.
• Maximum performance: for very graphics-heavy applications, games or smooth 120 fps animations, native plays to its strengths. For business applications, though, users rarely notice the difference.
• Store presence as a marketing channel: if your audience actively searches for apps in the store and a listing there is part of your marketing, that's an argument for native.

We've broken down how exactly to weigh the native vs. cross-platform question in a separate post. The good news: you don't have to commit dogmatically. In many projects we start with a web app or PWA and only add native parts once a concrete feature genuinely calls for it.

Our stack: React/Next.js on the frontend, Laravel on the backend

How a web app is built decides its speed, maintainability and future-proofing. Over time a proven combination has crystallized for us, one we can deliver quickly and reliably with.

• Frontend with React and Next.js: that's the visible interface in the browser — fast, modern and search-engine friendly. Next.js makes sure pages load quickly and get picked up well by Google. This very website, by the way, runs on Next.js.
• Backend with Laravel: the invisible backbone. This is where your data, the business logic, login, permission management and the interfaces to other systems live. Why we build on Laravel has solid reasons: it's mature, secure and quick to extend without starting from zero.

The big advantage of this separation: frontend and backend are cleanly decoupled. If you later want to build a native app as well, it can reuse the same Laravel backend — you don't have to rebuild the foundation. Everything we build in app development is designed for this growth path from the start.

A typical real-world example: an online booking system. Customers book an appointment in the browser, and in the background Laravel manages availability, sends confirmations and syncs calendars. No store needed, usable on any device, updatable at any time — a prime example of why a web app is the right call here.

What does web app development cost? Pilot €3,900, options, €119/month

The short answer: it depends on what it should be able to do. But we'll give you concrete numbers instead of vague hints — the way we actually calculate: a base package plus individually priced building blocks.

Anything beyond that — extra functional areas, special requests, extensions after launch — we bill at €79/h, transparently and traceably. You can put your own configuration together on our pricing overview.

Two things people underestimate when comparing quotes. First, ongoing care isn't optional: a web app depends on framework versions, security updates and a server — without maintenance it becomes a liability within two years. Second, a low entry price is worth little if roles, integrations and data migration get added later without you ever seeing them as a number. That's exactly why there's a table here instead of a single "from" price. And because many web app projects raise the app question sooner or later, it's worth a look at what you need to budget for app costs overall.

Web app, website or native app — the quick decision guide

Notice the pattern? As soon as it's about working with data and reach without hurdles, the web app plays to its strengths. Native is the right choice when the device itself is at the center.

Bottom line: thinking web app first almost always pays off

For most business applications the web app is the smarter choice: one codebase instead of two, no store gatekeeping, instant updates, reachable on every device. With a progressive web app you get the app feel on top, without the full effort of native development. Only when deep device features, reliable iOS push or maximum performance are central does the path lead to a native app. The good part: a cleanly built Laravel backend carries both routes — so you never lock yourself in unnecessarily.

And if your project is an internal tool, the same holds with different building blocks: roles, sign-in with the company account, integrations with what's already running. That's classic custom software — just in the browser instead of on the desktop.

Wondering whether a web app fits your project — a customer portal, an internal tool instead of that overgrown spreadsheet, or a native app after all? Send us two or three sentences about who'll be working with it and which systems have to play along. In a free initial call we'll tell you honestly which route is cheaper, which building blocks you actually need, and what that costs according to the table above. No obligation, and you'll know where you stand.

Frequently asked questions