Projects That Live and Projects That Just Exist

The architect Christopher Alexander spent a career circling something he refused to give a clean definition. He called it "the quality without a name," and described it as "the root criterion of life and spirit in a man, a town, a building, or a wilderness." It is the thing that makes one room feel alive and another feel like a waiting area, one product feel right and another feel like it was assembled by people who had never met a user. You cannot point at it. You know instantly when it is missing.

I should admit upfront that I am the wrong person to be lecturing anyone about this. I grew up in the ship-it-yesterday school, where speed beat everything and "good enough" was a finish line rather than a warning. There is real comedy in me shortening "quality without a name" to QWN, in an essay about resisting efficiency, like a man writing a letter about the dangers of sugar while eating a second slice of cake. Old habits.

But I have been stuck on one line of Alexander's for a while. "This quality cannot be made, but only generated, indirectly, by ordinary actions, just as a flower cannot be made, but only generated from the seed."

That is the whole argument, and it has a direct consequence for how anything gets built now.

The seed has to already contain it

The usual reading of "build an MVP" is permission to throw something rough together and see if anyone bites. Alexander's seed metaphor says something quieter and harder. A minimum viable product is fine. A thoughtless one is not, because a rushed, hollow seed does not bloom into something good later. It blooms into a bigger version of the rushed, hollow thing. The DNA of quality is either in the first version or it never arrives.

The difference is not size. A small but complete expression of what you are actually going for beats a sprawling one that was assembled to test market fit and nothing else. The question to ask of any first version is not "does this work" but "is this a real, if tiny, instance of the thing I am trying to make."

When the theory turned up in the backyard

I ran into this in the least technical place possible, which is a backyard renovation. It started as "let us replace these bricks" and quietly turned into something else. The temptation to cut every corner was real. Landscapers are not cheap, I had a few days, and staring at a bare brick yard for months is its own slow punishment.

My landscape designer, also known as my wife, kept asking questions that sounded more like a philosophy seminar than a quote. "How do you want to feel when you step outside?" "What do you want to remember happening here?" I was impatient in the way you are when someone asks you to feel things and you just want to lay pavers. But the questions did the work the bricks could not. The result is a space that feels like it grew alongside us rather than getting dropped on top of us. That is the quality without a name showing up in a place I was actively trying to rush.

The tortoise, AI edition

The fable is more relevant to software than it has any right to be. The AI tools with staying power were not sprinted into existence. Claude, ChatGPT and Gemini all incubated through years of research before they became overnight sensations, which is the only kind of overnight sensation that exists. Attio spent years building before traction arrived, and is now the option teams reach for when legacy CRMs feel too blunt. Lovable spent six months in development before hitting $10M ARR in just 60 days, and people only ever quote the 60 days.

These are tortoise stories wearing hare costumes. The teams that hold both things at once, deliver now and build the foundation properly, are the ones still standing later. As my favourite television father Phil Dunphy put it, slow is smooth and smooth is fast.

Building with versus building for

Alexander believed the quality emerges when the people making a thing are also the people it is for. They are connected to the problem because the problem is theirs. A lot of building now is the inverse. Teams making tools they will never open, for a problem they have never personally had, which is a bit like designing the perfect hiking boot having only ever seen a trail in a stock photo.

I fall into this constantly. The pressure to deliver pulls me away from the reason I started, and the work goes flat without anyone deciding to make it flat. When I get back in contact with a real problem and real people, the work comes back to life. It is not subtle. You can feel the difference in the first ten minutes.

The contradiction at the centre

The genuinely useful and slightly maddening thing in Alexander's work is that taking time often saves time. The overnight successes incubated for years. The systems that survive are the ones designed to keep changing, not the ones that looked finished at launch. A coherent product with five features that hang together usually beats a fragmented one with fifty that do not.

I know the objection, because I have said it myself. The investors want results now. The competitors ship weekly while you are still defining the problem. That pressure is real and I am not going to pretend it away. But "taking time" was never an instruction to be slow everywhere. It is an instruction to spend the right time on the right thing. One extra day genuinely understanding the problem before you write a line. One week with actual users instead of imagined ones.

AI does not remove this choice. It sharpens it, because it hands you back hours you used to spend on the mechanical parts. So the only decision that matters is what you do with those hours. You can use the speed to ship the hollow seed faster. Or you can spend a slice of it on the question your landscape designer would ask. How do you want this to feel for the person on the other side of it. Plant that into the first version. It is the one part nothing downstream can add for you.