What I've learned about building a consulting practice from products instead of credentials

The conventional path to a consulting practice is credentials and client work.

The CV builds, the network develops, the case studies accumulate, and the practice grows from the market’s recognition of what you have already done.

I understand that path. I am just not building only through it.

For me, the products come first. The consulting practice is not separate from them, nor are they side projects sitting next to the real work. Protocol, Gestalt, and the other things I keep building are part of the method.

They force me to stay close to the work I claim to understand.

Building a product is more similar to consulting than people realise. In both cases, you are trying to pull intent out of ambiguity, turn it into structure, and create something that can survive contact with actual use.

The difference is distance.

With a client, that distance is a gift. You are outside someone else’s dream, which means you can see the shape of it more clearly than they can while they are inside it. You can challenge the assumption, name the contradiction, and separate the symptom from the cause without carrying the same attachment.

With your own product, there is no clean distance. You are the founder, the product lead, the user, the critic, the backlog, the strategy meeting, and sometimes the person rubber-ducking the same decision to yourself for the tenth time while everyone around you regrets asking how the app is going.

That is funny until it is expensive.

The hard part of solo building is the context load as much as the workload. Humans have context tokens too, and mine are not infinite. I can only hold so much product logic, design detail, market uncertainty, technical debt, and personal conviction in my head before the system starts to degrade.

That has changed how I think about client work.

When a team tells me they need more clarity, more velocity, or better execution, I hear it through the experience of building alone. I know what it feels like when a product has too many live branches in your head. I know how easy it is to mistake motion for progress because every task feels valid. I know how scope creep arrives disguised as a better idea, a useful addition, or “just one small thing.”

The uncomfortable lesson is that discipline behaves less like a personality trait and more like an operating constraint.

You have to choose what gets your attention. You have to kill ideas before they derail the product that actually matters. You have to get outside your own head, even when you are building something that began as a problem you personally needed solved.

Protocol is a good example. It solves a real problem for me, which is what makes it worth building. That does not mean I am the whole market. If Protocol reaches critical mass, I cannot keep shaping it only around my own habits, preferences, and training logic. I might be a user, but I am not the user base.

That humility matters in consulting too.

A founder often knows the product better than anyone else in the room, while also being too close to see what the system has started doing around them. That is where the product work has made me sharper. It reminds me that the problem people describe is often not the problem they have; it is the part of the system they can still see from where they are standing.

The product argument for consulting is different from the credential argument.

Credentials say: here is where I have worked, who has trusted me, and what roles I have held.

Products say: here is how I think when nobody gave me a brief, here is what I build when I am accountable to the work itself, and here is the standard I hold when there is no client meeting forcing the next decision.

That matters commercially because it changes the conversation. Product work lets me enter discussions as a peer first, not as an opportunistic consultant trying to manufacture urgency. When someone can see how I think through Protocol, Gestalt, or the systems behind this site, the conversation starts in a different place.

That does not replace trust, but it opens a door to a better kind of trust.

I do not know if this is the faster path, and it probably is not. Building products while building a consulting practice is slower, stranger, and more personally revealing than polishing a credentials page.

It is also more honest for the kind of work I want to do.

If I am going to help teams turn intent into shipped systems, I need to keep building systems of my own; if I am going to challenge founders on scope, clarity, decision quality, and operating discipline, I need to keep meeting those same problems without the protection of distance.

The line I keep coming back to is simple: keep a compass.

The compass is not a roadmap; it will not tell you every step or save you from bad calls, but it keeps you honest about direction when the work gets noisy.

That may be the closest thing to advice I trust from inside this path.