Building in Public

Building in public is the deliberate practice of exposing the operational mechanics and product development lifecycle of Total Ventures, from initial concept to shipping today, as a core part of the process.

What it is

This approach is a commitment to transparency, not merely a marketing tactic. It involves sharing code snippets, architectural decisions, agent prompts, revenue numbers, user feedback, and even the moments where things break. It is about showing the work, the effort, and the learning, rather than just presenting a polished final product. This includes sharing the studio's financial approach, aligning with Cash Before Vanity where profit is prioritized over raw growth metrics. It's the output of my agentic engineering process, integrated into the workflow rather than being a separate task.

Why I do it this way

Operating in the open forces clarity in my thinking; if I cannot explain a concept simply in public, it indicates a gap in my own understanding. This process accelerates feedback, as early users and other builders often identify flaws or opportunities I might have overlooked. Transparency also builds trust, fostering a different kind of relationship with the audience, who see the effort, the challenges, and the learning involved. It naturally attracts the right users who resonate with the mission and potential collaborators who understand the operational model. My public posts frequently serve as living documentation for future iterations or agent training. As a solo operator, working in public is a practical way to externalize thinking and gain diverse perspectives without needing to hire a full team. It also helps me adhere to principles like Runway as Decision Frame by publicly tracking progress and financial health.

How it works in practice

In practice, this involves regular updates on LinkedIn and my personal site. These updates cover specific technical challenges, product launches, or operational insights. For instance, I might detail how I used Claude Code to refactor a Firebase function for `Pregnancy Power Hour` to shave off cold start times, or describe the agent orchestration for `Total Formula 1`. I share artifacts such as screenshots of Vercel deployments, anonymized Stripe dashboards, code diffs, or agent logs. Direct engagement through comments or DMs forms a critical feedback loop; I learned the hard way that isolated building often leads to solving problems no one actually has. I use tools like Resend for targeted email updates to a small list of builders, and my custom agent system, VERA, assists by drafting initial summaries of product updates or operational changes based on commit logs and agent activity. This automation frees me to focus on extracting deeper insights. I do not wait for perfection to share; I present the rough edges and the "this didn't work" moments. This aligns with Stop Short of Perfection, ensuring that the pursuit of an ideal state doesn't prevent shipping.

Where this breaks down

There are clear limits to this approach. Over-sharing can cross the line from transparency into revealing sensitive IP or operational vulnerabilities. I filter content to ensure it is constructive and appropriate for public consumption. The time commitment required to distill complex work into clear, public-facing updates can be significant, though my agent system helps by automating initial drafts. It is also easy to get caught up in vanity metrics or chasing engagement; the focus must remain on genuine learning and sharing, not performance. Finally, raw data or an incomplete picture can sometimes be misinterpreted. I mitigate this by providing sufficient context and remaining available for clarification.