A web application does not become bad because it is old. It becomes bad when nobody can explain why it was built the way it was.
Typical starting situations
- An application works, but every change takes longer than the last one.
- The frontend stack can no longer be updated without touching half the application.
- Business logic is spread across templates, database triggers and a folder of scripts.
- A platform needs to serve several tenants but was built for one.
The technical work
- Designing applications with clear layering and explicit responsibilities
- Server-side rendering wherever content must be reachable without JavaScript
- Untangling existing applications step by step instead of rewriting them wholesale
- Shaping data models that survive changes in the business domain
- Treating deployment, operation and rollback as part of the design
How we approach it
Technology decisions are reasoned through and written down — including what is deliberately not used. A framework that makes one task easier today but binds the application to a version line for years is rarely the cheaper option.
System context
This website is an example of that approach: server-rendered, no database, no client-side framework, content stored as versioned Markdown files. The architectural decisions live in the repository rather than in a settings dialog.