Solo Velocity vs Stakeholder Alignment: Building in Public, Shipping in Private

Building solo with AI = shipping fast. But nobody is there to tell you “that’s a dumb decision.” How do you compensate?

The tension is real

Solo builder + AI coding agents = absurd velocity. Amal Najib — a PWA for Muslim personal finance — I shipped in 2 weeks from empty to functional prototype. Stoka and House of Riddle ran the same way.

What gets lost: a sparring partner. No lead asking “why did you pick Sanity instead of Webflow?” No designer challenging the information architecture. No QA asking “have you handled the edge cases?” AI agents comply — they execute. But they are biased toward “help you finish” rather than “challenge your choice.”

So the problem is: how do you compensate for the missing team friction?

The answer that gets thrown around: post per sprint

“Write a blog every sprint. Tweet every commit. Build in public!”

It doesn’t work. Three reasons:

1. High overhead. If you ship fast, you don’t have time to write weekly essays worth reading. What gets produced is filler — “this week I refactored the auth flow!” — that helps no one.
2. Not scalable. Posting momentum collapses within 3 weeks. Almost every “build in public” journal dies around post 8.
3. Cheerleader bias. You’re writing while also selling your own progress. That’s not a sanity check — it’s marketing. Real stakeholder alignment needs friction, not applause.

The Stella Protocol answer: two layers

Layer 1: Internal logs (mandatory, low overhead)

This is what keeps the project alive. Stella Protocol is my AI-PM methodology — these three files live under brain/ in every project I run.

• brain/log-pose.md — current phase + next gate. One file that answers “where are you, where are you going?” Reads in under 30 seconds.
• brain/vivre-cards.md — decision log. Append-only. Every non-trivial decision goes in: picking Sanity over Webflow, deferring autosave to v2, shrinking the MVP scope. Fixed format: context, decision, rationale, alternatives. See Append-Only Decision Log for the full spec.
• brain/scope-changes.md — drift log. Every feature that enters or exits the approved PRD. Cipher Pol — the scope-drift monitoring skill — enforces this.

Overhead per entry: 2–5 minutes. Nothing more expensive than that, because the format is already fixed.

Layer 2: Selective public posts (optional)

Not per sprint. Not per milestone. Only when one of three conditions holds:

1. Framework shift. There’s a new way of working I changed structurally — worth writing.
2. Surprising lesson. I predicted A but reality was B. The insight’s value is in the gap between prediction and reality.
3. Clear story arc. There’s a beginning-middle-end that a reader with no project context can follow.

If it doesn’t hit one of the three, I don’t write. I save the energy for shipping.

Why internal logs are enough

Future-you is the most underrated stakeholder.

Six months from now, I won’t remember why Amal Najib chose Sanity vs Webflow. I won’t remember why the P0 scope was minimal, and why feature X got cut. Even if I do remember, I’ll second-guess myself — “maybe it should have been Webflow?” — and waste time re-litigating an old decision.

The log trail is there. The argument resolves in 30 seconds: open vivre-cards.md, read the entry with the decision date, see the rationale and alternatives already considered, close the file, keep working.

That’s not documentation for investors. That’s documentation for yourself in six months, who is effectively a different person.

Why selective public, not per sprint

Two reasons.

Build-in-public fatigue. Audience burnout happens when you post every commit. Engagement drops, signal drops, and you train the audience to skip your content. Rare but substantial posts give every post weight.

Author burnout. Writing is expensive if you take it seriously. If I force myself to write every sprint, one of two things happens: (a) I write carelessly, or (b) my shipping velocity drops. Both are bad trades.

So: write when there’s something worth writing. Otherwise, it goes to the internal log.

The trade-off I accept

Shipping in private = no pre-launch hype cycle. No “I’m building X!” tweet every week building anticipation. When it ships, the launch is cold — it has to rely on product merit alone, not audience momentum.

I accept that. The alternative — stealing shipping time to write for hype — degrades the quality of what I launch, which is counterproductive.

The compensation: the log trail means that if a co-builder joins at any point, or I hand off a project, their onboarding doesn’t start from zero. Concretely: if I hand Amal Najib off to a halal counselor as content lead tomorrow, they can read brain/log-pose.md and brain/vivre-cards.md in 20 minutes and understand why the CMS is Sanity, why the P0 scope is what it is, what’s deferred to v2, and the reason behind each of those choices.

That’s worth far more than last week’s blog post with 40 views.

Lesson

Documentation for future-you is the most underrated stakeholder work. If you only keep one ritual, make it the append-only decision log — not the blog per sprint.

Key Takeaways

1. The real cost of solo-building isn’t velocity, it’s the missing challenger. AI agents execute; they don’t push back. Replace the missing friction with structure (logs), not with ceremony (weekly posts you can’t sustain).
2. Future-you is the stakeholder you actually have to brief. Six months later you won’t remember the rationale, and without it you’ll re-open settled decisions. A 2-minute Vivre Card entry saves a 2-hour re-litigation.
3. Public posts earn their spot — framework shift, surprising lesson, or clear story arc. Nothing else. Everything else goes to the internal log, and shipping velocity stays intact.

Satellite: Morgans (this post) · Pipeline: REFLECT — Morgans