Philosophy
Radical
Simplicity.
"When there are two options, opt for the simpler one — until complexity necessitates the advanced option."
Premature complexity is the enemy. Systems, teams, and processes should be minimal, durable, and driven by actual business needs — not by what's trending on Hacker News.
This applies to greenfield projects and refactoring existing systems alike, whether it's a web application or a pure backend service. Domain-Driven Design reveals the right boundaries and translates them into architecture — which then gets implemented hands-on, together with the teams.
Radical Simplicity goes beyond code. It spans three pillars.
Team Structure.
Small Domain
Teams.
Vertical teams organized around business domains, not horizontal backend/frontend splits. Small, autonomous, and aligned with the bounded contexts identified through DDD. Each team owns its domain end-to-end.
This structure reduces handoffs, speeds up decisions, and gives teams real ownership over the value they deliver.
Development
Process.
Lean & Agile.
Lightweight processes like Kanban over heavy ceremony. The goal is flow and fast feedback, not process for process's sake.
Keep the overhead low so teams can focus on delivering value. The best process is the one you barely notice.
Tech Stack.
Minimal &
Durable.
Start with the simplest thing that works. Add complexity only when the problem demands it, not before.
Modular monoliths over premature microservices. Server-side rendering over SPAs — unless you're building something that genuinely needs it. Choose boring, proven technology. Scale the architecture when the load requires it, not because a blog post said so.
This is not just about code or architecture diagrams. It's a holistic approach — how teams are structured, how they work, and what they build with. All three need to be aligned for software to ship sustainably.
More detail on this, specifically for web applications: Radically Simple Web Architecture. The philosophy applies equally to pure backend systems and services.