Why I Avoided a SPA for a Large Internal System
A practical reflection on why a large CRUD-heavy internal business system with many screens was easier to build and maintain without making SPA architecture the default.
A practical reflection on why a large CRUD-heavy internal business system with many screens was easier to build and maintain without making SPA architecture the default.
In teams of one to three people, continuity depends less on role separation and more on shared understanding, document granularity, and records that let the work be handed over when necessary.
Why Cotomy ended up with multiple form layers, and how that structure came from the gap between desktop application habits and web runtime reality.
In CRUD screens, the core problem is often not where state is stored, but whether the mutation path is defined. Once load, input, save, and reload are allowed to diverge, the screen becomes difficult to reason about.
Server-side postback screens were limited, but they kept one execution path. Once Ajax became the main update mechanism, keeping display, input state, and server truth aligned became a structural problem.
State failures in business UIs are usually not isolated bugs. They appear when DOM state, in-memory state, and server state have no explicit ownership and synchronization rules.
Why I moved from natural keys to surrogate keys, and why that change made both database design and application code easier to manage.
I do not follow development methodologies rigidly. Some environments break them entirely. What actually moves projects forward is adapting to the real constraints in front of you, not applying theory.
AI coding agents are useful, but they work from narrow context rather than stable architectural intent. That makes software design and compact feature boundaries more important, not less.
A practical reflection on how I use ChatGPT, Codex, and Copilot to design first, code second, and reduce the risk of AI-driven development.