Web app development
A working demo can still hide the decisions that make a web application dependable.
The short answer
A dependable web application starts with the work people must complete, the records it holds and the rules around who can change them. Build one complete workflow at a time, include errors and permissions from the start, test the important behaviour automatically and keep the code, accounts and deployment process in the owner's name.
A web application is not a collection of finished screens. It is a set of decisions about data, access, failure and ownership that keep producing the right result after the demonstration ends. The build goes well when those decisions are visible early and each release proves a complete piece of the real work.
Start with the record the application is responsible for.
Every useful application has something at its centre: an account, a request, a property, a study, an order or a case. Screens, notifications and reports are different ways of viewing or changing that record. If the team cannot name it and describe the states it moves through, the interface is being designed before the product has a stable foundation.
Write the important states in ordinary language. A request might be drafted, submitted, returned, approved, completed and cancelled. Then name who can move it between those states, what evidence is required and what must be preserved afterwards. That exercise exposes more of the real build than a list of pages ever will.
It also makes scope smaller. Several requested screens may be views of the same record, while one quiet exception may require a different permission or audit rule. The application should be shaped around the work, not around the order the screens appeared in a workshop.
Build a complete slice before building every screen.
A horizontal build finishes all the layouts, then all the data work, then all the integrations. It looks busy for months and produces nothing a user can complete. A vertical slice follows one real task from entry to result, including the database, permissions, validation and feedback that task needs.
The first slice should test the most consequential uncertainty, not the easiest screen. If permissions are complicated, prove two roles can safely work on the same record. If an integration controls the result, connect a narrow real flow early. If the core value depends on a report, produce it from real sample data before polishing the surrounding dashboard.
1. Choose one finished task
Pick something a real user can start and complete. Define the starting information, the result and the person who knows whether it worked.
2. Include the rules around it
Add the permissions, validation, empty state and common failure path. Leaving them for later creates a second design for the same feature.
3. Put it on a real environment
Deploy the slice somewhere the owner and users can access. A branch on a developer's machine is progress, but it is not yet a product decision you can inspect.
4. Use it before widening it
Run the task with representative data and record what breaks or feels unclear. Fix the model before adding adjacent screens that depend on it.
Permissions, errors and recovery are part of the feature.
The happy path tells you what the product does when everyone has the right access, enters valid information and every connected system responds. Real use is mostly the edges around that path. Someone opens an old link, loses a connection, submits twice, changes roles or needs to reverse an action that was correct yesterday.
Treat those states as ordinary design work. Show the user what happened, what remains safe and what they can do next. Preserve enough history for an accountable person to understand a change. A generic error message and a database log do not give a non-technical owner a workable recovery process.
This is also where security becomes concrete. Instead of claiming the application is secure, list which roles can see, create, change, export and delete each important record. Test those boundaries. Access control is behaviour that can be demonstrated, not a paragraph added to a proposal.
| Concern | Question to settle | Evidence before release |
|---|---|---|
| Permissions | Who can do what to each record? | Role-by-role tests against the important actions |
| Validation | Which inputs are acceptable and why? | Clear field feedback and rejected invalid requests |
| Recovery | What happens after failure or a mistaken action? | A safe retry, reversal or accountable manual path |
| History | What needs to be understood later? | Useful timestamps, actors and state changes |
Quality has to be visible to someone who cannot read the code.
A non-technical owner should not have to accept a weekly percentage as proof. The clearest signals are working software, a written account of what changed and repeatable checks around the behaviours that would be expensive to break. You should be able to log in, complete the promised task and see the same release the team is discussing.
Automated tests belong around business rules, permissions and the paths used most often. They do not replace a person using the product. They make routine changes safer so human review can concentrate on whether the workflow still makes sense.
We keep the repository and operating accounts under the client's control from the beginning. That turns ownership into something checkable. It also forces documentation and deployment decisions to work for the next capable team, not only for the people who remember how the first release was assembled.
Handover starts before launch.
A handover assembled in the final week usually describes the ideal system and misses the practical knowledge needed to change it. Record setup, architecture decisions, external services, release steps and known limits while they are still current. Keep the instructions close to the code so a change to one can trigger a change to the other.
The owner should know where the code lives, which accounts run the application, how a release is approved, how it is reversed and who receives an alert when something fails. Those answers matter before launch because they reveal dependencies that are still cheap to remove.
The finish line is not that the original team can operate the application. It is that another competent team could understand it, release it and make a bounded change without first rebuilding the missing map.
Worth knowing before you start
Ask the team to demonstrate one complete user task on the same environment you will approve, rather than touring isolated screens.
Write permissions as actions against records. Role names alone hide what a person can actually see or change.
Put the riskiest integration or rule into an early slice. A polished shell does not reduce the uncertainty inside it.
Keep the repository, hosting and external service accounts in the owner's organisation from the first release.
Related work
Common questions
Define the primary users, the records the application owns, the important states those records move through, role permissions, the first complete workflow, external dependencies and acceptance criteria. You do not need every future screen. You do need enough clarity for the first release to prove one useful result.
You should see a usable slice regularly, usually whenever a complete piece of work is ready to judge. The important part is not a ceremonial schedule. It is that demonstrations happen on an accessible environment, use representative data and show a full task rather than a collection of unfinished screens.
Judge the evidence around it: working releases, automated checks on important behaviour, clear ownership of accounts, readable change notes, repeatable deployment and documentation another team can follow. A separate technical review can inspect the code itself, but these operating signals reveal whether quality is being maintained between reviews.
The client should own the repository and the accounts the application depends on. The development team can manage them day to day, but access should not depend on keeping one supplier. Ownership is easiest to arrange at the start and needlessly difficult to repair after launch.
Related
Want to talk through your situation?
A short call is usually enough to tell whether this is the right work for you. If it isn’t, we’ll say so.