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.
Why I care about keeping names consistent from Entity Framework models to Razor Pages forms and Cotomy, and how that reduces mistakes in long-lived business systems.
Why I stopped placing shared TypeScript infrastructure at the solution root and moved it into Core so Razor Pages and Cotomy could form one coherent application foundation.
How I place page-level TypeScript next to Razor Pages files and build a small shared foundation so Cotomy can stay aligned with endpoint boundaries.
How I use solution and project boundaries in Razor Pages systems to keep business functions understandable, extensible, and manageable in solo development.
Why inheritance is rarely used when designing entities in business systems.
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.
