I built an app for myself from zero using an AI agent as my main collaborator, and honestly, the process taught me more about product thinking than any tutorial has. People keep asking me what it's actually like to build this way, so I figured I'd write down the whole thing, step by step, issues and all.
Let me start with the obvious question: is this actually different from building software the normal way? Sort of. The steps aren't new. Idea, spec, design, build, that's the same shape software has always had. What's different is the amount of thinking you're forced to do up front, and who you're doing that thinking out loud with. Here's how it actually went.
Start with the idea, and build from there
Every build starts with an idea. Mine was simple: I wanted a trivia app that felt fast and had no fluff. That's it. No spec, no diagrams, just a problem I was curious about .
The mistake people make here is jumping straight into building. I get the urge. You have an idea, you're excited, you want to see something on screen. Don't. Sit with the idea for a bit first. Write one sentence about why it matters to you. If you can't do that, you're not ready to build it yet, agent or no agent.
Talk it out before you write anything down
Once I had the idea, I opened a chat with the agent and just talked. Not about code, about the app itself. What is this for? Who's it for? What does "done" even look like? Is this a weekend project or something I actually want to ship and maintain?
This stage is loose on purpose. You're not writing requirements yet, you're figuring out what you actually want. I've found this works best when I treat the agent less like a tool and more like a smart friend who happens to remember everything I've said in the conversation. I ramble, it asks follow-ups, I clarify. Nothing gets written to a doc yet. It's just thinking, except now the thinking has a second voice in it.
Then let it grill you
This is the part most people skip, and it's the most valuable one. After the initial chat, I ran a "grilling" session where the agent pushed back on every soft spot in my thinking. Where the scope was vague, it asked. Where I hadn't decided on something, it made me decide right there instead of letting me punt on it.
It's uncomfortable in a useful way, kind of like a good code review before you've written any code. Questions like: what happens if a user switches languages mid-session? Is that even a feature you want, or scope creep dressed up as thoughtfulness? Do you actually need accounts, or were you just assuming you did because every app has them?
By the end of this session, the gaps were closed and I actually knew what I was building. Not a vague version of it. The actual thing, with edges.
I think this is the step that separates people who ship from people who have forty half-built side projects. It's tedious, but it's cheap. Way cheaper than discovering the same gap three weeks into implementation.
Turn the discussion into documents
With that clarity, I had the agent draft a PRD and a TRD. The PRD locked in the product decisions: target user, core features, what's explicitly out of scope. That last part matters more than people think. A feature list without a "not doing this" list is just wishful thinking.
The TRD handled the technical side: stack choices, data layer, integrations, and why each one made sense for this app specifically, not just because it's popular this year. For this trivia app that meant deciding on Flutter, Firestore for real-time data, an external trivia content API, and a translation pipeline to actually support the bilingual promise I made myself back in step one.
These docs aren't just paperwork for later. Writing them is where fuzzy intentions become real decisions. You can feel the difference between "I want it to be fast" and "load time under two seconds on a mid-range phone." One of those you can build toward. The other is a vibe.
Design before you build
I also had the agent generate mockups before touching real code. Seeing actual screens, even rough ones, exposed problems that no document caught. A feature that sounded fine in the PRD looked cluttered on an actual screen. Better to find that out with a mockup than after three days of building it.
Plan before you build
Skipping straight from spec to code is tempting, but a short planning step pays for itself. The agent broke the build into phases with real dependencies mapped out, not just a checklist. Things like "auth before data layer" that I might have sequenced wrong on my own, or not thought about at all until I hit a wall.
This is also where I catch myself being overambitious. It's easy to write a PRD that sounds reasonable and then realize, once it's broken into phases, that phase one alone is a two week job. Better to know that on paper than halfway through a Saturday.
Build, then get out of the way
Implementation is where the agent does the heavy lifting. I still steered constantly: correcting edge cases, checking security rules, deciding when something "good enough" was actually good enough. But the scaffolding, the boilerplate, the repetitive parts? That's exactly what the agent should own. My job shifted from typing every line to reviewing every decision, which is a different skill and, honestly, a more interesting one.
What I'd tell you if you're about to try this
The agent isn't a shortcut around thinking. It's more like a sharp collaborator who won't let you get away with vague ideas. The real value shows up in that grilling stage, not the coding stage, which surprised me. I expected the time savings to come from writing less code. Instead they came from wasting less time building the wrong thing.
Most people think AI development is about writing code faster. It's not, or at least that's not the interesting part. It's about being forced to know what you're building before you build it. The agent just makes that forcing function a lot less painful than staring at a blank doc by yourself.
That's the whole loop: idea, discussion, grilling, spec, design, plan, build. Simple on paper. Genuinely useful in practice. If you're about to start a project like this, my honest advice is don't rush past the grilling stage to get to the fun part. The fun part goes a lot smoother when you do.
