Building Pophood

For a long time, building products meant building teams.

Backend engineers. Frontend engineers. Designers. DevOps. Product managers. QA. Each role existed because the work demanded that level of specialization. For large-scale companies, that’s still true.

But that model no longer defines what’s possible. Pophood is a good example of that.

So I’m going to share how it came together over a few posts.

I built this entire thing myself. The engineering and architecture, the product decisions, and the brand. Not because I see myself as a 100x engineer, but because I wanted to see how far I could push something end to end.

Some of it is technical. How I structured code in a way I can actually maintain. Why certain architectural patterns made sense here and others didn’t. Where AI coding assistants saved me hours, and where they wasted entire afternoons. And no, I didn’t vibe code the whole thing with a single prompt.

Some of it is product work. How I scoped features without a team or a budget. What user research looks like when it’s mostly conversations and pattern recognition. The ideas I killed before they shipped, and why killing them mattered.

Some of it is design. Building a brand system without a designer meant slowing down and being intentional. Typography, color, component architecture. Making deliberate choices instead of just picking what looked nice.

And then there’s the part people don’t really talk about.

The tradeoffs that don’t have clean answers. The back and forth on decisions you can’t delegate. The second guessing that creeps in when you’re alone with the work, wondering if your instincts are right and if the thing you’re building is actually any good.

Pophood isn’t just a set of features. It’s a long chain of decisions, some solid, some questionable, and some I’ll probably rethink later. Writing this out is my way of unpacking that process while I’m still close to it.

I’ll go deeper in the posts that follow.