Almost 7,000 contributions – and the part of building a company no heatmap shows

GitHub contribution graph showing 7,000 contributions in the last year.

On August 1, 2025, I founded Commander & Architect.

Since then, I have made roughly 7,000 public contributions on GitHub.

That is the visible record of a year of building.

It does not show the mornings I asked whether I had made the right decision. The work I had to rebuild after an AI told me it was finished. Or the weeks when the decision to continue remained mine alone.

People often talk about starting a company as an act of courage. The leap. The conviction. The big vision.

They talk less about the quieter part.

The mornings when you sit down and ask whether the thing you are building is becoming as real as the vision behind it.

The evenings when you have made twenty decisions nobody else will review.

The strange weight of putting years of experience into a product without knowing whether the market will ever catch it.

That has been my first year.

Not a clean founder story. Not a straight line from idea to product. More like a long conversation with myself about what I actually believe strongly enough to keep building when there is no external certainty.

The vision was there. The way was not.

I did not start Commander & Architect because I wanted to build a better website-feedback tool.

The vision was larger from the beginning: close the gap between strategic insight and execution.

I had spent years watching companies create enormous amounts of marketing and sales material while becoming less clear about the one question that mattered: why should this customer choose this offering now?

The website says one thing. Sales says another. A case study tells a third story. None of those statements need to be false. But if nobody can explain how they belong together, the buyer has to perform the strategic synthesis alone.

That was the problem I wanted to solve.

What I did not know was how much architecture that would require.

So I started where I could: n8n workflows. Then a website. Then the first systems that made the idea visible enough to test against reality.

From the outside, that probably looked like progress.

From the inside, it was also a search.

The moment trust became a design problem

After a break in China, I came back in November and began building the platform seriously. I moved from n8n into Claude Code. For a while, it felt like I had found the missing speed.

Then I checked work that had been reported as finished.

Part of it was not there.

That sounds like a normal technical problem until you are building from your own runway. Until your launch depends on the work. Until every week has a cost and every confident “done” becomes something you have to verify yourself.

The difficult part was not that an AI tool made mistakes. Every collaborator makes mistakes.

The difficult part was recognizing that I had given a system the emotional role of a trusted colleague without giving it the role design of one.

I had trusted fluency too much.

That was a sobering lesson. It was also useful.

I did not abandon AI. I changed the way I work with it.

I moved to Codex. I started building custom skills, small programs, review loops, and a more deliberate agent setup. I adapted review loops that made claims verifiable.

Not because I enjoy building process for its own sake.

Because I had learned that before you can build a complex system, you may first need to build the system that keeps the building honest.

The architecture before the architecture

That became the most important lesson of this year.

The product needs an architecture. It has to distinguish evidence from inference, reconstruction from diagnosis, and a plausible opportunity from a proven market fact.

But the work of building that product needs an architecture too.

The skills. The research habits. The review gates. The small tools that preserve a decision when the chat has moved on. The rules that stop a polished answer from becoming a false claim.

This is the architecture before the architecture.

It is invisible in a launch announcement. It is not particularly glamorous. And it is why the journey has sometimes felt so solitary.

You are not only trying to make a product work. You are learning which version of yourself can carry the responsibility of building it.

More patient than you expected.

More skeptical of easy answers.

More willing to tear down a convincing path when it is not true enough.

GTM-Audit technical preview for a Starlink audit report.
A test of our platform for Starlink.

What Commander & Architect is actually building

That personal lesson is now inseparable from the product direction.

GTM Audit offer reading for Starlink.

Commander & Architect is being built from the outside in. It starts with the public information a prospective buyer can see and reconstructs what an offering visibly communicates before interpretation begins.

That sounds abstract until you name the real problem.

Inside a company, people already know too much. They know the product history, the exceptions, the proof buried in a sales deck, the technical condition that only appears in a later conversation. They can fill in the missing steps because they live with them every day.

The people they need to convince cannot.

