Where web projects die03 / 12
Six walls, six answers.
Complex builds rarely fail on the framework choice. They fail on the same six things, usually somewhere between month four and the first real user. Here is all six, and what we do about each.
01 — DomainThe real rules
The brief is not the business
The specification describes the process as management believes it works. The actual rules — the exceptions, the informal approvals, the three cases that carry the margin — live with the people doing the job and surface at acceptance.
What we doWe model the domain with the people who operate it: states, transitions and edge cases agreed in week one, before a single screen is designed.
02 — Legacy dataMigration
A database nobody dares to move
Fifteen years of records with duplicates, three encodings, fields reused for a different meaning in 2019, and a business that cannot pause for a weekend cut-over.
What we doMigration as engineering: profiling, mapping, dual-run against the old system, reconciled totals, staged cut-over and a rollback path at every step.
03 — AccessPermissions
Roles bolted on at the end
“Managers see their own region, except the group head, except during audit.” Retro-fitting that into a system built for one kind of user is a rewrite of every query and every screen.
What we doThe permission model is designed first and tested like business logic: roles, row-level rules, delegation, impersonation and a complete audit trail.
04 — ConcurrencyReal time
Two people, one order, same second
Dispatchers taking the same job, a stock level that goes negative, an approval applied to a document that changed underneath. Under real load these stop being rare.
What we doTransactional boundaries, locking and conflict resolution designed explicitly, with live updates pushed to open screens rather than discovered on refresh.
05 — PerformanceAt volume
Fine in the demo, unusable in year two
A screen built against 5 000 test rows meets two million real ones, a report locks the database at month-end, and the interface everyone lives in becomes the thing everyone complains about.
What we doVolume is a design input: query and index design, server-side pagination and virtualised grids, caching, background jobs and measured p95 budgets per screen.
06 — MaintainabilityYear three
A platform only its author can change
No tests, no types, no documentation, environments configured by hand, and one developer who knows why any of it works. Every change becomes a negotiation and eventually a rewrite.
What we doTyped code, automated tests, infrastructure as code, migrations and runbooks — built so the platform can still be extended in year eight, not just shipped in year one.