The Architecture Manifesto: Building Software That Survives

A manifesto for building evolvable systems that survive production, not just demos. Why most software fails and how to design for the real world.

Photo of Brandon Lanthrip

Brandon Lanthrip

January 7, 2025

“A complex system that works is invariably found to have evolved from a simple system that works. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work.” — John Gall, Systematics

The Architecture Manifesto: Building Software That Survives

The Problem: Fragile Software

Is your system feature complete or production ready? While they may seem similar, these are fundamentally different goals. Delivery is often optimized for the wrong outcome, shaped by flawed incentive structures like moving tickets across a board or satisfying a spec on paper. This is checkbox engineering: the illusion of progress without the substance.

As a platform transitions from an internal platform to an externalized product, its architecture and development will need to face the hard truths of evolvability, maintainability, and sustainability. Fragile integrations, unclear domain boundaries, and high incidental complexity threaten its ability to grow, adapt, and survive at scale.

Thesis: Reframing Architecture as Engineering

This manifesto argues for a deliberate shift: to approach architecture through the lens of disciplined, fundamental engineering. That means designing for failure, minimizing points of brittleness, and optimizing not just for “working” but for surviving through stress, change, growth, and time.

In order to achieve this, we draw from two traditions:

  • Classical Engineering: The principle of design for manufacturability; solutions that are cost-aware, maintainable, and built to endure
  • Domain Driven Design: Structuring software around business truth through modular boundaries and strategic decoupling to reduce complexity and increase autonomy

Architecture, in this view, is not an aesthetic exercise or a theoretical playground. It is a continuous negotiation between speed, stability, and flexibility. One that must reflect both technical realities and organizational structure.

The Implication: A Product Bearing System, Not a Project-Bound App

What emerges from this perspective is a system that can carry the weight of being a product, not just a project. That means:

  • Shifting from monolithic deliverables to independently evolvable components
  • Embracing self-contained teams with ownership boundaries aligned to architectural seams
  • Prioritizing real-world feedback loops over speculative completeness

By internalizing these principles, any service can become a platform that earns its place in production, not just one that demos well.

The Six Principles of Evolvable Architecture

Over the next few posts, I’ll dive deep into each of these principles:

1. Design for Production, Not Just Delivery

Build systems for the real world with real users and unpredictable conditions. Prioritize durability, transparency, and recoverability over short-term velocity.

2. Anticipate Failure, Then Survive It

It is impossible to develop a fool-proof system, because the universe will always produce a better fool. Expect faults, contain errors, and engineer failure modes that protect what matters most.

3. Minimize Coupling, Maximize Autonomy

Loosely coupled systems with clearly defined seams enable independent evolution. Structure both code and teams to reduce coordination overhead and enable parallel progress.

4. Reflect the Domain

Architecture should mirror the business. Use Domain-Driven Design to anchor service boundaries in reality.

5. Evolve with Feedback

Production is the only truth; everything before it is rehearsal. Build small, ship often, and let the system adapt through tight, continuous feedback loops.

6. Guard Against Integration Risk

Integration points are the number-one killer of systems. Every dependency adds fragility. Use decoupling patterns like circuit breakers and async messaging to decouple failure and prevent crack propagation.


This is part 1 of a 5-part series on building evolvable architecture. Next: Building for Production →