Describe the workload before the boxes
Record who uses the application, from where, on which devices and at what expected scale. Note peak patterns and growth expectations honestly. An architecture sized for imagined traffic adds operational cost; one sized too small costs a rebuild. Write the numbers down so later decisions can be checked against them.
Map the data and its ownership
List the entities, their volumes, retention needs and which system owns each one. Decide where records of different sensitivity live and who may read them. A mobile or offline app needs the sync and conflict rules decided here, before any screen is designed against the data.
Choose integration boundaries
Name every external system — payments, email, ERP, instruments — and the contract each exposes. Favour explicit contracts over shared databases. Decide what happens when a provider is unavailable: queues, retries and a reconciliation path are architecture decisions, not later fixes.
Plan the run, not just the build
Agree environments, deployment, backups, monitoring and who is paged when something fails. The operating team's skills are part of the architecture: adopting more managed services can reduce code but increase coordination. Document the decision so the trade-off is reviewable later.
Bring this to your project brief.
- Expected workload, devices and growth numbers
- Entity list with ownership, retention and sensitivity
- Integration contracts and failure behaviour
- Environment, backup and monitoring ownership
Use general descriptions or anonymized examples. Do not put credentials, personal records or confidential documents into the brief.
Prepare your project brief