A Sunday Thought: The Builder vs. The Solver
On the quiet legacy of making problems disappear.
Hey everyone,
A quick thought for your Sunday.
While we were deep in the weeds writing this week's articles on frameworks and protocols, a simpler, more fundamental idea kept surfacing. We found ourselves circling back to the core conflict that drives so much of the work we do.
It’s not a formal protocol. It's a reflection on the two identities at the heart of creation.
It felt too important to bury inside another post, so we wanted to share it with you here, raw and unedited.
Hope it resonates.
- Hannes & Alex
There's a subtle but powerful trap in the heart of modern tech culture: the glorification of the "builder."
We idolize the builder. They create tangible things—products, features, companies. They leave behind statues. The act of building provides an immediate, controllable feedback loop of progress: the code commits, the demo goes live, the social media post gets likes. It feels good. It feels like winning.
The "solver," in contrast, is less glamorous. A solver’s success is often invisible—it's the absence of a problem. It's the support ticket that was never written, the user frustration that never occurred, the crisis that was averted through careful thought. The feedback loop is slow, uncertain, and depends entirely on an external variable you can't control: the user.
This creates a dangerous incentive.
When the psychological and social rewards are tied to the identity of being a builder, we risk prioritizing the performance of that role over the actual work. We engage in frantic, aimless motion—building and pivoting, shipping and iterating—because the motion itself is the reward. The user's problem becomes a mere prop in our personal journey of creation.
This leads to a cascade of indifference. The founder, chasing the builder identity, doesn't truly connect with the user's pain. The product, born of this indifference, fails to solve the problem. And the users, feeling this disconnect, are ultimately indifferent to the product.
The most critical shift for any founder is not from one idea to another, but from one identity to another. It's the conscious decision to stop playing the role of the "builder" and to start doing the rigorous, often invisible, work of the "solver."
It's the moment you realize that your legacy won't be the statue you built, but the problems you made disappear.
End 'Feature Factory' Hell With These 3 Questions
TL;DR The Problem: The endless "build trap" stems from a hidden conflict between the "Builder" (who craves tangible output) and the "Solver" (who needs to create real user impact). This imbalance leads to wasted effort.