What web app development involves

Where a website stops and an application starts

A website shows the same thing to everyone and forgets you between visits. An application remembers who you are, holds data on your behalf, and shows you something different from what it shows the person next to you. The moment either of those is true, a set of problems arrives that simply does not exist on a brochure site.

The line is not about complexity or budget. A three-screen tool where two people can edit the same record is an application. A forty-page site with a contact form is not. What matters is whether the system holds state that somebody can change.

The last row is the expensive one. On a website the failure modes are visible: something looks wrong, or does not load. On an application the serious failures are invisible from the outside, and you find them by going looking.

What the extra work actually is

People estimate applications by counting screens, which is why those estimates are wrong. Most of the additional work sits behind the screens and does not appear in a wireframe:

• Identity. Signing in is the easy half. Sessions expiring, devices being revoked, an invited user who has not accepted yet, and somebody leaving the company are all states the system has to hold.
• Authorisation, which is a different problem from identity and is where most real breaches live. Knowing who somebody is tells you nothing about what they may do.
• The data model, and what happens to it when requirements change. Migrating live data that people are using is a distinct skill from designing a schema.
• Concurrency. Two people editing the same thing, a request arriving twice, a job running while a user saves. All are normal, none are edge cases.
• Validation on the server, no matter what the form already checked. Anything the browser enforces can be bypassed by anybody who wants to.
• Audit and recovery. Knowing what changed, who changed it, and being able to get back a previous state.
• Rate limiting and abuse. As soon as an endpoint does work on request, somebody can ask it to do that work continuously.

None of these are visible in a demo, and all of them are visible in an incident. That gap is most of why application quotes vary so much between suppliers: some of them are pricing the screens.

Three failures from our own application

We run a dashboard behind this site, and we audited it rather than assuming it was fine. Three of the findings are published in full, with the fix and the test that now covers each. All three are impossible on a website, which is the clearest illustration of the difference we can offer.

1. A write that was meant to update an existing record would silently create a new one instead when the record was missing. Nothing errored. The data simply went somewhere else, and the only way to notice was to go looking.
2. A rate limiter that could be defeated by setting one request header. It counted requests correctly and attributed them to a value the caller controlled.
3. An identifier generated in a way that could produce the same value twice. Rare enough to never appear in testing, and permanent when it happened.

The pattern across all three is that each looked correct, passed review, and failed silently. That is the characteristic failure shape of an application, and it is why the testing budget on an application is not comparable to the testing budget on a site.

Publishing your own defects is unusual and it is deliberate. A supplier who has never found a defect in their own work has either not built anything with state in it or has not looked.

Dashboards, the most common shape

Most business applications end up as some kind of dashboard: a signed-in area where somebody sees their own data and acts on it. The design problems are consistent enough to be worth naming.

• Decide what the first screen is for before designing it. A dashboard that shows everything answers nothing, and the most common failure is a wall of cards nobody reads twice.
• Design the empty state first. Every user sees it, most designs skip it, and it is the screen that decides whether somebody comes back.
• Design the loading and error states as well. Real data arrives late and sometimes not at all.
• Numbers need a comparison to mean anything. A figure with no baseline is decoration.
• Density is a real trade-off, not a style preference. Somebody using this eight hours a day wants more on screen than somebody visiting monthly.
• Permissions change the layout, not just the contents. A viewer and an administrator should not be shown the same page with buttons quietly removed.

We keep a working dashboard example online rather than a screenshot, because the states above are the whole point and a screenshot shows none of them.

How to scope one without guessing

The most reliable way to size an application is to list the things that exist in it, and for each one, who may see it, who may change it, and what happens when two people change it at once. That list is short, a client can write it, and it predicts effort far better than a page count.

The second question worth answering early is what the system does when something goes wrong: whether a failed operation leaves a half-finished state, and whether anybody would know. A supplier who has a specific answer has built this before.

Start smaller than feels comfortable. The first version should be the smallest thing that puts real data in front of real users, because almost every assumption in the original plan changes on contact with them.

What this does not cover

• The three defects are from one application, ours. They are illustrative of a class of failure rather than a survey, and we have not counted how common any of them is in anybody else's code.
• This page covers what changes when a site gains state. It is not an architecture guide and it recommends no stack, because the right answer depends on the team who will maintain it more than on the technology.
• The dashboard section is design judgement from building them, not a usability study. We have not tested these points with users in any formal way and would not claim they hold universally.
• Nothing here is about mobile applications. A native app shares some of these problems and adds several of its own, including release cycles and store review, none of which are covered.
• There are no figures for effort or cost on this page, deliberately. Applications vary too much for a range to mean anything, and we publish no rates.

Sources

• The What Scene dashboard, audited 2026. Each of the three defects was found by reading our own code and rules against the behaviour we intended, then reproduced, fixed, and covered by a test that fails without the fix. Every one is published in full at the linked write-up, including the test. Run: /research/an-overwrite-that-was-a-create, /research/a-rate-limiter-one-header-could-defeat, /research/an-id-that-could-collide.
• What Scene engagement structure for applications. The scoping questions are the ones we actually ask before quoting work that holds state, defined in lib/documents/defs/engagement.ts and published at /resources/how-to-write-a-website-brief. Run: documents/transactional/project-brief, version 2026.1.

Revisions

• 31 August 2026 First published.

This page is revised in place rather than replaced, so its address does not change.