Tradeoff Studio.About
A NOTE FROM THE BUILDER

Systems aren’t static.
Our understanding
shouldn’t be either.

THE MANIFESTOV.01 / AN ONGOING EXPERIMENT

Requests move. Dependencies fail.
Traffic changes. Teams grow.
Constraints conflict. Decisions age.

Yet we often explain software architecture with a few boxes and arrows, frozen in a moment when everything works.

Architecture is less about drawing boxes and more about understanding what happens between them.

Tradeoff Studio exists to make their consequences visible.

01

Behavior before boxes.

A single line in a diagram can hide a timeout, a connection pool, a partition, or a queue quietly filling up. What I want to show is the part that happens between the boxes, because that is where the arguments usually turn out to be.

02

Trade-offs before dogma.

Every pattern answers a specific pressure and hands you a different kind of work in exchange. Whether it is good is rarely the useful question. The interesting one is what problem it is solving here, and what you are willing to pay for it.

03

I would rather you argued with the model than trusted it.

Everything here is a simplification, and each one is wrong in a specific way that I have tried to write down rather than hide. The recommendations are deterministic reasoning aids, not verdicts. If a result surprises you, the interesting move is to go and check it against something real — not to quote it back at someone in a design review.

a.
BUILT BY Abel

Why I built this.

I work as a software architect, mostly on distributed and integration-heavy systems, and I spend about as much time explaining architectural decisions as making them — to engineers who have to build the thing, to the people who will operate it at three in the morning, and to people whose real question is what it will cost them.

Both halves of that job keep running into the same wall. The diagram is where an architecture conversation starts, and almost everything that decides the outcome happens after it: a dependency slows down and the timeout you chose starts interacting badly with a retry somebody else added; traffic shifts and a queue nobody worried about becomes the constraint; a choice that looked small inside a rectangle turns into work the team carries for a year. None of that is visible in the picture, and describing it out loud only half works.

The other thing I keep running into is that there is no architecture that is simply correct. The same problem lands differently depending on the goals, the scale, the consistency you actually need, how many teams there are and what they can realistically operate. Two competent teams can face the same problem and reasonably choose different architectures. So this is not trying to tell you which architecture to pick. It is trying to make the consequences easier to reason about, so the choice is yours to make on purpose.

So I started building something that shows it instead. Tradeoff Studio is that, still growing, made in my own time. It is free, has no accounts, and collects nothing about the systems you model — partly on principle, and partly because a tool you have to sign up for is a tool you will not open on a whim.

How these models are built, and what they leave out What this site records
Try an experiment