Typical starting point
A launch, a first major customer, a funding round, a handoff to a development team, or a decision about further investment is approaching. The application visibly works, but its technical viability is unclear.
The key question
Is the application merely a compelling demo, or a reliable foundation for its intended use?
The architecture review does not assess whether the code was created with or without AI. It examines whether the specific application can meet its planned business, technical, and operational requirements.
Areas assessed
- System structure and responsibilities: Are system components, responsibilities, and dependencies separated in a clear, understandable way?
- Data model and data integrity: Do the model, storage, and consistency rules fit the critical workflows?
- Coupling and changeability: Can relevant changes be understood locally and implemented in a controlled way?
- Critical business logic: Are core rules discoverable, consistent, and sufficiently protected?
- Tests and reproducible validation: Can builds, tests, type checks, and quality checks be repeated reliably?
- Deployment, operations, and recovery: Are delivery, configuration, observability, and recovery robust enough for the intended use?
- Security baseline: Are obvious risks involving permissions, secrets, data access, and attack surfaces under control?
Results and deliverables
- Go, Conditional Go, or No Go for the intended use.
- A decision for each relevant system component: retain, harden, refactor, or replace.
- A prioritized risk register with technical evidence.
- Immediate actions for critical or readily reducible risks.
- High-level effort ranges, assumptions, and remaining uncertainties.
- A prioritized 30- and 90-day plan.
- A joint review of the results and transferable documentation.
An objective decision instead of an automatic rewrite
Critical findings initially lead to containment or targeted remediation, not automatically to a rebuild. Replacement is recommended only when the risks, level of change required, and target architecture clearly justify it. This preserves usable code and focuses the next investment on the bottlenecks that actually matter.
Scope and prerequisites
The architecture review requires:
- a defined repository state and a clearly bounded application,
- the key user workflows and intended use,
- existing architecture, data, and operational information,
- reproducible build and test steps, where available,
- accessible technical contacts for follow-up questions.
The specific scope, relevant system components, and deliverables are agreed upon before work begins. The review is repository-based; direct access to production systems is not required.
What is not included
- No formal penetration test.
- No security guarantee or certification.
- No legal, privacy, or licensing advice.
- No unlimited review of every line of code.
- No complete implementation of the recommended actions.
Frequently asked questions
Is AI-generated code inherently worse?
No. What matters is the architecture, data integrity, testability, delivery, and suitability for the intended use—not how the code was created.
Does the application already need to be deployed?
No. A defined repository state and information about the intended operating environment are enough for an initial assessment. An accessible test system can provide additional evidence.
Do you review Lovable, Cursor, or Claude Code projects?
Yes. The architecture review is tool-agnostic and also works for applications built with Lovable, Cursor, Claude, or comparable tools.
Will I receive a rewrite recommendation?
Only if the evidence warrants it. The assessment distinguishes for each system component between retaining, hardening, refactoring, and replacing it.
Can my existing team implement the action plan?
Yes. The plan is documented so that an internal team or another agency can take it over.