Short answer: Architecture first means designing the data, roles, approvals and integrations of a system before building its screens. For you it means five written documents before development starts, fewer rebuilds when requirements change, and a system another team could take over. If a vendor cannot show these documents, the design is probably in someone's head.
What does "architecture first" actually mean?
Most software is built screen by screen from a list of features. It looks finished quickly, and then each new requirement forces rework, because nobody decided early how the data, permissions and approvals fit together.
Architecture first reverses the order. Before anything is built, we map how work moves through your company, who can see and approve what, and which other systems the new one must connect to. That design is what keeps later changes small. We covered the argument in the feature list is not the system. This article is the practical side: what you should receive and how to check it.
What should you receive before any screen is built?
Five things, in plain language, in writing.
- A workflow map. How the work moves today and how it will move in the new system, including the exceptions people usually forget.
- A roles and approvals matrix. Who can create, review, approve and see each record. This is where many systems fail first.
- A data model overview. The main records, such as projects, contracts, invoices, customers or vehicles, and how they relate.
- An integration list. Which systems connect, in which direction, and who owns each connection.
- Deployment and handover notes. Where it will run, how it is released, and what documentation your team or another vendor would need.
These are not long documents. Their value is that you can read them, challenge them and correct them while changes are still cheap.
Why does it protect your budget?
Because the expensive changes in software are structural ones: a new approval step that touches every record, a second language, a second site, a new integration. When the structure was designed for change, these are contained. When it was not, they ripple through everything.
This is the author's view from the work we do, not a statistic. We design the data, roles and approvals first, so that your second, third and tenth change do not need a rebuild.
How does it show up in real projects?
On a construction project such as Al Mukab AlFudhi Engineering Consultancy's G+5P+15 building, inspections, submittals, drawings, bill of quantities finance, variations and payments all touch the same records. Getting those relationships right early is what lets the system keep one traceable record across them.
For EVS, the customer apps for iOS and Android, the staff web portal and the workshop-system integration had to agree on what a customer, a vehicle and a booking are before any screen made sense.
What is the difference between a design stage and a long planning phase?
A design stage ends with the five documents above and a written proposal. It is not a long programme of workshops. We then ship in modules, so you use real software early, and you commit one phase at a time. See our method for the stages and how we engage for the commitment model.
How can you check that a vendor does it?
| Ask the vendor | A good answer | A weak answer |
|---|---|---|
| What do I receive before development starts? | The five documents, or something close | "We start with wireframes" |
| Who signs off the roles and approvals? | You do, in writing | "We will work it out as we go" |
| How do you handle a change that touches many records? | Describe the data model and impact | "That will be a change request" |
| Could another team take over the system? | Yes, with documented handover | "Our code is proprietary to us" |
| Can I see an example? | A redacted workflow map or matrix | "It is confidential" |
When is architecture first not worth it?
For a small, throwaway tool with one user and one workflow, a design stage can be lighter. The more people, sites, roles and integrations involved, the more it pays back. If you are unsure which side you are on, our technology advisory work answers that before you commit to a build.
FAQ
Does architecture first slow the project down?
The first release can start slightly later, because the design comes first. In our experience, later changes are faster and cheaper, because they do not need a rebuild. That is the trade.
Do I need technical knowledge to review the design documents?
No. They are written in terms of your own work: workflows, roles, records. If you cannot follow them, they are not finished.
Is this the same as writing a full specification?
No. A full specification tries to fix everything upfront. The design stage fixes the structure and leaves room to change the detail as modules ship.
Can you review a system that was built without this?
Yes. An architecture review looks at how the data, roles and integrations are organised today and tells you what to fix first. See technology advisory.
Where does the scoping checklist fit in?
It comes before the design stage. Our scoping checklist helps you write the brief that the design stage starts from.
Want to see what the design stage produces?
Book a free 30-minute discovery call and we will walk you through an example.
