Landing pages, dashboards, customer flows
loading…
Page count is a poor proxy for engineering effort.
Start with what the user sees, then work downward: data objects, state changes, business rules, external systems, and operational controls. That is where the estimate lives.
Landing pages, dashboards, customer flows
iOS, Android, permissions, push
Configuration, support, content, refunds
Analytics, alerts, reconciliation, moderation
Write down the nouns the business cares about. In a class-booking product, the list may include:
The nouns are not enough. A booking moves through states, and every transition creates rules: who may trigger it, what must be true, what is recorded, and how failure is recovered.
A single “Book” button may trigger a full state machine.
Walk through each important workflow in plain language before drawing architecture.
Walk the transaction User selects a class → system checks capacity → membership is validated → payment is authorized → seat is reserved → booking is confirmed → notification is sent → admin dashboard is updated.
Then break the happy path. Two users request the last seat. The payment succeeds but the write fails. The instructor cancels an hour before class. These are not edge decorations; they are part of the product.
Rule of thumb Surface → Entities → States → Workflows. This sequence helps you see the system behind the screen.