A first visitor sees only a fragment. A technical evaluator looks for a different kind of proof than a budget owner. A decision-maker may understand the promised result and still not see why it is credible, what it requires, or how it changes the risk of the decision.

That gap is where the expensive blind spots live. Not because a company is dishonest. Because it is almost impossible to see your own offering with the fresh eyes of someone who does not already know the answer.

This is the distinction that now matters most to me: a piece of proof can exist and still be practically invisible. A condition can be technically documented and still arrive too late. A benefit can be true and still speak to the wrong decision.

The question is not simply, “What do we communicate?”

It is, “What can a person with responsibility for budget, risk, or implementation realistically find, understand, and trust before making this decision?”

The work distinguishes who a company intends to address from who its public communication actually appears to address. It makes visible what a realistic first-time visitor can find, understand, or miss – and which questions remain open.

From there, the company can decide what to examine next, with the sources and assumptions kept visible.

There is an important boundary here.

We do not claim to know who actually buys, evaluates, or responds. That requires internal behavioral data. From the outside, that is not provable. Pretending otherwise would be exactly the kind of confident fiction I am trying to remove from strategic work.

At its core is a shared, source-bound decision model: a reference point that shows what the offering communicates, what supports each claim, where sources conflict, and what remains uncertain.

Only then can options and next steps be discussed honestly.

A different kind of progress

I used to think the best proof after a first year would be a finished product and a neat story about how it all came together.

Instead, I have something more valuable: a clearer idea of what I refuse to fake.

I do not want to build another machine that produces confident marketing faster. I want to build a system that helps people see what their offer really says, what evidence supports it, what remains uncertain, and which decision is worth making next.

The other side of the doubt

Building independently changes the weight of ordinary setbacks. A difficult week can make the path feel less clear. A technical failure means revisiting a plan sooner than you expected. When you are carrying the risk yourself, it is easy to let one hard moment colour the whole picture.

But the year did not only bring setbacks.

It also brought conversations with people who understand complex B2B businesses and immediately saw a practical use for the early product. One conversation opened a concrete path for a beta pilot with an accelerator and its startups. Another came from someone who saw relevance not only for his own company, but for the companies he serves.

That does not make this market validation. It is not revenue, and it does not remove the work ahead.

But it is real signal.

So is the support around the build. NVIDIA Inception, AWS Activate, Microsoft for Startups, and Perplexity for Startups have given Commander & Architect infrastructure, credits, and a degree of backing that would have been hard to imagine when I opened the first n8n workflow. Another major platform has also begun a conversation about supporting the journey.

I do not treat those things as permission to become complacent. I treat them as reminders that the work is visible beyond my own desk.

That is the rhythm of a first year: questions and encouragement, recalibration and forward motion, long stretches of focused work and the conversations that give the next week a different meaning.

The aim is not to eliminate the uncertainty.

It is to keep earning the right to continue.

The next step is a small closed beta. It is not a claim that the entire vision is finished. It is a controlled way to put the first version of this platform in the hands of people willing to test it on their own offering – and to learn whether it gives them a useful starting point for an honest discussion of that offering.

If that sounds relevant to your company, you can learn more and apply for the beta at gtm-audit.com/beta-access.

If you have followed this journey, thank you.

Building a company can make you feel alone in ways I did not fully understand before I started. But it also gives you an unusual chance to meet yourself without the old roles, the old approval systems, and the old excuses.

One year in, I am still asking hard questions.

I am just no longer asking them alone inside my own head.

I have built enough of the architecture to let the work answer back.

If you want the personal story, this post is it.

If you want to go deeper into the method – how we reconstruct what an offering communicates, keep sources and uncertainty visible, and leave the decision with the human – read Understanding Before Decision: Understanding Before Decision (English PDF).

A German edition is also available: Understanding Before Decision (Deutsche Fassung).

Your Team Has AI Tools.

Your Team Has AI Tools.

How Revenue Teams Use Decision-ready GTM architecture and implementation assets To Shorten Complex AI Deals is evergreen enough to protect weekly…
Read more