Signs Your Web App Was Built Without Architecture

Most web applications don't fall over on launch day. They fall over the first time traffic, data or a new feature arrives in volume, and by then the choices behind them are expensive to undo. Here are the signs worth checking for, whether you're commissioning a build or inheriting one.

Speed and load

• Load times that were fine in a demo but drift once real users and real data arrive. A page that felt instant in testing has a habit of revealing what was never designed for concurrency.
• A database that behaves well with a handful of records and less well with thousands. This is usually a design question, not a hardware one.
• Timeout errors that appear under load and vanish when you test alone. They tend to be symptoms of something structural rather than a flaky connection.
• No documented performance limits. If nobody can say what the system is expected to handle, nobody can tell you when it's about to stop handling it.

Velocity and debt

• Each new feature takes noticeably longer than the last. That curve is a signal. Shortcuts taken early make the next piece of work harder, and the one after that harder still.
• A small change that requires touching three other systems nobody wrote down. Undocumented dependencies are a form of interest that compounds quietly.
• Frontend and backend that seem to have been designed by people who never spoke. When the API returns data the interface doesn't need, or a single screen fires a dozen requests, both sides pay for it.
• Authentication that breaks at the edges. Login is the first thing real users hit and the last thing anyone wants to debug under pressure.

The questions worth asking

• Can anyone show me the architecture, not just the screens? A working interface tells you very little about what sits behind it.
• What happens at ten times the current load? The answer should be specific, not reassuring.
• Is there a staging environment, logging and error tracking, or does production double as the test bed?
• Does the API have documentation someone else could maintain? If the only person who understands it has left, that's the answer.
• Was security reviewed before launch, or is it on a list somewhere? Data validation and auth handling are not features you add later without cost.

A good result looks unglamorous from the outside: pages that stay responsive as usage grows, features that ship at a steady pace, and documentation that lets a new developer contribute without a tour guide. The absence of drama is the point.

The full guide sets out what a properly architected build actually includes — the environments, documentation, performance benchmarks and security checks — and how the work runs from requirements to production. It's worth reading at Foundry 5's web development page before you commission or inherit anything.