There is a kind of recursion that happens when you build a platform for AI-assisted work. The only honest test of whether it does what you think it does is to use it to build the thing. So before we wrote our first line of gvmesh, we decided: we build this with this.
That was not a lucky accident we noticed later. It was the plan from the start. If the platform could not hold up under the weight of building itself, then we were building the wrong thing.
The hypothesis
Before we started, I had a specific belief about what this platform should make possible.
A small team with the right infrastructure should be able to build what used to take twenty people. Not by working harder. By working in a system where decisions are attached to the work they came from, where context does not vanish when you switch tasks, and where the AI is collaborating on the problem rather than just answering questions.
That was the hypothesis. Using greatVibe to build greatVibe was the test.
David was running the same test on the business side. He used it to build the brand, the GTM, the financial model, the website, the legal structure. While he was doing that, I was building the platform he was running on. The recursion ran two levels deep.
What we built and how
The core of greatVibe is a daemon called gvmesh. It holds all the state: credentials, sessions, the history of every AI turn, file transfers, the mesh topology. Thirty-five subsystems, all in one binary. Alongside it runs konui, the web dashboard, and gvmcp, which exposes all of this as tools Claude can use.
I built all three in greatVibe sessions with Claude. Not just the implementation. The architecture decisions, made in the same sessions that started implementing them.
When I was working out how to distribute credentials across mesh nodes, I came to a session with the problem and we worked through it. Push vs pull. Central store vs gossip. We landed on gossip: credentials move through the network like rumours. Each node hears them from a peer, verifies them, passes them on. Encrypted. Eventually consistent. No single point of failure.
The session that designed it was the session that started building it.
The bridge relay came the same way. I needed mesh nodes on different networks to talk to each other without open ports or VPN tunnels. We worked it out: extend the WebSocket connection that was already open between each node and the bridge. No new ports. No new services. Reuse what was already there. Twenty minutes.
Neither of those outcomes came from me sitting alone with a whiteboard. They came from the session.
Context is first class
The context holding was not an accident. I had that problem specifically in mind when I was designing the system.
I had spent enough time building software to know what losing context costs. You switch tasks, you come back, and you spend ten minutes re-establishing where you were before you can do anything useful. If you are doing that ten times a day, across a project with thirty-five moving parts, you lose whole days to overhead.
I built greatVibe to make that impossible. Context is a first-class primitive in the system. Every session, every decision, every piece of work leaves a trace. The next session picks up from where the last one left off. That is not a coincidence. That is the architecture.
What that gave me in practice was the ability to move between very different problems without losing ground. I would work on the credential layer, switch to a bug in the bridge relay, come back to the credential layer, and the shape of the problem was still there. Not just the files. The open questions, the decisions already made, the thing I was still figuring out.
David felt the same thing on the business side. The system held the thread across pricing strategy, legal documents, website copy, and the financial model, all at once. That is not luck. That is what context-first looks like in practice.
The proof
We built thirty-five subsystems and three hundred tools. And a business. Two people.
That was not faster than I expected. It was what the hypothesis predicted. Build the right infrastructure, keep the context coherent, and a small team can do work that used to require a large one.
The recursion closes cleanly here too. The platform we used to build the platform is the same platform we are asking builders to use. We are not selling something we have not lived in. We lived in it while building it.
What I want builders to take from this
The thing that changes is not the speed. Speed is a side effect.
The thing that changes is the coherence. The fact that you do not have to explain the project again tomorrow. The fact that the decision you made last week is still attached to the work it came from. The fact that switching between problems does not mean starting over.
That is what makes a small team capable of something large. Not AI that works faster. Context that stays whole.