Mobile app or web app: when a browser is all your business needs

en 2026-09-22 8 min read

If what you need is customers logging in, managing bookings, paying or checking an order on their phone, the answer is a web app: step 04 on our ladder, EUR 3.500 to 7.500, built in six to twelve weeks, and usable on every phone, tablet and laptop from one codebase. A native mobile app is a separate product with its own builds, its own store approvals and its own update cycle, and it only earns that cost when your idea needs something a browser cannot do.

The case for the web app

Ask what "we need an app" has to do, and the answer is concrete: customers log in, see their bookings or orders, pay, message you, and do it on their phone. Every one of those runs in a browser. A web app is a website that behaves like software, with accounts, a dashboard, data and actions, and it works on a phone as well as on a desk.

The practical advantages all come from having one product instead of several:

• One build. An iPhone app and an Android app are two builds, or one cross-platform build with two sets of store requirements. A web app is one build that runs everywhere, including the laptop your staff use to manage it.
• No store in the middle. You ship a fix and every user has it on their next page load. There is no review queue and no customer running last year's version.
• A link is the install. You can send it by email, text, QR code or a button on your site. Nobody has to find you in a store, create a store account or give up phone storage before seeing what you offer.
• Search can find it. Public pages of a web app can be indexed and ranked by Google. The screens inside a native app are not pages anyone can search for.

A web app can also be added to the home screen, open full screen with its own icon, and keep working through a patchy connection for content it has already loaded. For a booking tool, a client portal, an ordering flow or an internal dashboard, that covers what "app" meant in the first place.

Requirement by requirement

Look at the admin row. A native customer app still needs a place for your team to manage bookings, users and content, and that place is a web dashboard. The web build is not the optional part. The native app is.

When you genuinely need a native app

The honest cases are specific. If one of these is the core of the product rather than a nice extra, a browser will hold you back:

• Work without signal. Field inspections, warehouse counts, anything used where there is no connection and has to sync afterwards.
• Background activity. Tracking a route, a delivery or a run while the phone is in a pocket.
• Hardware. Talking to a Bluetooth device, a wearable or a sensor continuously.
• A daily habit. A product people open several times a day, where the home screen icon and reliable notifications are the product.

Native app builds are not on our ladder. If your product sits in that list, do not hire us to pretend otherwise. What we will say is that the server, the data model, the login and the admin side are the same work whichever front end you choose, so building the web side first is not wasted.

What a web app costs and what moves the number

Step 04, the advanced site or web app, is EUR 3.500 to 7.500 over six to twelve weeks. It covers login, a dashboard, an API, CRM connections, payments and a chatbot where one is needed. Where you land in that range depends on:

• How many kinds of user there are, and what each one is allowed to see and do.
• Whether payments are one-off, recurring or split between parties.
• How many outside systems it talks to: calendars, accounting, a CRM, a shipping provider.
• Whether the data already exists somewhere and has to be moved in.

Step 05, a custom SaaS platform from EUR 7.500, is for a product you sell to other businesses: scope, authentication, billing, admin and deployment, priced after a discovery phase. A fixed quote always follows scoping, at either step. How we build these is on Next.js development, and the full ladder is on packages.

How the build runs

Scoping first: who uses it, what each person needs to get done, and which of the native-only requirements above, if any, are real. Then the data model and the screens in plain form, then design, then build in working increments you can click through on your own phone. Then review and launch.

The six to twelve week range is wide because the variables above are wide. The part that waits on you is decisions: who can see what, what happens when a payment fails, what the confirmation email says. The sooner those are answered, the closer the build sits to the start of that range. How design and engineering run together is on design and engineering.

When to spend less

• If you do not yet have customers asking for an account, you do not need an app of either kind. A step 03 business website with booking or a contact flow, EUR 1.500 to 3.500 over three to six weeks, tests the demand first.
• If your "app" is really a way to take appointments, try an existing booking tool linked from your site before commissioning software.
• If you want to test an idea, a single-page landing at step 01, EUR 600 to 900 in one to two weeks, with a sign-up form tells you whether anyone wants it before anything gets built.
• If your product needs one of the native-only abilities listed above, do not hire us yet. Talk to a mobile team first, then come back for the web dashboard it will still need.

Questions buyers ask before they commit

Will customers take a web app seriously without an App Store listing?

Customers judge whether it works and whether it is fast. A web app that opens from a link and lets them do the job straight away compares well with an app that asks for a download first. If your buyers search app stores to find products like yours, that changes the answer, and you should weigh it honestly.

Can we add a native app later?

Yes. If the web app is built on a proper API, a native app later becomes a new front end on the same system rather than a second product. That order keeps early spending on the parts you need regardless.

Can a web app take payments?

Yes. Payments and checkout are part of step 04, together with login and the dashboard. On the web you choose your payment provider. Inside a native app, some digital purchases have to go through the store's own billing, which is one more reason to check before assuming native.

Who owns the web app and where does it run?

You own the code, the repository and the database. Hosting is agreed per project: we can host it, and that is settled in scoping along with the rest of the running costs, rather than decided by default.

What does it cost to keep it running?

Care is EUR 100 to 300 a month and covers updates, monitoring, backups and small fixes. New features and redesigns sit outside Care and are quoted as their own work.

Tell us what your users need to get done on their phone, and we will tell you whether that is a web app and which step it is. Describe the project.