Why I'm Rebuilding My "Build in Public" Site (And What Most Founders Get Wrong About Content)

TL;DR

I just finished testing my personal site and realized something uncomfortable: my "Journey" section was failing the very people I want to serve. A chronological blog feed sounds authentic, but it's actually lazy architecture. Today I designed a complete content reorganization that treats my site like a product, not a diary. Here's what I learned and why it might change how you think about your own build-in-public content.

The Problem Nobody Talks About

I've been building in public for months. Sharing wins. Documenting failures. Writing about the messy middle.

And today, while reviewing my site against my actual mission documents, I realized I'd made a classic mistake:

I was writing for myself, not for the people I want to help.

My "Journey" section? It's a reverse-chronological feed of posts. Very blog. Very 2010. Very... useless for anyone trying to actually learn from my experience.

Think about it: If you landed on my site wanting to understand how I built Trader-7, or what went wrong with my first SaaS attempt, you'd have to scroll through dozens of unrelated posts hoping to find the relevant ones.

That's not a resource. That's a scavenger hunt.

The Three People Who Visit (And What They Actually Need)

When I looked at my Client Success Blueprint, I'd already defined three distinct personas:

1. Corporate Escapists

They want proof that solo building works
They need case studies, data, systematic approaches
They're asking: "Show me someone who actually did this"

2. Service Providers

They want quick wins and templates
They need actionable, bite-sized content
They're asking: "Give me something I can use today"

3. Ambitious Builders

They want technical deep-dives
They need metrics, architecture decisions, code patterns
They're asking: "How exactly did you build that?"

A single chronological feed serves none of them well. It's the content equivalent of a junk drawer.

The Architecture That Actually Serves Them

Here's what I'm building instead:

Keep the Journey (But Know Its Purpose)

The chronological feed stays. It's the "follow along in real-time" experience. Great for subscribers. Great for RSS readers. Great for the 40% of my content that's pure journey documentation.

But it's no longer the only entry point.

Add a Projects Hub

New /projects page where each project becomes its own mini-case-study:

Status badges: "In Development", "Launched", "Pivoted", "Failed"
Key metrics: MRR, users, days invested
Tech stack: What I actually used
Timeline: Visual progression through phases
All related posts: Filtered and organized by project

This gives Corporate Escapists the proof they need. "Here's Trader-7. Here's every post about it. Here's what worked and what didn't."

Make Failures First-Class Content

Here's where it gets interesting.

My brand essence is "Proof over promises." My differentiator is radical transparency. But where on my site can someone actually find my failures?

Buried in random posts. Maybe. If they scroll enough.

The new project pages will have a prominent "Lessons Learned" section above the fold. Two parts:

What Didn't Work

Issue encountered
Root cause analysis
How to prevent it

What Worked Unexpectedly

The win
Why it worked
Is it replicable?

This is content no one else is creating. Everyone shares their wins. Almost no one systematically documents their failures with actual analysis.

The Post Categorization System

Every post will now have metadata that makes it findable:

Content Pillar (aligns with my documented content strategy):

Journey (40%) - Real-time updates, daily progress
Framework (30%) - Tutorials, guides, systematic approaches
Tool (20%) - How-to content, demonstrations
Community (10%) - Case studies, success stories

Post Type:

Progress Update
Milestone
Failure
Tutorial
Case Study

Target Persona:

Corporate Escapist
Service Provider
Builder
All

This isn't over-engineering. It's treating content like a product. When someone visits, they should be able to self-select into the content that serves them.

What This Looks Like In Practice

Before:

"Check out my Journey page" User scrolls past 47 posts looking for something relevant User leaves

After:

Corporate Escapist lands on site → Sees "Projects" in nav → Clicks into Trader-7 project → Sees timeline: Ideation → MVP → Launch → Current → Reads "Lessons Learned" section → Clicks related posts filtered by this project → Actually learns something useful → Bookmarks site, subscribes

The Uncomfortable Truth About "Build in Public"

Here's what I realized today: most build-in-public content is performative, not useful.

We post screenshots of revenue. We share Twitter threads about our "journey." We write blog posts that are really just long-form humble brags.

But useful build-in-public content is structured. It's findable. It's organized around the problems your audience is trying to solve, not the story you want to tell.

Your site isn't a diary. It's a product. And like any product, it needs to solve a real problem for a specific user.

My "Journey" section was solving my problem (documenting what I did). The new architecture solves their problem (learning how to do it themselves).

The 30-Hour Sprint (According to Claude Code)

Claude scoped this out at 19-30 hours across 6 phases:

Database schema - Add categorization fields
Projects pages - Build the hub and individual project pages
Admin UI - Make categorization easy when creating posts
Content remediation - Bring all existing content up to standard
Navigation - Integrate across the site
Testing - Make sure it all works

It's not trivial. But it's the difference between a personal blog and a genuine resource for people trying to build solo. lets see how long it really takes!

The Meta-Lesson

Today I passed 12/12 tests on my site. Everything works. It's ready for production.

But "working" isn't the same as "serving."

The code can be perfect and the content architecture can still be wrong.

If you're building in public, ask yourself: Is your content organized for you or for them? Is your site a diary or a resource? Are your failures hidden in random posts or prominently documented where people can learn from them?

The build-in-public movement has a content problem. We're all posting, but few of us are architecting.

Time to fix that.

What's Next

I'm at a crossroads:

Option A: Deploy what's working and start the content reorganization sprint
Option B: Deploy now, iterate later

I'm leaning toward A. The site works, but "works" isn't the goal. Serves is the goal.

Follow along at jamiewatters.work/journey - and soon, at /projects where you'll actually be able to find what you're looking for.

Building the billion-dollar solo playbook, one architectural decision at a time.

#buildinpublic #solofounder #contentarchitecture

My Build In Public Site - Rebuilding (And What Most Founders Get Wrong About Content)