There’s a version of every troubled project where the problems were visible from the start, to anyone who looked carefully. The database schema that can’t represent the core business entity without a join across five tables. The event model that can’t support the audit log that compliance will definitely require. The authentication approach that can’t extend to the multi-tenant model on the roadmap.
What we review and why
A pre-engagement architecture review covers six areas: data model, API surface, authentication and authorisation model, infrastructure and deployment topology, observability, and test coverage. We’re not auditing for code quality — we’re looking for structural constraints that will become expensive problems later.
The most valuable output isn’t a list of issues — it’s a risk-ranked prioritisation. Not every architectural problem needs fixing before work starts. The review gives the team a shared, honest picture to make that call.
The conversation with clients
Some clients push back on a review. They want to ship, not audit. Our framing: the review takes a week and might save three months of rework. We’ve had that trade pay off on more projects than we can count.
We share the findings in a written report with a risk rating (high/medium/low) and a recommended action for each finding. High-risk items go into the project plan explicitly.
What we consistently find
The most common high-risk finding is a schema that can’t represent the business entity accurately. The second most common is an auth model that assumes a single-tenant deployment when the product roadmap clearly leads to multi-tenant. Both are cheap to fix at the start and expensive to fix at month six.