Leadership
The order is a dependency, not a plan
Three of the companies I have been part of solve one problem at three layers. The stack has an order. The building did not follow it, and the gap between the two is the useful part.
Published
The pattern
Build something. Discover that its value is limited by a constraint above or below it. Build that. That is the dependency order.
Why the stack is described bottom-up
Delivery depends on having something to deliver, and analytics depend on a portfolio to inform. That is a dependency between layers, not a sequence of construction: the platform opened in 2020, the first THOR fund followed in 2022, and the risk engine in 2026.
Nobody planned that. Each layer was the next thing in the way.
What this is not
It is not a master plan executed over twenty years. Told afterwards it sounds like one, and that is a distortion worth resisting.
The argument came first. The coherence of three layers was recognized afterward, one constraint at a time.
The risk of the pattern
It can become a justification for building anything adjacent. Every business has constraints in every direction, and “we discovered a problem upstream” can rationalize almost any expansion.
The discipline is asking whether the constraint is binding, or just visible.
Where I broke it
Civly is not part of the stack. Different customer, different domain, no shared infrastructure. It exists because the problem was worth solving, which is a sufficient reason and a different one.
The transferable part
When something is not working as well as it should, look at what is immediately above and below it before improving the thing itself.
The constraint is usually not where the symptom is.