An AI agent can start building in the first minute, and it will build your first description at full speed. The problem is that your first description is usually a guess. You find out a week later, when the thing works fine and you still don't use it. An hour spent figuring out what you want is cheaper than a week spent building the wrong thing.
I'm at this step right now with a workout tracker, so I'll use it as the example the whole way through.
Start with what and why
You should be able to answer three questions in a sentence each before the first build prompt. Here are mine.
Who is it for? Just me, at least to start.
Where will I use it? My phone, standing in the gym.
What must it do on day one? Log a workout and show me the log.
Write yours down, because every choice the agent brings you later gets easier to answer against them.
Then figure out the why, and make it something you can test. Mine is "do I open it and look every day?" Yours might be "did I stop paying for the app this replaces" or "did my club actually sign up through it." If you can't describe what using it looks like next Tuesday, you have a research question, and that's the next section.
Notice my first answer, because it matters most. If this is your first project ever, build it for yourself even when the bigger idea is for other people. A for-you version runs on your own computer, costs nothing, and needs no accounts. Have the agent keep it local and explain the moving parts as it builds, and learn a little about things like Docker along the way. Then use it yourself for a week or two, developers call this dogfooding, and see if the idea stands. If you're still using it, that's the point to ask the agent about opening it up to other people on Supabase, Vercel, Railway, Fly, or whatever fits the project. Expanding something you already use is an easier conversation than guessing what strangers need on day one.
Do the research with the agent
The same agent that builds can dig first, and it's good at it. Tell it the idea, then ask what already exists, what people who use those things complain about, and two or three ways yours could be built, with the trade-offs in your terms: what it costs to run, what breaks, and what you'd have to maintain.
Mine went like this:
I want to track my workouts from my phone. Before we build anything,
look into it. What do existing workout apps get wrong? What are two
or three ways we could build ours? Which would you pick for one
person who wants zero upkeep, and why?
The agent does the legwork. The decision stays yours.
Make it document what it finds. Research turns up a lot of moving parts and a lot of text, and a chat conversation scrolls away. Ask the agent to write its findings into documents you can reread and mark up, and keep them in the project folder. They become the memory you'll both lean on once building starts.
Ask for pictures too, because some choices are easier to make by looking than by reading. An HTML mockup lets you see and click a rough version of a screen before anything real is built. For my tracker, the question a mockup settles is whether logging a set takes one tap or three, and no paragraph of description can answer that. A Mermaid diagram, which the agent can draw from plain text, shows you how the pieces link together. Ten minutes of looking at a sketch settles questions that pages of text leave open.
Check what it tells you
Two problems with what the agent knows, one old and one new.
The old one is age. The model behind your agent learned about the world up to a cutoff date, and that date is always months in the past. Tools, versions, and prices move faster than that. Whenever it recommends a tool or library, quotes a price, or tells you the best way to do something this year, tell it to search the web first because its information might be stale, and ask when the thing it's recommending was last updated. The check takes a minute.
The new one is that the internet is now being written for your agent. Marketers have figured out that AI agents read the web and repeat what they find, so there's an industry producing pages designed to be the answer your agent gives. They call it generative engine optimization. The aggressive version goes further. Microsoft's security team reported over 50 attempts in 60 days, from 31 companies, to plant hidden instructions that steer what AI assistants recommend. Researchers have also shown that a single planted line on a product page can turn a product an AI never recommended into the one it recommends most.
A few habits make your agent harder to fool.
- Ask where a claim came from. If every source turns out to be the company selling the thing, keep looking.
- Ask what real users complain about, not just what fans say. Complaints in forum threads are harder to fake than praise on a product page.
- Never accept a single candidate for a tool choice. Ask for two and the reason to prefer each.
- Use official docs for facts and real users for experience, and be suspicious of pages that read like they were written to be quoted.
It's the same skepticism you already use on the first page of Google results.
Then build the smallest slice
Once the what and why are set and the research is in, resist the urge to spec everything. Pick the smallest version you would actually use this week and build only that. My tracker starts as a page where I log an exercise and see the list. Charts, streaks, and history views all wait until logging feels right, because if logging doesn't feel right I'll never see the charts anyway. The big vision still happens, it just arrives in slices, and the first slice teaches you more about what you want than planning ever does.
I build Koda, a Mac app for building things with an AI agent. It asks the what-and-why questions before it builds. But everything in this guide works in any tool.
Give your agent this prompt:
I want to build [describe your idea]. Before we build anything, help me decide what the first useful version should be. Ask who it is for, where they will use it, what it must do on day one, and how we will know it is useful. Then research what already exists and what real users complain about. Give me two or three ways to build the smallest version, with the cost, upkeep, and trade-offs explained in plain language. Put the result in a short project brief I can review before we start.