A web application starts from what people do, not from the homepage layout. Who signs in, what they can change, and what the next role is allowed to see — that is the product.
The actual problem
A website presents information. An application changes it: requests, orders, statuses, files, permissions. If that logic lives in buttons, every new field breaks a neighbouring screen.
It shows up when the database is a pile of tables with no relations, and two people edit the same record without a history.
A shape that holds
- a React or Next.js interface with no business rules inside components;
- an API that checks the role and returns only the fields that role may see;
- a database where the order, the client, and the status are separate records;
- background work for email, files, and exports, so the screen does not wait on the network.
Sign-in is a list of roles: client, operator, admin. Each role gets its own screens.
Example
A measuring-request service. The client creates a request and watches the status. An operator assigns a visit. A manager sees the week’s load. One application, three interfaces, one set of records. The “request received” email leaves from a queue, not from the button handler.
Before estimating, write the screens, the roles, what is stored, and which outside systems (payments, stock, mail) can be down without losing the request.