The Done-When Line Beginners Forget To Give AI Before Building An App

One of the easiest ways to let an AI coding tool waste your afternoon is to ask it to "finish" a feature. Finish is a mood. It is not a requirement.

You 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. Then you open the app. The screen exists. The button exists. The app may even look polished. But 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?

That is why I have become picky about one short line in every feature request: Done when: [a user can complete a specific outcome, and I can verify it].

Before 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: https://marcusykim.gumroad.com/l/ai-app-builder-starter-prompts. The prompts are free because blank-page paralysis is a terrible project manager.

"The Screen Exists" Is Not A Definition Of Done

When 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. The useful part was not the vocabulary. You do not need to become an Agile priest and carry a tiny backlog scroll everywhere you go. The useful part was that a story had to end somewhere real.

"Build event RSVPs" is a task-shaped cloud. It sounds like work, but it does not tell you when to stop. This is better:

Done 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.

Now you have something you can test. You 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. It needs to deliver one user outcome. That is a much healthier amount of ambition for version one.

The Line Has Four Jobs

For a beginner, I think a good done-when line should quietly answer four questions.

1. Who is doing the thing?

Name the user state that matters.

• A new visitor
• A signed-in customer
• An event host
• A musician recording a song idea
• An admin reviewing a report

This stops AI from building a generic screen that ignores permissions and context. For 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.

2. What is the one action?

Use a verb that somebody can actually perform.

• create
• save
• search
• record
• invite
• pay
• export
• delete

"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. That 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.

3. What must persist or change?

Most apps are not just pretty screens. They are promises about what happens after someone presses a button. Ask yourself what needs to change for the user to trust the feature.

• If they save a profile, does it still exist after reopening the app?
• If they send a message, does the recipient see it?
• If they mark a task complete, does it remain complete on another device?

This is where your frontend meets the backend. The screen is the waiter. The saved data is the meal actually arriving at the table. You 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.

4. How will you prove it worked?

This is the part people skip because it sounds slightly less glamorous than shipping. But it is the part that keeps "the AI said it works" from becoming your entire QA department. For each feature, decide on a short proof:

• complete the workflow with a normal account
• try one bad input
• reload the app and confirm the important data remains
• test a permission or account boundary if the feature has one
• make sure a failure produces a useful message instead of an endless spinner

You do not need a 400-line spreadsheet created by someone who says "quality gate" recreationally. You need evidence that the feature survives normal use.

A Prompt I Would Use With An AI Coding Tool

When you have a feature in mind, give your AI tool this before you let it touch code:

I am building [app name] for [specific user]. The feature I want is: [feature]. Done when: [one user can complete one specific outcome, including what must save, change, or be visible afterward].

Before you implement it:

1. Restate the workflow in plain English.
2. List the screens, data, permissions, and integrations this feature actually needs.
3. Name what is explicitly out of scope for this version.
4. Give me a small QA checklist that proves the done-when line is true.
5. Ask for approval before changing shared schema, authentication, payments, or unrelated screens.

Then implement only the smallest version that satisfies the done-when line.

That prompt does not make the AI magically perfect. Nothing does. What it does is turn a fuzzy request into an agreement you can both keep checking. If 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: "Does this help satisfy the done-when line?" If not, it probably belongs later.

Done-When Lines Keep Your App Honest

There is a business reason for this too. Your 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.

• A tiny event app does not need to become a social network before you know whether people will RSVP.
• A 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.
• A 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.

The done-when line protects you from confusing visual motion with product progress. It gives you something to demo. It gives you something to QA. It gives you a clean stopping point. And it gives your AI tool a smaller target than "make my app good." That is not a limitation. That is how you finish things.

The 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. Then build until that sentence is true.

If 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: https://marcusykim.gumroad.com/l/ai-app-builder-from-zero

You can also find me here:

• Medium: https://medium.com/@marcusykim
• DEV.to: https://dev.to/marcusykim
• Website: https://marcusykim.com/blog/
• X: https://x.com/marcusykim
• LinkedIn: https://www.linkedin.com/in/marcusykim/