{"slug": "the-done-when-line-beginners-forget-to-give-ai-before-building-an-app", "title": "The Done-When Line Beginners Forget To Give AI Before Building An App", "summary": "A developer named Marcus Y. Kim advocates for using a 'Done when' line in AI feature requests to prevent AI coding tools from wasting time on incomplete or vague tasks. He explains that specifying a concrete user outcome, such as 'a signed-in user can open an event, choose Going, see their RSVP saved after reopening the app, and see a useful message if the save fails,' helps AI deliver testable results. Kim offers free prompts to help beginners turn ideas into smaller, verifiable plans.", "body_md": "One of the easiest ways to let an AI coding tool waste your afternoon is to ask it to “finish” a feature.\n\nFinish is a mood. It is not a requirement.\n\nYou tell the tool, “Finish the profile screen,” and it gets busy. It adds fields. It adjusts spacing. It may write some validation. It may even tell you the feature is complete with the confidence of a person who just installed a shelf without checking whether it is level.\n\nThen you open the app.\n\nThe screen exists. The button exists. The app may even look polished.\n\nBut can a real person create a profile, leave the app, come back, and still see the right information? What happens if they use an email already attached to another account? What happens if the network drops halfway through saving? What does “saved” actually mean?\n\nThat is why I have become picky about one short line in every feature request:\n\n**Done when: [a user can complete a specific outcome, and I can verify it].**\n\nBefore you ask AI to build anything, you can use my free AI App Builder Starter Prompts to turn a rough idea into a smaller, testable version-one plan:\n\n[https://marcusykim.gumroad.com/l/ai-app-builder-starter-prompts](https://marcusykim.gumroad.com/l/ai-app-builder-starter-prompts)\n\nThe prompts are free because blank-page paralysis is a terrible project manager.\n\nWhen I managed an iOS team at a startup, we organized work around features and user stories. A larger feature might have been a timeline feed, an event flow, a camera experience, or a private group chat. Each feature was broken into smaller user stories that someone could own.\n\nThe useful part was not the vocabulary. You do not need to become an Agile priest and carry a tiny backlog scroll everywhere you go.\n\nThe useful part was that a story had to end somewhere real.\n\n“Build event RSVPs” is a task-shaped cloud. It sounds like work, but it does not tell you when to stop.\n\nThis is better:\n\nDone when a signed-in user can open an event, choose Going, see their RSVP saved after reopening the app, and see a useful message if the save fails.\n\nNow you have something you can test.\n\nYou also gave the AI fewer places to invent. It does not need to guess whether “RSVPs” includes event creation, invitations, attendee chat, calendar syncing, reminders, six filters, a badge system, and a tiny city government.\n\nIt needs to deliver one user outcome.\n\nThat is a much healthier amount of ambition for version one.\n\nFor a beginner, I think a good done-when line should quietly answer four questions.\n\nName the user state that matters.\n\nThis stops AI from building a generic screen that ignores permissions and context.\n\nFor example, “users can delete a post” is incomplete. Which users? The author only? A moderator? Everyone who can see it? Permissions are product decisions wearing engineering clothes.\n\nUse a verb that somebody can actually perform.\n\n“Support recording” is vague. “A musician can tap once to create a recording, hear a metronome, stop, name the take, and export an audio file” is a workflow.\n\nThat distinction matters because workflows expose the missing pieces. You start noticing the need for a microphone permission, a saved file location, an empty state, a failed export message, and a way to find the recording later.\n\nMost apps are not just pretty screens. They are promises about what happens after someone presses a button.\n\nAsk yourself what needs to change for the user to trust the feature.\n\nIf they save a profile, does it still exist after reopening the app?\n\nIf they send a message, does the recipient see it?\n\nIf they mark a task complete, does it remain complete on another device?\n\nThis is where your frontend meets the backend. The screen is the waiter. The saved data is the meal actually arriving at the table.\n\nYou do not have to understand every database detail before starting. You do need to tell AI what the user should be able to trust after the action is over.\n\nThis is the part people skip because it sounds slightly less glamorous than shipping.\n\nBut it is the part that keeps “the AI said it works” from becoming your entire QA department.\n\nFor each feature, decide on a short proof:\n\nYou do not need a 400-line spreadsheet created by someone who says “quality gate” recreationally.\n\nYou need evidence that the feature survives normal use.\n\nWhen you have a feature in mind, give your AI tool this before you let it touch code:\n\n```\nI am building [app name] for [specific user].\n\nThe feature I want is: [feature].\n\nDone when: [one user can complete one specific outcome, including what must save, change, or be visible afterward].\n\nBefore you implement it:\n1. Restate the workflow in plain English.\n2. List the screens, data, permissions, and integrations this feature actually needs.\n3. Name what is explicitly out of scope for this version.\n4. Give me a small QA checklist that proves the done-when line is true.\n5. Ask for approval before changing shared schema, authentication, payments, or unrelated screens.\n\nThen implement only the smallest version that satisfies the done-when line.\n```\n\nThat prompt does not make the AI magically perfect. Nothing does.\n\nWhat it does is turn a fuzzy request into an agreement you can both keep checking.\n\nIf the tool begins adding an unrelated dashboard, three new user roles, or an elaborate notification system, you have a simple sentence to bring it back to:\n\n“Does this help satisfy the done-when line?”\n\nIf not, it probably belongs later.\n\nThere is a business reason for this too.\n\nYour first app does not need to prove that you can imagine every feature it might ever have. It needs to prove that somebody can get real value from one workflow.\n\nA tiny event app does not need to become a social network before you know whether people will RSVP.\n\nA song-idea recorder does not need to become a full digital audio workstation before you know whether musicians actually value one-tap recording, a metronome, and a clean export.\n\nA tutor-management app does not need billing, a marketplace, group video calls, and a mascot before one tutor can add a student and schedule a session.\n\nThe done-when line protects you from confusing visual motion with product progress.\n\nIt gives you something to demo.\n\nIt gives you something to QA.\n\nIt gives you a clean stopping point.\n\nAnd it gives your AI tool a smaller target than “make my app good.”\n\nThat is not a limitation.\n\nThat is how you finish things.\n\nThe practical takeaway is simple: before you ask AI to build a feature, write one sentence describing what a real user will be able to do, what will be true afterward, and how you will verify it.\n\nThen build until that sentence is true.\n\nIf you want a fuller build-along system for idea, scope, stack choice, prompting, QA, deployment, and launch, AI App Builder From Zero is the deeper next step:\n\n[https://marcusykim.gumroad.com/l/ai-app-builder-from-zero](https://marcusykim.gumroad.com/l/ai-app-builder-from-zero)\n\nYou can also find me here:\n\nMedium: [https://medium.com/@marcusykim](https://medium.com/@marcusykim)\n\nDEV.to: [https://dev.to/marcusykim](https://dev.to/marcusykim)\n\nWebsite: [https://marcusykim.com/blog/](https://marcusykim.com/blog/)\n\nX: [https://x.com/marcusykim](https://x.com/marcusykim)\n\nLinkedIn: [https://www.linkedin.com/in/marcusykim/](https://www.linkedin.com/in/marcusykim/)", "url": "https://wpnews.pro/news/the-done-when-line-beginners-forget-to-give-ai-before-building-an-app", "canonical_source": "https://dev.to/marcusykim/the-done-when-line-beginners-forget-to-give-ai-before-building-an-app-5c65", "published_at": "2026-07-11 23:50:35+00:00", "updated_at": "2026-07-12 00:13:31.036705+00:00", "lang": "en", "topics": ["developer-tools", "artificial-intelligence", "ai-tools"], "entities": ["Marcus Y. Kim"], "alternates": {"html": "https://wpnews.pro/news/the-done-when-line-beginners-forget-to-give-ai-before-building-an-app", "markdown": "https://wpnews.pro/news/the-done-when-line-beginners-forget-to-give-ai-before-building-an-app.md", "text": "https://wpnews.pro/news/the-done-when-line-beginners-forget-to-give-ai-before-building-an-app.txt", "jsonld": "https://wpnews.pro/news/the-done-when-line-beginners-forget-to-give-ai-before-building-an-app.jsonld"}}