The Pragmatic Builder

An Introduction

I used to be a software developer. Past tense. I got out because, honestly, I wasn’t great at it and I didn’t particularly enjoy it. But here’s the thing about being a mediocre developer who becomes a product manager: you never quite stop seeing problems as things you could build, if only you had the time, the skills, or the energy to actually finish something.

For years, I’d start projects. A tool to solve this workflow problem. A dashboard to track that metric. Each time, I’d get a few hours in, hit some obstacle I didn’t know how to solve, and quietly abandon it. The problems remained problems. I remained someone who had ideas but couldn’t execute them.

Then, about 18 months ago, two things happened almost simultaneously.

First, the noise around “vibe-coding” got too loud to ignore. Developers were casually mentioning they’d built entire features over a weekend using Claude or Cursor. Non-technical founders were shipping products. The discourse was getting spicy, and I was curious.

Second, I realised that Lenny’s Newsletter package came with access to a bunch of these AI coding tools - for a fraction of what they’d cost individually. So I signed up, more out of curiosity than conviction.

And then I just... started building.

I tried them all. Lovable, Cursor, v0, Bolt, Replit. I poked at their edges. I learned what each one was great at and where they’d faceplant. I built small tools for myself—things that actually worked, that actually solved my problems. A tracking system here. An automation there. Nothing fancy, but functional.

But the real revelation came when I connected this to my day job as a product manager.

Before, my workflow looked like this: Have a hypothesis. Document it carefully. Write requirements. Hand it to a designer. Wait. Hand it to a developer. Wait some more. Get something back two weeks later if I was lucky. Test it. Learn something. Repeat.

Now? I could have an idea in the morning, build a working prototype by the afternoon, and put it in front of users the next day. It wasn’t pretty. It wasn’t robust. But it was enough to know if the idea had legs.

That changed everything.

The more I built, the more refined my approach became. I started developing intuition about when to use which tool, what kinds of experiences worked better with certain approaches, where to cut corners and where to be careful. I wasn’t becoming a great developer - I was becoming an effective builder.

And here’s what I realized: this isn’t just about me getting slightly more technical. This is about a fundamental shift in how product work can happen.

What This Newsletter Is About

I’m calling this The Pragmatic Builder because I’m interested in one thing above all else: actually shipping stuff that works.

Not perfect architecture. Not gold-plated code. Not following best practices for their own sake. Just building things that solve real problems, learning from them quickly, and iterating based on what you learn.

Over the coming months, I’ll be sharing:

Vibe-Coding Chronicles – Real build stories with actual decisions, trade-offs, and occasional disasters. How I built things, why I made certain choices, what worked and what didn’t. The PMS system I’m currently building will be a recurring case study.

AI-Assisted Workflows – Practical techniques for working with Claude, Cursor, and other tools. Not hype, not theory - just what actually works when you’re trying to build something real.

Pragmatic Product Development – How building changes product management. Prototyping approaches. Testing hypotheses faster. The new possible workflows when PMs can code (sort of).

Tool Selection & Technology Decisions – When to use which AI coding tool. How to evaluate technologies when you need to move fast. Building conviction without infinite research.

Solo Builder Lessons – Maintaining momentum. Scope management for the impatient. Balancing “good enough” with “actually useful.”

Some of this will be free. The deeper dives and more detailed tutorials will be for subscribers.

What This Isn’t

Let me be clear about what you won’t find here:

This isn’t computer science theory. I’m not teaching you algorithms or data structures.

This isn’t “how to become a professional software engineer” content. I’m not one, and I’m not trying to be.

This isn’t claiming that vibe-coding is production-ready or that you should ship AI-generated code to millions of users without review.

But here’s the thing about that last point: yes, the conventional wisdom says vibe-coding won’t get you to production. And I mostly agree - if you’re building software that needs to scale, needs to be maintained by a team, needs to handle edge cases gracefully.

But every single professional developer is using these exact same tools right now. They’re just using them better, with more context, with more ability to review and refine. The gap between “vibe-coder” and “professional using AI tools” is narrowing fast, and it’s more about judgment than pure technical skill.

For product managers, founders, designers, and anyone else who needs to validate ideas quickly? The bar for “good enough to learn from” is so much lower than “good enough to ship to production.” And that’s the space I’m playing in.

Why You Should Care

If you’re a product manager, this approach means you can test ideas before they hit your roadmap. You can prototype solutions to show stakeholders instead of writing documents. You can have informed technical conversations because you’ve actually tried building the thing.

If you’re a founder without a technical co-founder, this is how you get to your first real version without outsourcing to an agency or spending months learning to code properly.

If you’re a designer, this is how you can build interactive prototypes that feel real, not just clickable mockups.

If you’re a developer, this might annoy you or it might intrigue you - either way, your PMs and colleagues are going to start doing this, so you might as well understand how they’re thinking about it.

Join Me

I’m figuring this out as I go. I’m going to make mistakes, change my mind, and occasionally build something embarrassingly hacky. But I’m also going to ship things, learn from them, and get better.

If that sounds interesting, stick around.

Next week, I’m going to share something immediately useful: how to use AI tools to write genuinely helpful PRDs - the kind that give your team clarity without drowning them in documentation. It’s one of the first practical applications I found for this approach, and it’s made my product work noticeably better.

Let’s build some stuff.

---

Questions? Thoughts? Leave a comment - I read everything.