How I Built My First AI Product Alone, and Everything I'd Do Differently

Six months in, the product worked. Every feature I'd designed did what I'd designed it to do. The AI layer was running. The logic held. If you sat me down today and asked me to walk through every decision I made, I could defend most of them.

The problem was that I was the only person who could do that.

I built a general ERP system alone. AI-assisted, fully solo, six months of evenings and weekends and the particular tunnel vision that comes from being both the PM and the engineer and the QA and the person who decides when something is done. The system existed. It worked.

And then a real user sat down with it and got stuck in the first ten minutes.

Not on a bug. On the logic. On decisions I'd made at 1 AM that made complete sense to me — and no sense to anyone who hadn't been there when I made them.

"Building alone is not the same as building for one person. Building for the product is not the same as building for the people who have to live inside it every day."

I know that now.

The Build That Didn't Know When to Stop

Here's what solo building does to scope when nobody's watching.

You start with a clear plan. Then you think of one improvement. Then another. Then you realize the first thing and the third thing need to talk to each other, so you build the connection. The connection needs its own logic. The logic needs its own interface. Six months later you have something technically impressive that only you can navigate without a guide.

I knew what scope creep was. I had warned other people about it. I had put it in documents with headers and bullet points. I did it to myself anyway — enthusiastically, for half a year — because I cared about the wrong things.

Here's what makes that so easy to miss when you're inside it: every single addition felt like the right call at the time. The first feature outside the original scope felt like discipline — I'd spotted a gap before a user had to find it. The second felt like thoroughness. The third felt inevitable once the first two existed. By the time I was building bridges between features that didn't need to talk to each other, I had long stopped asking whether something should exist and started only asking how to build it.

That's the trap. Scope creep doesn't feel like drift. It feels like momentum. And when you're building alone, there's no one to sit across from you and ask the question that actually matters: who asked for this?

I cared about what the system could do. About the elegance of how it was built. About making something I'd be proud to explain to another engineer.

What I didn't care about enough was the person opening it on a Tuesday morning who needed to get something done in ten minutes and had no interest in the elegance of the architecture.

Three Mistakes, Named Specifically

When the first real user got stuck, she wasn't stuck on something I'd built badly. She was stuck on something I'd built well — for myself.

• Built for capability, not comprehension. Every feature added power. None of the decisions asked: can someone understand this without me in the room to explain it? The more the system could do, the harder it was to know where to start.

• Treated complexity as quality. I built the engine of a plane and forgot that pilots need readable instruments. A system that handles every scenario is useless if the person using it can't tell which scenario they're in.

• Optimized for what interested me. The AI integration got my best hours. Automation logic got my best thinking. The onboarding flow, the error messages, the documentation — those kept getting scheduled for later. Later didn't come until someone needed them and they weren't there.

And the AI layer — it worked. That was never the issue.

"I built the intelligence without the legibility. The system was doing things users couldn't predict or explain, which made them distrust it even when it was right."

What I'd built wasn't a product. It was a dependency. On me being available to translate it.

What I'd Actually Do Differently

Not in theory. In order.

That distinction matters more than it sounds. Most advice about building better gets treated as a checklist — items you can shuffle, skip, or revisit whenever convenient. This isn't that. The sequence is the lesson. You can't talk to users after you've already built the thing, because by then you're not learning what to build, you're defending what you've already built. Each step only works if the one before it happened first. Skip step one and everything after it is built on assumption. The order isn't arbitrary. It's the whole point.

1. Talk to five users before writing a single line of code. Not to validate the idea. To learn their language — the specific words they use when something breaks, the workarounds they've built in spreadsheets, what they actually wish existed rather than what you assume they need.

2. Build one workflow, not a system. Not a general ERP. The one workflow that, done well enough, someone would choose over their spreadsheet. Ship that. Watch what breaks. Build the next one from what you learned.

3. Design the support experience before the product. What does someone do at 9 AM on a Monday when they're stuck and you're not available? If you can't answer that before you build, you're building something that only works when you're present.

4. Make the AI explainable before making it smart. Every AI action should come with a sentence a human can read and decide whether to trust. "This matches the pattern from last month's inventory close" is useful. A number with no context is just noise with confidence.

5. Build with a user, not just for one. Not a co-founder. A real user who agrees to break the thing regularly and tell you where they got confused. Solo building means being the only one writing the code. The decisions about what to build should never be made alone.

On the Second Draft

This isn't a regret letter. The product taught me things I couldn't have gotten another way.

The PM in me knew how to write a spec. The builder in me learned what it feels like when the spec meets a real user and the gap between them is your problem to close. The lecturer in me now has a library of specific, lived, hard-earned lessons that I actually know to be true — rather than things I read somewhere and repeated.

Every first draft tries to do too much. Assumes the reader has more patience than they do. Falls in love with its own architecture.

"The second draft is where you cut what you love and keep what works. The product is not the point. The person using the product is the point."

Build less. Talk to users more. Ship before you're comfortable.

And write the help documentation before you build the feature that needs it.