Not because the tools were bad. Because I kept skipping the part where you decide what you’re making.
I’m not a developer. I can follow along when someone explains code, and I find the whole thing interesting — but writing it from scratch has always been just slightly out of reach.
For about four or five months, I kept trying to shortcut my way past that gap. ChatGPT, Lovable, Cursor, Claude Code. I’d generate something, hit a wall, delete it, start over. The bill kept going up. Nothing stuck.
What took me longer than it should have to figure out: the tool was never the problem. I kept skipping the step where you decide what you’re actually building. Not broadly — specifically. What it does, what it doesn’t do, how much you know about the tech involved, what it’s going to cost before it earns anything.
Once I stopped skipping that step, things started working. Here’s the process I’ve settled on, using a personality analysis site I built recently as the example.
The planning phase feels slow when you’re in it. It’s not. It’s the part that makes everything after it faster.
Start with a conversation, not a prompt
The idea was a site where people answer questions and get back real psychological insight — backed by actual research, not horoscope-level observations. Simple enough to prompt into existence in an hour with Lovable. But that version would’ve been a dead end. Nothing to improve, nothing to debug when something broke.
So instead of opening Lovable, I opened ChatGPT and just talked through the idea until I could describe it clearly. Not a pitch — features, constraints, what I actually wanted it to do. Once that felt solid, I asked it to turn everything into a PRD. A product requirements document. Markdown file. That’s it.
Before moving on, I made myself answer three questions honestly:
| 01 | How much do I actually know about building this? Not in general — specifically, for this project. The answer shapes the stack, the timeline, and how much help I’ll need at each step. |
| 02 | What is this going to cost, and for how long before it earns anything? My rule now: if ChatGPT estimates one month, I budget for three. That ratio has held. |
| 03 | Does anyone actually want this? Once I had the PRD, I used it to generate a deep research prompt for Gemini — market research scoped to my specific idea, not the general category. |
If the idea held up under that scrutiny, I moved to a TRD — technical requirements. Same approach: give ChatGPT the PRD, ask for a stack recommendation that fits both the product and my skill level. Free tiers where possible. Cloudflare for CDN. Supabase for the database. Not the perfect stack — the one I could actually operate.
The implementation plan is the source of truth
With PRD and TRD done, I give both to a fresh ChatGPT chat and ask it to generate a prompt for Claude Opus — specifically for creating a phased implementation plan.
This is the step I’d tell myself not to rush.
Opus produces a plan that breaks the entire build into slices. Each phase has a clear scope. That plan becomes the source of truth for everything after it — not the conversations, not the individual prompts. The plan.
I run a quick sanity check: send the plan back to ChatGPT for review. If it rates above 8 out of 10, I move forward.
Fresh chats in both ChatGPT and Cursor for every phase. The context window fills up, and when it does, things start going sideways in ways that are hard to trace.
How a phase actually runs
I set up a ChatGPT project with the implementation plan in the context. The instruction: we build one phase at a time, we don’t deviate.
For each phase, the loop looks like this:
| → | ChatGPT writes a prompt for the phase — in a code block so it’s easy to copy cleanly. |
| → | I paste that prompt — only that prompt — into a fresh Cursor agent session. Cursor executes. |
| → | Cursor gives me a summary of what it did. I give that summary back to ChatGPT: did the phase complete properly? |
| → | When it’s done, I run one more audit prompt through Cursor. If it passes, I move on. |
One thing I learned that isn’t obvious: when you’re reading unfamiliar documentation or trying to understand something you don’t know, open a new chat. Don’t ask in the same thread where you’re building. The context gets bloated and the answers get worse.
The context document — the thing I didn’t expect to matter
After each phase, I export the entire conversation as a markdown file. I give that file to Claude Sonnet with extended thinking and ask it to compress the development history into a clean context document: decisions made, deviations from the plan, bugs that came up and how they were resolved.
That compressed file goes into the ChatGPT project context. I open a fresh chat. Start the next phase.
This sounds like extra work. It’s the opposite. Without it, context from phase one leaks into phase three in unpredictable ways. Decisions you made early get re-litigated by the model because it’s lost track of why you made them. The compressed file prevents that.
Audits, not vibes
Once all phases are done, I do a full codebase audit with Opus. The prompt is generated by ChatGPT with the implementation plan attached. Opus goes through everything — bugs, security issues, places where something was over-built or under-built, things that don’t follow standard practice.
I fix what it finds. Then I run the audit again. I keep going until I get a clean report.
After that: manual testing. ChatGPT gives me a checklist of things to verify before launch. I go through it and note anything that feels off — UI problems, anything that doesn’t behave the way I expected. One final Opus audit. If it clears, I move to deployment.
Deployment is its own sequence. ChatGPT walks through it in phases too. What files go where, which cloud services need to be connected, what gets configured first.
What I actually got wrong
I thought the tools were holding me back. They weren’t. I was giving them incomplete instructions and expecting them to fill in the gaps I hadn’t filled in myself.
The workflow I’m describing isn’t complicated. It’s just sequential. Do the thinking before you start building. Write it down. Use that document to generate the next document. Keep the context clean. Audit before you ship.
I’ve built a few things with this now, and each one has gone more smoothly than the last — not because the tools got better, but because I stopped treating the planning phase as something to get through quickly on the way to the interesting part.
It is the interesting part. I just didn’t see it that way until I’d wasted enough time proving it.
Tools mentioned: ChatGPT, Claude Opus, Claude Sonnet, Cursor, Lovable, Gemini Deep Research, Supabase, Cloudflare.