Why I Build in Public Now

For years, I only showed finished work. Polished case studies. Clean code samples. The messy process stayed hidden.

That changed. Now I share work in progress. I debug on camera. I write about problems before I've solved them. The shift wasn't natural, but it was necessary.

Why Share Unfinished Work

Finished work is a lie by omission. It shows the destination without the journey. The code sample works, but you don't see the five approaches that didn't. The architecture is clean, but you don't see the refactoring sessions that got it there.

Sharing unfinished work is more honest. It shows the actual process — the false starts, the debugging sessions, the moments of confusion followed by clarity. That's what learning actually looks like.

It's also more useful. Someone struggling with a problem doesn't need to see a perfect solution. They need to see someone else struggle with the same problem and work through it. That's relatable. That's actionable.

Learning Faster by Explaining

There's a selfish reason too. Explaining things forces understanding.

When I write about a technical concept, I discover gaps in my knowledge. When I record a video walkthrough, I find assumptions I hadn't questioned. The act of explanation is a learning accelerator.

This isn't new insight — it's the Feynman technique, rubber duck debugging, teaching as learning. But building in public makes it systematic. Every project becomes an opportunity to deepen understanding through explanation.

Live Debugging vs Polished Tutorials

Polished tutorials have their place. Sometimes you need a clear, step-by-step guide to accomplish a specific task.

But live debugging sessions show something different. They show how an experienced developer actually thinks through problems. The heuristics for narrowing down issues. The tools for investigation. The instinct for where bugs hide. The recovery when assumptions prove wrong.

I've learned more from watching someone debug a tricky issue for 20 minutes than from dozens of tutorials. The tutorials show the what. The debugging shows the how.

Mistakes as Teaching Material

The best content I've created came from mistakes. A deployment that failed in a surprising way. An architecture decision that seemed smart until it wasn't. A security issue that almost shipped.

Mistakes are valuable because they're specific. Abstract best practices are hard to remember. "That time I accidentally exposed database credentials in a client-side bundle" is unforgettable.

Sharing mistakes requires getting over the instinct to hide failures. But the value is clear. Other developers learn what to watch out for. And documenting the mistake forces real analysis of what went wrong and how to prevent it.

How YouTube and Writing Reinforce Each Other

I've had a YouTube channel for years. Activity ebbed and flowed. Recently I came back to it with more intention.

Video and writing serve different purposes. Video is good for walkthroughs, live coding, and showing real interfaces. Writing is good for structured arguments, reference material, and searchable documentation.

They reinforce each other. A video walkthrough becomes the basis for a written guide. A blog post surfaces questions that become video topics. The content compounds.

The AI tools available now make this more feasible than ever. Transcription, summarisation, reformatting — the friction of repurposing content across formats has dropped dramatically. A single deep-dive can become multiple pieces of content without proportional effort.

Why Transparency Matters More Now

The internet is full of AI-generated content. Polished, plausible, and often shallow. It's getting harder to distinguish genuine expertise from sophisticated pattern matching.

Transparency is a differentiator. Showing the actual work, including the struggles and mistakes, demonstrates real experience in a way that generated content can't fake. The rough edges are proof of authenticity.

This matters for trust. When I share that something didn't work and explain why, readers know I'm not just presenting an idealised version. They're getting actual experience, not manufactured content.

The Invitation

If you're interested in PWA development, offline-first architecture, or the practical realities of building production applications — follow along. Subscribe to the channel. Read the posts. Watch the process, not just the results.

The work continues in public.