Why I'm Building in Public

2 min read

The pitch, minus the pitch

I quit pretending there's a perfect moment to start. Instead, I'm building products — real ones, not side-project graveyards — and writing about every step publicly.

The plan is simple: ship a new SaaS product roughly every 4–6 weeks, learn fast, kill what doesn't work, and keep going. I'm calling it a product factory, mostly because "serial micro-SaaS builder" sounds terrible.

Why build anything in public?

Three reasons, no fluff:

  • Accountability. Saying "I'll ship this in two weeks" on a blog post hits different than whispering it to your terminal at 2 AM. Public deadlines are real deadlines.
  • Compounding audience. Every post is a tiny SEO beacon. Over months, they add up. I don't have a Twitter following or a newsletter list — I have git log and a blog.
  • Faster feedback loops. Showing work-in-progress lets people point out blind spots I'd otherwise discover three weeks too late.

I'd rather share a rough idea today and find out it's flawed than polish it for six months and still find out it's flawed.

What this is not

This isn't a "hustle culture" play. I'm not going to post daily revenue screenshots or manufacture urgency. Early on, there won't even be revenue worth mentioning. What I will share:

  • Technical deep-dives — the actual code, architecture decisions, and tradeoffs behind each product
  • Product thinking — how I pick ideas, validate them (or don't), and decide what to build
  • Honest retrospectives — what worked, what flopped, and why

If something fails, I'll write about that too. Probably more interesting than the successes, honestly.

The factory model

The idea is borrowed from makers like Marc Lou, but adapted. His model works because he has an audience — hundreds of thousands of Twitter followers who'll try anything he ships. I have approximately zero of those.

So my version leans on SEO and content instead of social distribution:

  • Every product targets a specific, searchable problem
  • This blog creates topical authority around the things I build
  • Products cross-link here, and here links back to products

The economics are simple: near-zero cost, fast iteration, kill at 60 days if there's no traction. Everything runs on a Mac Mini in my apartment. No cloud bills, no VC, no pressure to 10x.

The stack, briefly

Every product shares a common foundation — Next.js, Tailwind CSS, self-hosted on that Mac Mini via Cloudflare Tunnel. Same stack means I'm not wasting time learning new frameworks every month. I'd rather spend that time on the actual product.

This blog itself is built with MDX (via Velite), which means I can drop React components into posts when I need to show something interactive. Haven't needed that yet, but it's there.

What's already shipped

The first product is ConvertStatement — a tool that parses bank statement PDFs into clean, structured data. It's live, it works, and I'll write a proper case study about the build process next.

What to expect from this blog

Roughly one post per week, covering whatever I'm actively building. Some weeks that's a new product launch. Other weeks it's a TypeError that cost me four hours and a deep look at why PDF parsing is a nightmare.

If you're an indie hacker, a developer building side projects, or just someone who likes reading about people making things — stick around. Subscribe if that's your thing. Or just check back whenever you remember this URL exists.

Either way, the code is getting written and the products are getting shipped. Might as well write about it.