The situation
A founder had built and launched a consumer-facing platform using AI-assisted development. A new commercial opportunity would increase its users and operational demands. The question was whether the existing system could responsibly support that next stage.
Investigate the system, not the stereotype
The review examined relevant code, architecture evidence, database migrations, serverless functions and tests. Tool-assisted findings were traced to their source, then checked by the lead architect. The investigation covered identity and trust boundaries, reliability, data handling, scale and maintainability.
What was sound, and what wasn't
The system had useful foundations, including real-time behaviour, structured data controls, bounded AI integration and testing. The main weaknesses involved trust boundaries, failure handling and test patterns that did not always exercise production paths.
What was sound
- Real-time synchronisation worked well.
- The database was properly structured, with access controls.
- AI integration was well bounded, with server-side keys and rate limiting.
- Payment processing reliably prevented duplicate events.
- A substantial automated test suite and continuous integration were in place. This was not a prototype.
Seven risk patterns
- Open doors at the protocol level: Real-time channels had no access control, and identity relied on visible, self-minted values rather than server-issued credentials.
- The client decides, the server records: Browser code controlled business-critical logic such as outcomes, state transitions and verification, and the server recorded whatever the client reported without checking it.
- One interruption ends everything: A single interruption on the host device ended the session for every connected user, with no pause and resume although the infrastructure could support it.
- A green light during an outage: Server errors were handled as empty successes, so users saw a healthy indicator while data was being lost, and an earlier failure of this kind went unnoticed.
- Tests that missed the production paths: Tests reimplemented algorithms internally instead of importing production code, so they documented intent but could not catch regressions.
- A scaling ceiling that was a setting: What looked like a fundamental architecture limit was a provider configuration setting, while the real bottlenecks were operational, such as unbounded logs, unexpected storage costs and rate limiting that did not hold at scale.
- A codebase built for one: Global state, scripts that only work in a fixed load order and core logic duplicated across modules suit one developer and become a constraint at two.
Some scaling limits were settings, not architecture
Some apparent scale limits were configuration or operating concerns. That distinction changed the response: targeted, sequenced hardening was more appropriate than a wholesale rewrite.
A roadmap in three horizons
- Immediate fixes: small, contained changes that close the most exposed risks first.
- Pre-scaling changes: architecture changes made before the commercial opportunity increases load and reliance on the platform.
- Structural unlocks: deeper changes that let the codebase support a growing team.
Inside the assessment
How evidence became a recommendation.
- Evidence examined
- The evidence base included repository code, architecture and review documents, a findings register, database migrations, serverless functions and tests.
- Checked by the lead architect
- Tool-assisted findings were traced to their source, then checked by the lead architect. The review kept independently verified findings apart from new implications, and weighed each against the product's current use and next commercial step.
- Decision supported
- The recommendation separated sound foundations from trust and failure-handling risks, and configuration concerns from structural changes. It supported targeted, sequenced hardening rather than a wholesale rewrite.
A finding that affected the recommendation.
Anonymised summary.
- Observation
- The assessment identified weak trust boundaries, with too much authority in client-side code and insufficient protection for certain real-time interactions.
- Why it mattered
- A working product still had significant trust and failure-handling risks to address before greater business reliance.
- Recommended direction
- Prioritise hardening of trust and authority boundaries while retaining sound foundations. Separate configuration and operating changes from structural redesign.
The architecture lesson
Keep what works. Fix the trust and failure risks before the next business stage. Sequence the structural work around the real business step.
Client and product anonymised.