Web App Development Guide: Web App vs Website, Process, Costs
A practical guide to web app development: how a web app differs from a website, when custom beats off-the-shelf, the building blocks, process and cost factors.
A web app is software that runs in the browser: people sign in, work with their own data, and the system remembers what they did. Custom web app development makes sense when your processes don’t fit standard software, or when you want to give your clients a portal of their own. This guide covers what a web app is made of, how a project runs, what drives the effort and what to ask a developer.
Web app vs website: the real difference
A website informs. Everyone sees the same pages. A web app does a job: after signing in, each person sees their own data and can create, edit or approve things.
| Aspect | Website | Web app |
|---|---|---|
| Purpose | inform, win enquiries | get tasks done |
| Content | the same for everyone | different per person and role |
| Login | usually none | central to the product |
| Data | copy and images | records that users create themselves |
| Logic | little, such as a form | rules, calculations, notifications |
A contact form doesn’t turn a website into an app. A booking system with customer accounts, cancellation deadlines and reminder emails does. Common examples:
- a client portal where customers see orders, documents or invoices
- a booking or reservation system with its own rules
- an internal tool for orders, staff scheduling or stock
- a platform that is itself the business
If what you need is really a good website with a feature or two, start with our web design and development page.
When a custom web app is worth it, and when it isn’t
Before commissioning a web app, look honestly at the alternatives. There are broadly three.
Off-the-shelf software fits when your process is standard for your industry: accounting, newsletters, a common booking tool. You pay a recurring fee for updates and support, and you adapt to the software rather than the other way round.
No-code tools let you assemble databases, forms and automations with clicks instead of code. For internal lists, small teams and first prototypes, that’s often enough. It gets harder with fine-grained permissions, outside clients, per-user costs and the question of where your data lives.
A custom web app is the right call when at least one of these applies:
- Your way of working is part of why clients choose you.
- You regularly copy data by hand between several programs.
- Clients or partners should be able to look things up or get things done themselves.
- You want to keep your data, your code and future development in your own hands.
Otherwise, ready-made software is usually the better choice, and a good developer will say so.
The building blocks of a web app
What happens when you click in a web app
- 1InterfaceA user clicks “Approve order” in the browser.
- 2Login and rolesThe server checks who this is and whether they’re allowed to approve.
- 3Backend and APIThe logic validates the input, updates the status and sends a notification.
- 4DatabaseThe new state is stored permanently and visible to everyone with access.
Integrations: through the backend, the app can talk to other systems such as payment providers, email delivery, calendars or accounting.
Interface (frontend)
Lists, forms, filters, dashboards: what people see and use. It should work on a phone as well as on a large screen, and with a keyboard and screen reader. Public parts such as a booking form should load as fast as a good website; the Core Web Vitals are a useful yardstick.
Backend and API
The backend runs on the server and holds the rules: who may do what, which deadlines apply, what happens after a booking. The API is the interface through which the frontend and the server talk to each other. Built well, it can later serve other programs or a mobile app too.
Database
Clients, orders, appointments and how they relate to each other. The data model is among the most important decisions in the project. A clean model can still be extended years later. A sloppy one slows down every new feature.
Login and roles
Sign-in with a password or a link sent by email, plus roles such as client, staff and admin. The finer the permissions, the more precisely they need to be described up front.
Admin area
A back office where your team adds users, changes settings and maintains content. Often forgotten in planning, it’s the part your staff will use most.
Integrations
Payments, email, calendars, accounting or the software you already use: a lot can be connected, as long as the other system offers a documented interface or at least a data export. Check that before anyone commits.
The process, from first conversation to live operation
1. Pin down the requirements
Start with who needs to get what done, not with a feature list. Short sentences help: “As a client, I want to see my open invoices so I don’t have to ask.” Then the edge cases: what happens with a cancellation, a duplicate entry, a forgotten password?
2. A clickable prototype
Before any code is written, there’s a design you can click through. This is where misunderstandings surface while they’re still cheap to fix. Show it to the people who will actually use the app.
3. A first working version (MVP)
The first real version contains only the most important workflows, but complete: with login, real data and proper storage. MVP stands for “minimum viable product”, the smallest thing that’s already useful in daily work. Real users test it and show you what’s missing.
4. Build it out step by step
From there, the app grows in small stages. That keeps the direction adjustable, and you don’t pay for features nobody ends up using.
5. Operations
A web app isn’t finished at launch. It needs hosting, regular backups, security updates for the server and the libraries it uses, and someone who responds when something goes down. Agree early on who takes this on.
What drives the effort
We deliberately don’t quote price ranges: two web apps with similar names can differ enormously in effort. These factors decide it:
- Roles and workflows: every role and every workflow with its own rules has to be built and tested.
- Edge cases: exceptions, deadlines and approval steps often take more work than the normal path.
- Integrations: how many systems need connecting, and how well documented are their interfaces?
- Data migration: existing spreadsheets or legacy data need cleaning up and moving across.
- Interface: a custom design or proven components, one language or several.
- Security and availability: health or financial data calls for more care than an internal holiday planner.
- Operations: hosting, maintenance and further development are ongoing.
Our article on how much a website costs covers running costs and comparable quotes, and that applies here too.
Web app or native app?
A native app is built for iOS or Android and distributed through the app stores. A web app runs in any modern browser, with one codebase for every device. Updates reach all users at once, with no store review in between.
As a progressive web app (PWA), a web app can also be added to the home screen and open in its own window. With a service worker, it can cache content and work partly offline (MDN: Progressive web apps).
A native app is mainly worth it when your users look for the app in the app stores, or when you need device features that the browser doesn’t offer or only offers in part. Browser support varies by operating system, so check your specific features first.
Security and GDPR: the essentials
As soon as personal data is processed, the GDPR applies if you or your users are in the EU. This isn’t legal advice, but a few basics apply to every web app:
- Store passwords safely: never in plain text, always with a hashing algorithm designed for passwords, such as Argon2 or bcrypt. Then nobody on the team can read them either.
- Check permissions on the server: hiding a button in the interface isn’t enough. Broken access control is one of the risks listed in the OWASP Top Ten.
- Encrypted connections: HTTPS throughout, including the admin area.
- Data minimisation: store only what the purpose really needs (Art. 5 GDPR) and build privacy in from the start (Art. 25 GDPR). That includes deciding when data gets deleted again.
- Server location: if you prefer, servers and database can run in the EU. If a provider processes data on your behalf, you need a data processing agreement (Art. 28 GDPR).
- Backups and updates: regular, automatic, and with a restore that has actually been tested.
How to choose a web app developer
Portfolios say little about how a project will run day to day. These questions tell you more:
- When will I see the first clickable prototype, and when the first working version?
- Which technology do you use, and is it common enough that someone else could take over later?
- Who owns the code, the data and the access credentials after the project?
- Where is the data stored, and will you sign a data processing agreement?
- How do you test, and how do you handle security updates?
- Who looks after the app after launch, and how quickly do you respond to an outage?
- How are change requests during the project handled and billed?
Your briefing checklist
- What problem should the app solve, and how is it handled today?
- Who will use it: clients, staff, partners? With which permissions?
- The three to five most important workflows, in plain sentences
- Known edge cases and exceptions
- Systems that need to be connected
- Existing data that has to be migrated
- Devices: mainly phones, mainly desktops, or both?
- Requirements for data protection and server location
- What goes into the first version, and what can wait?
- Timeline and a rough budget range
- Who takes care of operations and further development after launch?
We build web apps like these end to end, interface, backend, database and login, and can look after them once they’re live. You’ll find how we work on our web app development page. Or use the contact form to tell us briefly what your app should do and who will use it.
Frequently asked questions
What is the difference between a web app and a website?
A website informs, and every visitor sees the same content. In a web app, users sign in, work with their own data and get things done, such as booking an appointment or tracking an order. That takes a backend, a database and user management.
How much does it cost to have a web app built?
There's no honest flat price. Effort depends mainly on the number of roles and workflows, the integrations with other systems, migrating existing data and ongoing operations. Starting with a small first version gives you a reliable picture sooner.
Can a web app be installed on a phone?
Yes. As a progressive web app (PWA) it can be added to the home screen and opens like an app, without an app store. With a service worker it can also show some of its content offline. Which device features are available in the browser depends on the browser and operating system.
Who owns the source code of a custom web app?
That's down to your contract with the developer. Put in writing which rights you get to the code, where the code is kept and that you receive access to the server, database and domain. That way you can continue with someone else later if you need to.
Are no-code tools an alternative to a custom web app?
For internal tools, small teams and early prototypes, often yes. Limits tend to show up with fine-grained permissions, access for external clients, per-user pricing and where your data is stored. Check up front that you can export all of your data.
