AI
Why Architectural Decisions Are Hard to Reverse
Every architectural decision closes a door. The further a project progresses, the harder it gets to change direction, because choices embed in data models, team structures, pipelines, and organizational processes. Jedrzejewski started commercial programming in 2011 believing you could design everything upfront and then move on. That belief did not survive contact with real projects. The actual challenge is that early choices ripple forward and constrain what comes later. Architecture is not about the perfect design. It is about keeping options open as long as possible.
How Teams Over-Engineer Before Understanding the Problem
Two forces push developers toward overengineering. The first is the cognitive shortcut: brains categorize fast, which works in survival situations but causes developers to jump to solutions before understanding the problem. The second is FOMO. A company rebuilds on Kubernetes and suddenly a functional monolith feels embarrassing. The logic, “if it works for Google it will work for us,” ignores that every tool brings learning curves and operational costs conference talks never mention. New team members then take months instead of weeks to get productive, and knowledge silos form fast.
problems. Spoiler, it won’t. — Maciej Jedrzejewski
Discovering the Business Domain Before Picking Technology
Every abstraction and every boundary flows from how well a team understands its domain. Event storming forces that understanding by working in business facts rather than CRUD assumptions. Participants post events on a board, “contract signed” not “button clicked,” then group them along a timeline to expose real process flow. Domain storytelling gives domain experts the stage to narrate the process, surfacing handoffs that linear requirements documents miss. Bounded context canvas then captures each context’s purpose, strategic classification, and ubiquitous language in one place.
Mapping the Operating Environment
Domain knowledge is not enough. Team skill set, budget, and organizational structure all shape what architecture is viable.
A competency matrix maps who knows what. Three Java experts and one C# developer points toward Java, not whatever won a recent conference. Budget follows the same logic: Jedrzejewski treats infrastructure spend like personal money. A $100 component on a $1,000/month budget is a 10% hit; the same $100 on a $100k/month budget is noise. Deployment strategy is no different. A regulator requiring 3-week firmware audits makes continuous deployment impossible regardless of what the team prefers.
The Four Phases of Architectural Evolution
Jedrzejewski and colleague Camil Bonk named four phases: simplicity, maintainability, growth, and complexity. The rule is to identify which phase the system is in now. Simplicity is one project, modules as namespaces, one database with multiple schemas. Maintainability triggers when in-memory queues fail and teams step on each other. Growth triggers when infrastructure costs cross 15% of revenue. Complexity triggers when regulations make simple solutions structurally inadequate. The medical clinic four-phase walkthrough (33:49) tracks 1,000 users to half the European market, showing exactly which signals forced each transition.
We had more services once than users. — Maciej Jedrzejewski
Our logging bill was higher than our compute bill. — Maciej Jedrzejewski
Notable Quotes
problems. Spoiler, it won’t. Maciej Jedrzejewski · ▶ 5:47
We had more services once than users. Maciej Jedrzejewski · ▶ 44:32
Our logging bill was higher than our compute bill. Maciej Jedrzejewski · ▶ 45:01
Key Takeaways
- Architectural decisions compound: early choices embed in data models and team structures and are costly to reverse.
- Start with the business domain, not the technology stack — every boundary and abstraction flows from domain understanding.
- Add complexity only when the pain of not having it is real and measurable, not when it feels prudent.