From the outside they look alike: both open in a browser, both have an address you can share. Yet you are buying two fundamentally different things. A website tells people who you are and what you do. A web application does work: users log in, enter data, and the system acts on it.
That distinction is not semantics. It sets your budget, your timeline and the maintenance you are signing up for. Choose too big and you pay for technology nobody uses. Choose too small and you squeeze a business process into a tool that was never built for it. Below: where the line runs, when a web application is worth the investment, and how one gets made, from idea to go-live.
Same screen, different work
A website shows every visitor the same content: service pages, case studies, vacancies, a knowledge base like this one. Interaction stays limited to browsing and, at most, a contact form. That is not a shortcoming, it is exactly what a website is for: getting found and making the case.
A web application is software that runs in the browser and moves with the user. Think of a customer portal where clients track their orders, a scheduling tool that calculates rosters, a dashboard that combines figures from several systems, or your online banking. There are accounts, data comes in, and that data gets processed and stored. Nobody has to install anything and everyone works in the same, current version. But the bar rises too: security, access management and reliability suddenly carry real weight.
Four questions that decide the choice
Hold your plans up against these four questions:
- Do users need to log in and see something meant only for them?
- Do they carry out tasks, such as ordering, scheduling or entering data?
- Does the system need to process and store data, or just display it?
- Does it need to work together with other systems, such as your accounting or your stock?
Four no’s mean a website is enough, however big your ambitions are otherwise. Every yes pushes you towards a web application, or a website with an application behind it.
Choosing too big costs money, choosing too small costs more
One risk is building an application where a website would have done. You then pay not only for developing accounts, a database and admin screens, but also for the maintenance, year after year, of functionality no visitor asked for.
The reverse happens more often and hurts more: a website stretched with forms and plugins until it resembles an application. Submissions land in inboxes, colleagues keep spreadsheets alongside it, and nobody knows which version is correct. The moment people do manual work next to the site to finish the process, you have crossed that line.
When a custom web application is worth the investment
A yes to the four questions does not yet mean you should have something developed; for many tasks standard software is good enough, and then that is the sensible choice. Custom development becomes interesting when your process differs from what standard packages assume, or when your team does manual work to move data between systems that do not talk to each other. How to weigh that up is covered in our article on custom web applications versus SaaS.
How a web application gets made, from idea to go-live
Having a web application made for the first time, you probably picture mostly the programming. In practice that is one of five steps, and each step asks something of you as the client.
- Sharpening the brief. Your process comes first, not the technology: which work the application must take over, who will use it and what they may see and do, which systems it exchanges data with, and what stays out of the first version. Your contribution: bring the people who run the process every day to the table, because they know the exceptions.
- Designing. The agreements are translated into screens you can click through before any code is written. This is where you notice whether the application works the way you work. Corrections at this stage are still small.
- Developing in rounds. The application grows in steps, each time with a working version you can review. You help decide what the next round delivers and what can wait. Testing is part of every round, not left for the end.
- Rolling out and going live. Existing data is migrated and checked, colleagues learn the application, and the old system often runs alongside for a while. Your role: pick a moment outside your busiest period and appoint an internal point of contact.
- Maintaining and developing further. After go-live, real use begins, and with it the requests for improvement. Reserve budget for that from the start. Read more about ongoing development and maintenance.
You do not need to choose the technology underneath in advance. You may expect the team to pick proven technology that can still be maintained years from now, and to explain why; more on this in our article on programming languages for web applications.
What the choice means for budget and timeline
You develop a website in weeks; a web application takes months. That difference does not lie in the screens, but in what sits underneath: a data model that holds up, permissions and security, connections to other systems, and the testing that makes all of it reliable. How much time each step takes and where delays come from is covered in our article on the timeline of a web application.
We deliberately do not quote a fixed amount here: the price follows from the number of user roles, the integrations and the volume of data. The misunderstandings about that are set out in three misconceptions about the price of custom web applications. Also budget for structural maintenance. A website that stutters for a day is annoying; an application your business process runs on cannot go down. That difference belongs on paper from the very first budget.
Start with the work, not the technology
The most useful question is not which technology you want, but which work the system needs to take off your hands. If you want to get found and make your case, that is the territory of our websites. If work needs doing, with accounts, data and integrations, you land at web applications and portals. We develop both, and we regularly advise the smaller of the two. Does your question sit somewhere in between? Those are exactly the cases we like to put on the table together.