This sample excerpt is fictional and intentionally simplified. It shows the format of the results; actual findings, scope, and level of detail depend on the repository and intended use.
Simplified System Overview
Example scenario: A B2B web application developed with AI tools is to be opened to its first paying customers after a successful demo.
- Web frontend: Sign-in, customer management, and reporting.
- API application: Business logic, data access, and external integrations in one deployment.
- PostgreSQL: Customer, user, and transaction data.
- External identity provider: Sign-in; authorization is also handled in the application.
- CI/CD: Build and deployment are in place, but automated quality checks are only partial.
Critical flow: A user uploads transaction data, which is assigned to a tenant, processed, and shown in a report.
Decision Matrix
| System component | Decision | Rationale |
|---|---|---|
| Frontend structure | Refactor | User flows work; state and API access are tightly coupled. |
| Authentication | Keep | The external provider is integrated appropriately and encapsulated for replacement. |
| Authorization | Harden | Tenant access is not centrally enforced for every data access. |
| Data import | Refactor | Business rules and persistence are mixed; error handling cannot be tested reproducibly. |
| CI/CD | Harden | The build is reproducible, but migration and integration tests are missing as release criteria. |
Three Example Findings
01 · Tenant boundary not centrally enforced
Evidence: Two repository queries filter by a tenant ID supplied by the client; a shared server-side access context is missing.
Impact: Erroneous or manipulated requests could read another tenant’s data. This conflicts with the planned B2B use.
Recommendation: Derive the access context server-side, centralize data access, and add negative integration tests.
Effort class: M · Priority: immediate
02 · Schema changes are not tested for rollback
Evidence: Migrations run only at production startup; CI does not start an empty database or check either forward migrations or compatible application startup.
Impact: A faulty migration can block deployment and recovery.
Recommendation: Run migrations in CI against an empty and representative schema, document compatibility rules, and test the restore procedure.
Effort class: S–M · Priority: before launch
03 · Business logic is covered only by UI tests
Evidence: Import rules reside in the controller and data access; three central error cases cannot be tested in isolation without a full browser run.
Impact: Small changes require substantial review effort and increase the risk of unintended functional deviations.
Recommendation: Move import rules behind a clear interface, define representative sample data, and add fast domain tests.
Effort class: M · Priority: within 30 days
Example Decision
Conditional Go: A limited pilot with selected customers is viable once the tenant boundary is centrally secured and supported by negative tests. A general launch should additionally require migration verification and a tested recovery path.
The application does not need to be rebuilt. Authentication and large parts of the frontend can remain; authorization, import logic, and delivery require targeted measures.
Excerpt from the 30-/90-Day Plan
First 30 Days
- Centrally enforce tenant access and introduce negative integration tests as a release blocker.
- Verify database migrations reproducibly in CI; test backup and restore once under realistic conditions.
- Separate critical import rules from transport and persistence; add representative domain tests.
- Define error handling and monitoring for the import flow.
By Day 90
- Decouple frontend state and API access along the most important user flows.
- Version API contracts and test data for critical integrations.
- Fully document the roles and permissions model and review additional data access.
- Standardize quality criteria for changes in pull requests and deployment approvals.
What an Actual Architecture Review Adds
The full report includes specific repository references, scope and assumptions, a prioritized risk register, decisions for each relevant system component, open uncertainties, and a joint review of the results.