Back to blog

Building Products Solo With AI

December 20, 20253 min read
Building Products Solo With AI

Three months ago I wrote about going part-time to focus on building products. Since then, I've shipped more working software than in any comparable period of my career.

Not because I'm working harder. Because the leverage has changed.

What's actually different

Five years ago, if I wanted to build a web app with authentication, a database, API integrations, and a polished UI, I'd need a team. Or I'd need to spend months doing it myself, context-switching between frontend, backend, and ops.

Now I can do it in a week. Sometimes days.

The AI tools I use daily have collapsed the execution time on almost every part of the stack. Need a React component? Describe it and refine. Need to integrate an API? Paste the docs and ask for help. Need to debug something weird? Share the error and the context.

What used to be blocked by "I don't know how to do that" is now blocked by "I haven't asked for help with that yet."

What AI is good at

After months of building this way, I have a clearer picture of where AI helps most:

Boilerplate and scaffolding. Setting up projects, writing CRUD operations, creating UI components that match existing patterns. This used to be tedious. Now it's instant.

Translating between domains. I understand product. I understand systems. AI bridges the gap to specific implementation details I don't have memorized - CSS properties, library APIs, deployment configs.

Rubber duck debugging. Explaining a problem to Claude often solves it before Claude responds. But when it does respond, it usually spots something I missed.

First drafts of everything. Code, docs, specs, copy. I almost never start with a blank page anymore.

What AI is bad at

Taste. AI can build what you describe, but it can't tell you what's worth building. That's still on you.

Coherent architecture over time. Each conversation starts fresh. AI doesn't remember the decisions you made last week or why you structured things a certain way. It will happily suggest approaches that contradict your existing patterns.

This second problem is the one I've been thinking about most. The models are good enough. What's missing is continuity - the ability to maintain context across sessions, tools, and time.

The spec-driven approach

My solution: I write specs before I build. Not formal requirements documents - just clear descriptions of what I'm building and why, the decisions I've made, and the constraints I'm working within.

Then I feed those specs to whichever AI I'm working with. It's like onboarding a new team member for every session, except it takes thirty seconds instead of thirty days.

This works, but it's manual. Copy-paste, re-explain, repeat. I've been thinking about how to make this automatic - how to give AI tools access to my project context without re-uploading it every time.

I've been working on something. More on that soon.