I've Spent My Career on Other People's Projects. Here's What Happened When I Started Building My Own.

• Building is accessible now, and the entry point isn't technical skill. It's the scoping, structuring, and problem-definition skills you already use.
• I tested whether a PM and brand strategist could build a custom tool with Claude Code. The claim held up.
• The real shift: "I could build this" is now a real option when I identify a problem. That changes how I think about every tool I use.

I've spent my career identifying problems and building processes to solve them. Scoping projects, structuring strategy, managing the distance between a messy brief and a clear deliverable. That's the work. The tools evolve. So does the thinking.

For the past year and a half, I've tried countless AI tools: transcription and meeting tools, Claude and ChatGPT and Gemini on the model front, Make and Zapier to connect data and build automations, Replit and Lovable to build proof of concepts. I'm drawn to anything that might sharpen how I think through problems, and the temptation is always to chase features instead of focusing on the problems that undergird them.

The pattern was always the same: features that came so close to what I needed, yet never quite right. Tools that didn't connect. Manual steps bridging the gaps. Friction everywhere.

And chat interfaces only go so far. You type a question, get an answer, iterate a few times, but you can't reshape how the technology works. You have no agency in how it's deployed.

Then I tried Claude Code. Not because I wanted to learn to code, but because I wanted to test whether the gap between seeing a problem and building a solution was actually as small as people were claiming.

It was. A capable assistant in the terminal that could write code, explain decisions, debug with me, and help me learn as I built. The shift wasn't learning a new tool. It was realizing that the skills I already use, scoping, structuring, defining what "done" looks like, were exactly the skills this kind of building requires.

For the first time, the bottleneck wasn't technical ability. It was clarity of thinking. And clarity of thinking is what I've spent my career trying to get better at.

I have years of data from my practice that's completely under-leveraged: client transcripts, strategy sessions, meeting notes, research, braindumps. Years of thinking sitting in folders, disconnected and underutilized.

I kept asking myself: what would it look like to build something that helps me actually use all this? Not a universal solution, but something specific to how I work. A personal knowledge system that tracks how my thinking evolves.

So I built it.

I asked Claude how to scope a proof of concept, and it suggested two weeks. I built it in two days. The framework mattered: daily standups with myself, explicit "done" criteria for each piece, time-boxed experiments. The technology wasn't just executing tasks; it was helping me manage my own process in a new (for me) product development terrain.

I learned about retrieval systems by implementing one, embeddings by generating them, concept extraction by writing prompts and seeing what broke. Not by reading documentation, but by doing, with a capable partner explaining what I was creating along the way.

The proof of concept extracts concepts from documents and links similar ideas across files. It's rough, and where it breaks is almost more interesting than where it works. Still, it works well enough to explore what I was actually curious about.

This isn't about the technology. It's never about the technology.

It's about learning to ask better questions about the problems I'm trying to solve, and then having more tools to build toward a solution. The gap between identifying a problem and having the means to address it is getting smaller. Not because the technology is magic, but because the skills that close that gap, scoping, structuring, defining what "done" looks like, are ones I've been building for years.

Building is accessible now. And your existing skills are the entry point.

Next up: what the process actually looked like, and why the skills that mattered most weren't the ones I expected.