SA on Tech System Failures: Common Architecture Mistakes and How to Fix Them
Ten architecture mistakes SA finds in every audit, their root causes, business impact, and remediation cost. The root cause analysis of why they happen, and SA’s five-step rescue protocol for fixing a broken system without creating new problems.
The Architecture Mistakes SA Sees Most Often
In five years of building and auditing production systems, SA has identified a set of architectural mistakes that appear repeatedly across different teams, industries, and project types. These are not random errors — they are predictable failure modes arising from the same root causes: insufficient requirements analysis, skipping the design phase, and building without architectural discipline.
With Business Impact and Remediation Cost
| Mistake | Root Cause | Business Impact | Remediation Cost |
|---|---|---|---|
| No privacy rules on data types | Never learned they were required | Security vulnerability; enterprise sales blocker | High — must be set carefully to avoid breaking existing functionality |
| Stripe status from redirect URL | Did not understand webhooks | 10-15% of paid customers have no access | Medium — add webhooks; audit and fix affected accounts |
| :filtered by in all searches | Did not know the performance difference | App unusable as data grows | Medium — systematic replacement with search constraints |
| Live count queries on dashboard | Did not know denormalisation | 10+ second dashboard load at scale | Medium — add denormalised fields and update workflows |
| Unpaginated repeating groups | Thought pagination was optional | Browser freezes on large datasets | Low — add pagination to each repeating group |
| Roles on User, not Membership | Did not design multi-user roles | Users have same role across all workspaces | High — data migration and new Membership-based role system |
| API keys in data fields | Did not know API Connector Private flag | Credentials visible via browser network tab | Medium — move to Connector; rotate compromised keys |
| No architecture documentation | Never prioritised | New developers take weeks to onboard | Low — retroactive documentation is possible |
| Frontend workflows for heavy operations | Did not know backend workflows | Operations fail when users navigate away | Medium — move to backend API workflows |
| No pre-launch testing protocol | Tested happy paths only | Vulnerabilities discovered by real customers | Low — implement testing protocol and run retrospectively |
The Root Cause Analysis
Skipped the Design Phase
The most expensive mistakes originate from building without designing first. Decisions cheap at design time become expensive after customers are using the system. The fix is commitment to design before build.
Learned From Incomplete Resources
Most tutorials teach how to make things work, not how to make them work correctly at scale and in production. A tutorial showing :filtered by does not mention that it is catastrophic at 10,000 records. Architects learn from production experience; developers often learn from tutorials.
Optimised for Speed Over Quality
Early founders optimise for speed. Correct for validation. Incorrect for production architecture. The right model: spend three hours designing correctly, then build at full speed. The three hours of design saves weeks of rework.
Fixing Broken Systems Without Creating New Problems
Assess before touching anything
Full Architecture Review before any changes. Understand the complete current state, all problems, and all dependencies. Changing a system you do not understand creates new problems while fixing old ones.
Fix critical security issues first
Any data type without privacy rules. Any exposed credentials. Any webhook handler without signature validation. These are fixed before anything else, even under deadline pressure.
Fix billing issues second
Any Stripe integration relying on redirect URL. Any missing webhook handlers. Any billing state incorrect for existing customers. Billing errors cost money and customer trust directly.
Fix performance issues third
Replace :filtered by with constraints. Add denormalised fields. Add pagination. Measure improvement at each step.
Add documentation last
Once the system is secure and performant, document what it now looks like. Documentation of a remediated system is more valuable than documentation of the broken system would have been.
Work With SA — Simple Automation Solutions
a no-code systems architecture practice. We design tech systems before we build them.