DEV Community: Marcus Kim

How To Know Whether AI Fixed The Bug Or Hid The Bug In 2026

Marcus Kim — Sat, 25 Jul 2026 20:48:43 +0000

The most dangerous sentence in an AI-built app is often:

The bug is fixed.

That sentence can mean several different things:

the original symptom disappeared;
the error message was hidden;
the failing path was bypassed;
the code now handles one example but not the workflow; or
the change fixed one screen while quietly breaking another.

I have learned to treat an AI-generated bug fix as a claim that needs evidence, not as a conclusion.

The beginner-friendly rule is this:

A bug is fixed only when the original failure is gone, the intended behavior works, and the nearby behavior still works.

That is a small regression test. You do not need a large QA department to run it. You need a clear before-and-after record.

If you are staring at a blank prompt box, my AI App Builder Starter Prompts are free and include prompts for scope, debugging, QA, deployment, and launch. The useful part is not asking AI to sound confident. It is making the proof request specific.

First, Capture The Bug Before Changing Code

Before asking AI to fix anything, write down the smallest reproducible version of the failure.

Use this format:

Starting state:
[what must already be true]

Actions:
1. [action]
2. [action]
3. [action]

Expected result:
[what a user should see or be able to do]

Actual result:
[what happens instead]

Evidence:
[error text, screenshot, console output, or saved record]

For example:

Starting state: I am signed in and have one saved task.
Actions: open the task, edit its title, press Save, refresh the page.
Expected result: the new title remains after refresh.
Actual result: the screen says Saved, but the old title returns.
Evidence: the network request succeeds, but the database record is unchanged.

That description is much more useful than “Saving is broken.” It gives AI a path, an expected outcome, and a place to look for false success.

The Four Proofs Of A Real Fix

When AI proposes a patch, I want four separate proofs.

1. The original reproduction now passes

Run the exact same starting state and actions. Do not paraphrase the steps because the patch may only work under a slightly different condition.

If the original reproduction cannot be run anymore, ask why. Sometimes the code change genuinely changed the workflow. Sometimes the test data disappeared. Sometimes the error was hidden. “I cannot reproduce it” is not the same as “it is fixed.”

Record the result plainly:

original steps: pass or fail;
expected result: observed or not observed; and
evidence: screenshot, saved record, test output, or visible state.

2. The data or state is correct underneath

Screens can lie by being polite.

A toast that says “Saved” does not prove that the record was saved. A blank error area does not prove that an invalid request succeeded. A loading spinner that stops does not prove that the correct result arrived.

Check the state behind the screen using the safest visible tools available to your project:

refresh the page;
close and reopen the app;
sign out and back in when ownership matters;
inspect the visible record in the database dashboard if that is part of your workflow; or
run the project’s existing test or logging command.

The question is: did the promised state change persist in the place where the product actually owns it?

3. The failure is still honest when it should fail

A real fix does not turn every input into a success message.

Try one invalid input, one missing value, one offline or timeout condition, or one unauthorized account when the bug involves those boundaries. The exact test depends on the feature, but the principle is stable: the app should fail clearly and safely.

If AI changed a validation error into an empty result, it may have hidden the bug. If it catches every exception and returns a generic success object, it may have hidden several bugs at once.

Ask:

When this request is invalid or unavailable, what does the user see, what state is written, and how can they recover?

4. The neighbor workflow still passes

Most bug fixes touch shared code. That means the original screen is not the only thing worth testing.

If AI changed a shared form component, test another form. If it changed an authentication check, test both an owner and a non-owner. If it changed a database query, test an empty list and a list with several records. If it changed mobile layout code, test a smaller screen and a keyboard-open state.

You are not trying to test the entire universe. You are testing the closest behavior that could have been affected by the same change.

The Before-And-After Table I Use

For a small app, this is enough:

Check	Before patch	After patch	Evidence
Original reproduction	Fails	Passes	visible result or test output
State after refresh	Old value returns	New value remains	refreshed screen or record
Invalid input	Misleading success	Clear correction path	error state
Neighbor workflow	Passes or fails	Still behaves as expected	second scenario
Logs and secrets	Error or unsafe data	Useful, non-sensitive evidence	log/test review

The table is deliberately boring. Boring is good. It stops a confident explanation from replacing a working product.

A Debugging Prompt That Requests Proof

I would give AI this prompt instead of “fix the bug”:

Treat this as a regression investigation, not a request for a confident explanation.

Bug reproduction:
[starting state, exact actions, expected result, actual result]

Constraints:
[files or behavior that must not change]

Before editing code:
1. Explain the most likely cause and the evidence that would confirm it.
2. List the smallest files or functions that may need to change.
3. Name one way a patch could hide the symptom instead of fixing the cause.

After proposing the patch, provide:
1. The exact original reproduction to rerun.
2. One persistence or underlying-state check.
3. One invalid-input or failure-path check.
4. One nearby workflow that could regress.
5. A short explanation of what evidence would make us reject the patch.

Do not remove an error merely to make the screen look successful. Do not broaden the change beyond the stated bug without explaining why.

The phrase “what evidence would make us reject the patch” is important. It gives you a way to disagree with AI before the code becomes too large to understand.

When The Fix Is Not Ready

I would keep the bug open if any of these are true:

the original steps changed without an explanation;
the UI says success but refresh loses the result;
the error disappeared and no replacement behavior exists;
the fix works only with one hard-coded example;
the patch changes unrelated screens without a clear reason;
no failure-path test was run; or
nobody can say what evidence proves the underlying state is correct.

That is not perfectionism. It is a boundary between a demo and a product.

The deeper field manual behind this workflow is AI App Builder From Zero. It walks through the larger path from idea and scope to architecture, prompting, QA, deployment, and launch. Use it when you need the whole build system, not just one debugging prompt.

The Short Version

When AI says it fixed a bug, ask it to help you prove four things:

The exact original reproduction passes.
The underlying state is correct after refresh or relaunch.
Invalid or unavailable inputs still fail honestly.
The nearest shared workflow did not regress.

If you can show those four proofs, you have more than a plausible patch. You have a defensible fix.

If you want a free place to start, AI App Builder Starter Prompts gives you practical prompts for turning a rough idea into scoped, testable work. The prompts are free. When you are ready for the deeper build-along process, AI App Builder From Zero is the next step.

You can also find me here:

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

What Beginners Should Check Before Trusting AI-Generated Code In 2026

Marcus Kim — Fri, 24 Jul 2026 00:29:17 +0000

AI can write code that looks finished

One of the most dangerous moments in AI-assisted development is not the obvious error.

It is the moment when the app runs, the screen looks polished, and you assume the code underneath must be sound.

I have learned to separate two questions:

Can this code produce the screen or behavior I asked for?
Does this code preserve the rules my app is supposed to follow?

The first question is a demo. The second is engineering.

AI is very good at producing a plausible first answer. It is not automatically good at preserving your product's boundaries while changing one part of the system.

That is why I review AI-generated code before I trust it, even when the feature appears to work.

Start with the user contract, not the code

Before opening the changed files, write down what the feature is supposed to do in one sentence.

For example:

A signed-in user can save a private note and see only their own saved notes after refreshing the page.

That sentence gives you more to review than a vague request such as “add notes.” It contains a user, an action, ownership, and a persistence expectation.

Then ask AI to show where each part of that contract is implemented:

Where is the user identified?
Where is ownership enforced?
Where is the note saved?
Where is the saved note loaded again?
What happens when the user is signed out?
What happens when the request fails?

If the answer cannot point to those boundaries clearly, the feature is not ready for trust.

The five checks I use before trusting a change

1. Check the data path

Follow the data from the input field to the database or storage layer and back to the screen.

Do not stop at the component that looks correct.

Ask:

Is the input normalized or validated?
Is the data shape the same at every layer?
Is a missing value treated differently from an empty value?
Is the saved record loaded from the real source, or only held in local screen state?
Could an old field name silently produce an empty result?

AI can update a type, a form, and a query in three different ways. Each change can look reasonable in isolation while the path between them is broken.

I want to see the contract between layers, not just a collection of green-looking files.

2. Check who is allowed to do what

A button being hidden is not the same as an action being protected.

If an app has accounts, private data, paid features, admin actions, or shared workspaces, find the actual authorization check.

Ask:

Does the server or database verify ownership?
Can a user change an ID in a request and read somebody else's record?
Are create, read, update, and delete rules consistent?
What happens when the session expires halfway through an action?

The beginner-friendly way to review this is to imagine two test accounts. If account A can change an identifier and see account B's data, the feature is not secure just because the UI shows the right menu.

3. Check the failure paths

AI often spends most of its attention on the happy path: valid input, working network, existing record, expected response.

Review the opposite cases deliberately.

What does the user see when the request times out?
Is a failed save presented as a success?
Can the user retry without creating duplicates?
What happens when the response is empty?
Does an error leave stale data on screen?
Is a loading state cleared on every exit path?

A feature is not finished when it works once. It is finished when the user can understand what happened when it does not work.

4. Check the change surface

Ask AI to list every file, schema, route, dependency, permission, and environment variable it changed.

Then compare that list with the request.

This catches a common failure mode: a small feature quietly changes shared code used by unrelated screens.

I also look for:

duplicated business rules,
new dependencies that solve a problem the project already solved,
broad refactors mixed into a narrow feature,
renamed fields without a migration path,
fallback behavior that hides a configuration error.

The more unrelated surface area a change touches, the more proof it needs. “The new screen works” is not proof that the old screens survived the change.

5. Check whether the code explains itself

Readable code is a QA tool. If you cannot tell what a function is allowed to change, you cannot review it confidently.

Look for clear names, small responsibilities, predictable error handling, and comments that explain decisions rather than narrate syntax.

When AI generates a large function, I ask it to explain:

the inputs it expects,
the side effects it performs,
the errors it can return,
the data it is allowed to read or write,
the assumptions that would make it unsafe.

If that explanation reveals hidden assumptions, I fix the boundary before polishing the implementation.

A review prompt I would give AI

You can use this as a starting point:

Review the changed code against this user contract: [write one sentence]. First map the data path from input to persistence to display. Then list every authorization check and identify any action protected only by the UI. Then inspect timeout, empty, invalid-input, duplicate-submit, and expired-session behavior. List every changed file, dependency, schema, route, environment variable, and shared component. Identify regressions this change could cause outside the requested feature. Do not rewrite the code yet. Report evidence by file and function, then give me the smallest safe correction for each issue.

The important instruction is “do not rewrite the code yet.” I want the review before the next burst of generated code. Otherwise AI may confidently patch an assumption that nobody has inspected.

What I would not use as proof

These are useful signals, but none is enough by itself:

The app compiles.
The page looks right.
The happy-path demo passed.
AI says it fixed the bug.
There are no visible errors in the browser console.
The code is long and detailed.

The proof has to connect the implementation to the user contract. It has to include the boundaries where data, permissions, failures, and unrelated features can leak.

My rule for beginners

Do not ask, “Did AI write good code?”

Ask, “What rule is this code responsible for preserving, and what evidence shows that it still preserves it?”

That question changes your role. You are no longer grading code by how impressive it looks. You are checking whether the system still behaves like the product you intended to build.

If you want a guided starting point, I made the AI App Builder Starter Prompts, and they are free. They help turn a blank prompt box into a more specific conversation about scope, architecture, implementation, and proof.

For the deeper, end-to-end path from idea through prompting, building, QA, deployment, and launch, the next step is AI App Builder From Zero.

The goal is not to stop using AI. It is to make AI's speed answer to your standards.

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/

What My First Freelance App Taught Me About Scope Creep In 2026

Marcus Kim — Mon, 20 Jul 2026 18:42:22 +0000

The most dangerous sentence in a freelance software project is usually not, “We need to rebuild everything.”

It is, “Could we also add one small thing?”

One small thing sounds harmless. It sounds like a button, a field, a filter, a notification, or a slightly different screen. It sounds like the kind of request a helpful person should absorb without making a production out of it.

That is how a project quietly becomes a different project.

I learned this while working on my first major freelance app project. I was the only person responsible for the work, which meant every new request landed on the same small system: my time, the app's existing behavior, the backend, the QA pass, the next demo, and the client's expectations.

The lesson was not that clients are bad when they ask for more. Most scope creep is not a villain entering through a trapdoor. It is a reasonable person noticing a better idea after seeing the first version.

The lesson was that a new feature request is a decision, not a task.

Every new feature spends one of three resources: time, scope, or money. If you do not name the trade, the project spends the resource silently. Usually, it spends your time first.

The helpful-person trap

Freelancers often want to be easy to work with. I understand that instinct. You want the client to feel that you are flexible, collaborative, and invested in the product.

So a client asks for a change, and you say, “Sure, I can add that.”

The sentence feels generous because it only describes the coding action. It does not describe the consequences.

The new button may require a new state. The new state may require a data-model change. The data-model change may touch existing screens. Those screens need testing. The test may reveal a permissions problem. The permissions fix may change the demo. The demo may expose another expectation.

By the time the feature is visible, “one small thing” has become a chain of decisions.

AI coding tools make this trap more dangerous because they can produce the first version of a change so quickly. The speed is real, but it can hide the surface area. A generated screen is not the same thing as a completed feature. The feature still has to fit the product, the data, the permissions, the existing user journey, and the promised timeline.

That is why I now try to pause before accepting the implementation itself.

The first response to a new request should not be “I will code it.” It should be “Let us understand what changes if we include it.”

If you want a practical place to learn this kind of project-control habit, I made AI App Builder Starter Prompts, a free pack for turning a rough app idea into a scoped first build with AI:

https://marcusykim.gumroad.com/l/ai-app-builder-starter-prompts

The three-way trade

When a new request arrives, put it through a simple three-way trade:

Keep the original date, and remove or delay something else.
Keep the original scope, and move the date.
Keep the original date and scope, and add budget or people.

There is no secret fourth option where the project receives more work without paying for it somewhere. Sometimes the cost is hidden because the freelancer absorbs it. Sometimes the cost appears later as rushed QA, a missed milestone, a tired developer, or a client who no longer trusts the schedule.

Naming the trade makes the conversation less personal. You are not rejecting the idea. You are showing the project its actual accounting.

For a small freelance app, the conversation can be as plain as:

That feature makes sense. It touches the event flow and the data behind it, so I see three safe options: add it and move the next milestone, add it and remove another item from this milestone, or treat it as a new piece of work after the current milestone. Which trade do you want to make?

This is not bureaucracy. It is a way to stop a project from making an accidental promise.

What to inspect before you say yes

Before I accept a new feature, I want an impact scan. It does not need to be a forty-page technical investigation. It needs to expose the places where “small” can become expensive.

I look at six areas:

1. User outcome

What is the user trying to accomplish now?

If the request does not create a clearer user outcome, it may be decoration, a preference, or a future idea rather than a current requirement.

Ask:

Who uses this?
What can they do after the change that they cannot do now?
Is that outcome part of the current promise?

2. Existing workflow

Which current path changes?

A new control placed on a screen may alter the order of actions, empty states, loading states, error states, or navigation. A request can be small in code and large in behavior.

Ask:

Does this create a new step?
Does it change what “done” looks like?
What happens when the user cancels, retries, or has no data?

3. Data and ownership

Does the feature need new information to be stored, shared, or associated with a person?

This is where many beginner projects discover that a screen is only the visible part of the request. If the data does not persist, belong to the right user, or survive the next session, the feature is not finished.

Ask:

What data is created or changed?
Who owns it?
Who can see or edit it?
Does the existing schema support it?

4. Integrations and permissions

Does the feature involve notifications, location, payments, email, an outside API, or a new account boundary?

Each integration adds a contract and a failure path. The happy-path demo is the cheapest part.

Ask:

What external service or permission is required?
What happens when the user denies access?
What happens when the provider is unavailable?

5. Proof

How will we know the feature works?

I want the proof named before the feature is treated as complete. That might be a user completing a workflow, data surviving a restart, two accounts seeing the correct boundaries, or a failed request producing a useful recovery state.

Ask:

What will I demonstrate?
What will I test with bad input or missing data?
What existing behavior could this accidentally break?

6. Schedule and trade

What does the request displace?

This is the area people skip because it feels commercial. But schedule is part of the product promise. If the new request takes two days, those two days have to come from somewhere.

Ask:

Does the milestone move?
Does another feature move out?
Does this become a separately priced change?

A better change-request note

For a new request, I would write a short note with these fields:

Requested change:

User outcome:

Existing workflow affected:

Data, permissions, or integrations affected:

New QA proof:

Estimated effort and risk:

Trade chosen: date, scope, or money:

Next decision:

The point is not to create paperwork for its own sake. The point is to make the invisible parts visible while the request is still easy to discuss.

This note also gives an AI coding tool something better than “add this feature.” You can ask the tool to inspect the repository against the change-request note, list the affected files and contracts, identify unknowns, and wait for approval before editing.

The prompt I would use is roughly:

Before changing code, analyze this requested feature against the current project.

Return:
1. The user outcome.
2. Existing workflows and data affected.
3. New permissions or integrations required.
4. Failure and empty states.
5. QA proof needed.
6. The smallest implementation that meets the outcome.
7. What the feature may displace in the current milestone.

Do not edit files until I approve the impact scan and the schedule trade.

That last sentence matters. If the AI starts coding while the request is still being negotiated, the project can become emotionally committed to a solution before anyone has agreed on the cost.

The free starter prompts are useful for this pause because they turn a vague request into a sequence of questions: what is the outcome, what belongs in version one, what does the tool need to know, and how will you verify the result? You can find that free pack here:

https://marcusykim.gumroad.com/l/ai-app-builder-starter-prompts

Scope control is part of client service

There is a fear that talking about scope makes you seem difficult. In my experience, the opposite is often true when the conversation is calm and specific.

Clients usually do not need a freelancer to say yes to every idea. They need someone to help them understand what the idea means. A useful freelancer can say:

“Yes, here is what it would take.”
“Not in this milestone, but here is where it fits.”
“We can add it if we remove this other item.”
“I do not know yet; I need to inspect the data and workflow first.”

That is not resistance. It is professional translation.

The same principle applies when you are building your own app. You are both the client and the freelancer, which means you can give yourself unlimited requests and then blame the project for taking forever.

Do not do that.

Keep a change log. When a new idea appears, record it, classify it as now, next, or later, and write down what it would cost. You are not killing creativity. You are giving creativity a place to wait without hijacking the current build.

What I would do differently now

On my first major freelance project, I learned that technical effort and project agreement are separate problems.

I can ask Codex to help implement a change. That does not mean the change belongs in the current milestone. I can make a screen look convincing. That does not mean the user workflow, data, permissions, and QA are finished. I can be excited about a feature. That does not mean the original deadline should remain unchanged.

The better sequence is:

Translate the request into a user outcome.
Scan the workflow, data, permissions, integrations, and QA impact.
Name the smallest useful version.
Choose the trade: time, scope, or money.
Update the milestone or change log.
Then ask AI to implement the approved slice.

The order protects both sides of the relationship. The client gets an honest decision. The freelancer gets a project that can still be finished. The AI gets a bounded job instead of a moving target.

I made a free AI App Builder Starter Prompts pack for beginners who want help turning app ideas and build requests into clearer conversations with AI:

https://marcusykim.gumroad.com/l/ai-app-builder-starter-prompts

If the starter prompts are useful and you want the deeper field manual, AI App Builder From Zero walks through idea, scope, stack, prompting, QA, deployment, and launch:

https://marcusykim.gumroad.com/l/ai-app-builder-from-zero

My rule now is simple: a new feature can be a good idea and still be the wrong thing to build next.

Before you say yes, make the project name the trade.

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/

A Beginner's Guide To APIs And Integrations In AI-Built Apps In 2026

Marcus Kim — Sat, 18 Jul 2026 18:47:31 +0000

The fastest way to make your first AI-built app confusing is to say:

Add an API.

That sentence sounds like a feature request. It is actually a small pile of unanswered questions wearing a trench coat.

Which API?

What information goes into it?

What comes back?

Who is allowed to call it?

What happens when the service is slow, unavailable, or returns an error?

Does each request cost money?

Where do the credentials live?

How will you know the integration worked instead of merely producing a pretty loading state?

I have watched AI coding tools move quickly when the target is clear. I have also watched them turn a vague integration request into a small haunted house: a button, a spinner, a secret key in the wrong place, a response nobody understands, and a fallback that says “Something went wrong” forever.

The useful beginner lesson is simple:

An integration is not a button you add to an app. It is a contract between your app and another system.

If you can describe the contract, AI can help you implement it. If you cannot describe the contract, AI will fill in the blanks, and it will do so with the confidence of a person who has never met your product but has already rearranged your kitchen.

Start With The Ingredient, Not The Feature

The easiest analogy I know is cooking.

Your app is the meal. An API is an ingredient or an outside kitchen you are asking to do one job for you.

You need to know what the ingredient is, how much you need, how it should be prepared, what it tastes like when it is missing, and whether it is safe for the person eating the meal.

“Use an API” is like telling a beginner cook, “Add a mysterious liquid.” That may technically move the recipe forward, but it does not create a dependable dinner.

Before you ask AI to connect anything, write one sentence in this format:

When [user] does [action], my app sends [specific input] to [outside service] so it can return [specific output], which my app uses to [user outcome].

For example:

When a musician saves a rough recording, my app sends the audio file and optional tempo note to the transcription service so it can return a timestamped text draft, which my app uses to make the idea searchable.

That sentence is already better than “Add transcription.” It gives you a user, an action, an input, an outside capability, an output, and a reason the integration exists.

Before going further, I made AI App Builder Starter Prompts, a free pack that helps you turn a rough app idea into a conversation about scope, screens, data, debugging, QA, deployment, and launch. It is useful here because the blank prompt should not be where you first discover that your integration has no defined input or finish line.

The Seven Parts Of An Integration Contract

When I am deciding whether an AI-built app is ready to depend on an outside service, I want seven answers.

1. The input

What exactly does your app send?

Do not stop at “the user's data.” Name the data.

It might be:

a search phrase;
an image file;
an audio recording;
a location and radius;
a payment amount and currency;
a list of calendar events;
a text prompt and a selected language; or
a record ID your own database already owns.

Input details matter because APIs are literal. A person may understand that a “photo” is a photo. The service may require a file type, size limit, encoding, or URL it can actually reach.

Ask AI to list the exact input fields, their types, required versus optional status, size limits, and examples of valid and invalid values.

2. The output

What comes back, and what does your app do with it?

An API response is not automatically a screen. It may contain a result, an ID, a status, warnings, pagination, usage information, or several possible error shapes.

If the service returns a generated image, your app may need to save a URL, download a file, show a preview, and give the user a way to retry. If it returns a delivery status, your app may need to show “queued,” “sent,” “failed,” and “unknown” instead of pretending every response is success.

Write the smallest useful output your first version needs. Do not ask AI to expose every field merely because the service returned it.

3. Permission and secrets

Which part of the app is allowed to call the service, and where do the credentials live?

This is related to authentication, but it is not the same lesson as the account boundary in your app. Here the question is whether your app is allowed to use another system, and whether a secret key is being protected from the people using your app.

Never treat a private API key like a normal display value. A key placed in a public client bundle may be copied. A key pasted into a visible prompt or committed to a repository may travel farther than you intended.

Ask AI to explain:

whether the call belongs on the client, server, or a controlled backend function;
which credential is required;
which permissions that credential has;
how the key is stored in development and production; and
how the key can be revoked or rotated.

If you cannot explain where the secret lives, you are not ready to ship the integration.

4. Failure states

What happens when the outside service does not cooperate?

This is where many AI-generated demos become theater. The happy path works once, the button looks impressive, and the first timeout turns the whole feature into a shrug.

List the failures before you build:

the user is offline;
the request times out;
the service returns a validation error;
the service rate-limits you;
the credential is missing or expired;
the response is empty or malformed;
the request succeeds but your app fails to save the result; or
the service succeeds twice because the user tapped the button twice.

Your user does not need a lecture about HTTP status codes. They do need an honest next action: correct the input, retry, wait, contact support, or continue without the integration.

5. Cost and limits

What does one request cost, and how often can a user make it?

Some services are free only within a small quota. Some charge per request, per image, per minute of audio, per token, or per stored item. Some limit concurrent requests. Some become expensive precisely when your feature starts working.

For a first app, write down:

the unit you are charged for;
the free or included limit;
the expected cost of one normal user action;
the behavior when the quota is reached; and
whether a user can accidentally trigger duplicate requests.

This is not financial modeling. It is basic product safety. A button that can create an uncontrolled bill is not finished just because the API response renders.

6. Ownership and storage

Where does the result belong after the request finishes?

Does the response only live on screen? Does it belong to the signed-in user? Does it need to be associated with an existing project, recording, order, or message? Can it be deleted? Can it be regenerated without charging the user twice?

Your backend article may have helped you decide whether your app needs persistence. The integration question is narrower: if this outside service returns something valuable, how does your app connect that result to the user workflow?

For every returned item, name:

the record that owns it;
the place it is stored;
the identifier that ties it to the request;
the retention or deletion behavior; and
what the user sees after leaving and returning to the app.

If the result matters tomorrow, do not leave it trapped in today's screen state.

7. Proof

How will you prove the integration works?

Do not use “the API call returned 200” as the whole test. A technically successful request can still create a broken user experience.

Test the complete path:

Start with a known valid input.
Confirm the request leaves your app with the expected fields.
Confirm the service response is parsed into the expected result.
Confirm the result appears where the user needs it.
Refresh or relaunch and check whether the result still exists when it should.
Test an invalid input.
Test a timeout, offline state, or simulated service failure.
Tap twice and check for duplicate work or duplicate charges.
Confirm secrets are not visible in the client or logs.

The integration is not done when the API answers. It is done when the user's promised outcome survives the full path and the failure paths are understandable.

A Prompt I Would Give AI Before Adding An Integration

I would not start with:

Add Stripe.

That names a tool, not a product behavior.

I would give AI something closer to this:

I am adding one integration to a beginner app.

User outcome:
[what the user should be able to accomplish]

Trigger:
[the exact user action]

Outside service:
[service name and the capability we need]

Input contract:
[required fields, optional fields, file types, limits, and examples]

Output contract:
[the smallest result my app needs and where it should appear]

Permissions and secrets:
[who can call it, where the credential must live, and what must never be exposed]

Failure behavior:
[offline, timeout, invalid input, rate limit, expired credential, malformed response, duplicate tap]

Cost and limits:
[what one request costs, quota, and what happens when the limit is reached]

Ownership and storage:
[which user/project record owns the result and whether it must survive relaunch]

QA proof:
[the happy path plus the failure cases I will test]

Before changing code, explain the smallest safe architecture, list the files or services that need to change, identify assumptions, and propose a test plan. Do not add a second provider, background job, analytics system, or abstraction layer unless the user outcome requires it.

The last sentence is important. AI likes to be helpful by building an airport when you asked for a bicycle rack. An integration contract gives it a runway length.

A Beginner Integration Checklist

Save this checklist somewhere your project and AI tool can both see it:

[ ] I can name the user outcome, not just the service name.
[ ] I know the exact trigger that starts the request.
[ ] I listed the input fields and invalid-input cases.
[ ] I listed the smallest useful output.
[ ] I know where the call runs and where secrets live.
[ ] I know which users or roles can trigger it.
[ ] I named offline, timeout, rate-limit, credential, and malformed-response behavior.
[ ] I know the cost, quota, and duplicate-request risk.
[ ] I know who owns the result and whether it survives relaunch.
[ ] I have a test that proves the user outcome, not only a successful API response.
[ ] I know what the user can do when the service fails.

If you cannot check the boxes, do not let the integration expand into five more features. Narrow the first version until you can explain the complete path.

The free AI App Builder Starter Prompts are a practical next step if you want guided prompts for this kind of scoping, architecture, build, debugging, QA, and launch work. The starter prompts are free, and you can use them with your AI coding tool while the project is open.

The Operating Rule

When AI suggests an API or integration, do not ask only, “Can you add it?”

Ask:

What enters the system, what leaves it, who is allowed to trigger it, what can fail, what can it cost, where does the result belong, and how will I prove the user outcome?

That question turns an integration from a shiny feature into a piece of software you can reason about.

I learned this kind of discipline through software engineering study, startup iOS work, and freelance app development. The tool can write a surprising amount of code. It cannot decide what your product promises, what tradeoff you can afford, or what failure your user can tolerate unless you give it those decisions.

If you want the deeper build-along field manual behind the free prompts, AI App Builder From Zero walks through idea generation, scope, stack choice, project rules, prompting, architecture, QA, deployment, and launch.

The practical takeaway is this:

An API is not a shortcut around product thinking. It is a new relationship your app now has to manage.

Name the input. Name the output. Protect the permission. Plan the failure. Count the cost. Connect the result to the user's workflow. Test the promise.

Then let AI help you build the boring, dependable version.

For first-time builders, boring and dependable is a much better feature than impressive and haunted.

I made AI App Builder Starter Prompts, a free pack for turning a rough app idea into a scoped AI-assisted build with practical prompts for planning, architecture, debugging, QA, deployment, and launch.

If you want the full build-along field manual behind the free prompts, AI App Builder From Zero is the deeper next step.

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/

Authentication Is Not Just A Login Screen: A Beginner's Guide To Account Boundaries In AI-Built Apps In 2026

Marcus Kim — Sat, 18 Jul 2026 01:55:53 +0000

The login screen is one of the most convincing fake signs of progress in a beginner app.

It has the right fields.

It has a button that says Sign In.

It may even show a friendly little spinner before landing you on a dashboard with three sample records and a profile avatar that appears to know what it is doing.

That does not prove your app has authentication.

It proves that your app has a front door.

Authentication starts with a harder question:

Who is this person, what are they allowed to do, and how does the app keep that boundary true after the screen changes?

That distinction matters even more when you are building with AI. If you ask an AI coding tool to “add login,” it may create a polished form while leaving the actual ownership and permission rules vague. The interface looks finished because the visible part is finished.

The invisible part is where trust lives.

If you are at the stage where you need help turning a rough app idea into a controlled first build, I made the free AI App Builder Starter Prompts pack for beginners:

https://marcusykim.gumroad.com/l/ai-app-builder-starter-prompts

The prompts help you make the project more explicit before your coding tool starts filling in the blanks.

Think Of Authentication As A Bouncer

The simplest analogy I use is a bouncer at a venue.

The bouncer answers a few different questions:

Is this person known to the venue?
Did they prove who they are?
Are they allowed inside this area?
Are they allowed to do what they are trying to do?
What happens if their pass expires or they leave?

Those are not one question. They are several jobs that beginners often blend together under the word “login.”

Your app needs the same separation.

Authentication asks, “Who are you?”

Authorization asks, “What are you allowed to see or change?”

Session management asks, “How does the app remember that you already proved who you are?”

Account recovery asks, “What happens when you forget your password, lose access, or need to sign out everywhere?”

The login screen is only one small part of that system.

Write The Account Contract Before You Ask AI To Code

Before I let AI build account features, I write a short contract in plain English.

It does not need to sound like a security textbook. It needs to remove the guesses that cause the most damage.

For a simple private notes app, the contract might say:

Each account has a unique user ID.

Each note belongs to exactly one user.

A signed-in user can create, read, edit, and delete only their own notes.

A logged-out visitor cannot read private notes or reach private screens.

Refreshing the page must not change ownership.

Signing out must remove access from the current session.

Password recovery must not reveal whether an unrelated email address has an account.

That is already more useful than “add secure authentication.”

The contract gives you something to inspect. It gives AI a set of behaviors to implement. It gives QA a set of claims to challenge.

It also gives you a way to notice when the app has a beautiful login screen but no real account boundary behind it.

Identity Is Not Ownership

A common beginner mistake is assuming that because the app knows who you are, it knows what belongs to you.

Those are related, but they are not identical.

Imagine a user called Marcus signs in successfully. The app can display “Welcome, Marcus,” but that does not automatically mean every database query is limited to Marcus's records.

The data layer still needs an ownership rule.

For every private record, ask:

Which user owns this record?
Where is that owner ID stored?
Does the create operation assign the owner from the authenticated session, or trust an ID supplied by the client?
Does every read filter by the current user?
Does every edit check ownership before changing anything?
Does every delete check ownership before removing anything?

This is the part I want a beginner to understand: a user ID in a screen, hidden field, or request body is not proof of identity. The app should derive sensitive ownership from the authenticated session and enforce it where the data is actually protected.

Otherwise, a curious user may be able to replace one ID with another and ask for somebody else's records. The UI may never show a button for that. The boundary can still be missing.

Make The Permission Table Boring

You do not need a complicated role system for your first app. You do need a clear permission table.

Start with the smallest roles your product genuinely needs.

Resource	Logged out	Signed-in owner	Other signed-in user	Admin, if truly needed
Private note	No access	Create, read, edit, delete	No access	Only if the product requires support access
Public profile	Read only if designed as public	Edit own profile	Read public fields only	Edit only for a defined operational reason
Event	Read only if public	RSVP or manage if owner	RSVP according to the product rule	Moderate only if the role exists

The table makes vague requests uncomfortable, which is useful.

“Users can manage events” is too fuzzy.

Can any user edit any event? Can only the host edit it? Can attendees change the time? Can a deleted account leave the event without an owner? Does the event become public after a share link is copied?

You do not have to solve every future question on day one. You do have to decide which questions version one is actually promising to answer.

The Four Authentication States I Would Test First

AI-generated account flows often get tested only in the happiest possible state: one developer account, one browser, one successful login.

That is not enough.

I would test at least these four states.

1. Logged Out

Open the app in a fresh session.

Try to visit a private URL directly.

Try to call the action that creates or edits private data.

The app should either send you to the right entry point or return a clear, safe response. It should not briefly render private content and hide it later like a stage magician who forgot the trick.

2. Signed In As Account A

Create a record and confirm it belongs to Account A.

Refresh the app. Leave and return. Sign out and sign back in.

The record should still be there for Account A if persistence is part of the promise. The app should not silently switch the record to a default user or a shared test account.

3. Signed In As Account B

Use a genuinely separate account, not a second tab pretending to be a different person.

Try to find, edit, or delete Account A's private record.

The expected result is not merely “the button is hidden.” The server-side or data-layer rule should reject unauthorized access too.

4. Expired Or Removed Access

Sign out, expire the session if your platform supports that test, or remove a user's access according to the product's rules.

Then try the old page, an old tab, and a direct request.

This catches the difference between a UI that changed state and an actual permission boundary that still holds.

Password Recovery Is Part Of The Product

Beginners often treat password recovery as a later polish item because the login screen is more visible.

But recovery is where your app explains what it believes about identity.

At minimum, decide:

Does the user recover with email, a social login, a magic link, or another method?
Does the recovery message avoid exposing whether an email exists?
What happens when the link is expired or already used?
Can the user set a new password without being logged in?
Are existing sessions kept, revoked, or reviewed after a password change?
Where can the user sign out of the current device?

You do not need to build every enterprise account feature for version one. You need a recovery path that matches the promise you are making to a real user.

If a person can lose access to their work with no clear way back in, that is not a minor missing button. It is a gap in the product's trust model.

Do Not Let AI Invent A Security Shortcut

When an AI tool is trying to get a prototype working, it may suggest shortcuts that are acceptable only in a tightly controlled local demo.

Examples include:

storing a password in plain text
using one shared test account for every user
trusting a user ID sent from the browser
making every record readable during development
disabling rules because they make a test fail
putting secret keys in client-side code
treating a hidden button as the permission system

If the tool suggests one of these, stop and ask it to explain the risk before accepting the change.

Here is the prompt I would use:

I am building [app] for [user]. Define the authentication and authorization contract before changing code.

List:
1. the identity source and session behavior
2. each private resource and its owner
3. who can read, create, edit, and delete each resource
4. what logged-out users can access
5. password recovery and sign-out behavior
6. the data-layer rules that enforce ownership
7. tests for Account A, Account B, logged-out access, refresh, and expired access

Do not use hidden UI buttons, client-supplied ownership IDs, shared passwords, or broad public read/write rules as shortcuts. Explain the smallest safe implementation for version one before writing code.

That prompt is useful because it makes the AI describe the boundary before it starts moving files around.

The free AI App Builder Starter Prompts pack includes practical prompts for planning, architecture, debugging, QA, and launch. It is free, and it is meant to help you turn the blank prompt box into a controlled build conversation:

https://marcusykim.gumroad.com/l/ai-app-builder-starter-prompts

My Beginner Definition Of Done For Authentication

I would not call the account system done when a test user can sign in.

I would call it ready for a first release when:

a new user can create an account or use the chosen sign-in method;
the app can tell the difference between logged-out and signed-in states;
private records have an explicit owner;
the owner can complete the promised create, read, edit, and delete actions;
another account cannot cross that boundary;
direct private URLs and requests are protected, not just hidden in the UI;
refresh, sign-out, and the promised recovery path behave predictably; and
the AI-generated implementation has been tested with more than one account.

That is a small definition. It is still a real one.

When I managed iOS work at a startup, shared rules around schemas, feature ownership, and team communication mattered because one person's shortcut could create work for everybody else. Authentication has the same shape in a beginner app: an unclear rule at the boundary becomes a confusing problem everywhere else.

The goal is not to build a bank on your first weekend.

The goal is to make the promise of your app match the access rules behind it.

The Practical Takeaway

Before you ask AI to build login, write down:

who the users are;
what proves identity;
what data belongs to each user;
which actions each role can perform;
what logged-out users can see;
what recovery and sign-out mean; and
how you will prove the boundary with two separate accounts.

Then ask AI to explain the contract, propose the smallest safe implementation, and give you a test plan before it writes the code.

That is how you keep a login screen from becoming a costume for a missing security model.

If you want the practical starting point, the free AI App Builder Starter Prompts are here:

https://marcusykim.gumroad.com/l/ai-app-builder-starter-prompts

If you want the full build-along field manual behind the free prompts, AI App Builder From Zero walks through idea, scope, stack, architecture, prompting, QA, deployment, and launch:

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/

How I Use Client Demos To Manage Freelance App Projects In 2026

Marcus Kim — Mon, 13 Jul 2026 18:54:18 +0000

A software project can look extremely busy while delivering almost nothing a client can use.

Files changed. Components added. Bugs moved from one corner of the app to another corner where they can enjoy a little vacation. The task board glows with activity.

Then the client asks a painfully reasonable question:

What can I do now that I could not do before?

If the answer takes ten minutes, three diagrams, and a guided tour of the codebase, the project probably does not have a communication problem.

It has a delivery problem.

One of the most useful lessons from my freelance app work is that the demo can act like the project manager. I do not mean that a screen share replaces scope, milestones, QA, or human judgment. I mean that the next honest demonstration can organize all of them around something real.

My rule is simple:

Every meaningful client update should show one new outcome a real user can complete.

Not one new screen.

Not one impressive technical system.

One outcome.

That rule gives you a practical way to choose what to build, decide what to postpone, ask for useful feedback, and keep AI-generated activity from masquerading as progress.

A Status Report Can Hide An Unfinished App

Traditional progress updates often describe motion:

Added authentication
Connected the database
Built the profile screen
Fixed navigation
Started notifications

Those lines are not useless. They are just incomplete.

Authentication might exist while account recovery fails. A database might be connected while saved data disappears after refresh. A profile screen might look finished while the Save button does nothing. Navigation might work only on the exact path the developer happened to click.

A demo forces a stronger sentence:

A new user can create an account, finish their profile, close the app, sign back in, and still see the information they saved.

Now the project has a visible claim.

You can run it. The client can inspect it. QA can attack it. If it breaks, everybody knows what “it” is.

That is why I like demo-shaped work. It turns progress from a pile of technical nouns into a user verb.

If you are still trying to turn a rough app idea into the first user outcome worth demonstrating, I made AI App Builder Starter Prompts, a free prompt pack for scoping and planning a first website or mobile app with AI:

https://marcusykim.gumroad.com/l/ai-app-builder-starter-prompts

Use the free prompts to clarify the person, workflow, boundaries, data, and first milestone. Then make that first milestone demoable.

Define The Next Demo Before You Choose The Next Task

The easiest way to let a project drift is to open the backlog and ask, “What should I work on today?”

That question invites task shopping. You pick the ticket that looks interesting, easy, or technically satisfying. Three days later, the project contains five partial features and no complete story.

I prefer a different question:

At the next client update, what should one user be able to accomplish from start to finish?

Write the answer before you choose the tasks.

For example:

At the next demo, an event organizer can create an event, publish it, share the link, and see one test attendee RSVP.

That sentence tells you what matters now. The event form matters. Saving the event matters. The public link matters. The RSVP matters. The organizer seeing the new RSVP matters.

A custom avatar editor does not matter yet.

Neither does a twelve-color notification preference center that AI helpfully proposed because it got excited.

The demo outcome becomes a temporary filter. Every task either helps prove the outcome or waits.

My Six-Part Demo Contract

Before I build toward a client update, I like to define a small demo contract.

It has six parts.

1. The User

Name the person completing the workflow.

“A user” is weak. “A first-time event organizer” is better. “A returning musician looking for a saved recording” is better. The more clearly you can picture the person, the easier it is to notice missing steps.

2. The Starting State

Say what must already be true before the demo begins.

Does the test account already exist? Is the app freshly installed? Is there seed data? Are permissions already granted? A demo can look magical when the starting state quietly did half the work.

Write it down.

3. The User Action

Describe the exact path in verbs.

Open the app. Sign in. Create the event. Add the date. Publish it. Copy the link. Open the attendee view. RSVP. Return to the organizer view.

This is the center of the demonstration.

4. The Proof

Name what proves the outcome survived the interface.

Refresh the page. Relaunch the app. Open a second account. Check the saved record. Confirm the correct person can see it and the wrong person cannot.

Pretty motion is not proof. Persistence, permissions, and the expected result are proof.

5. The Known Gap

Say what does not work yet.

Maybe event editing is not included. Maybe email reminders are still fake. Maybe the Android layout needs another pass. A known gap is not an embarrassment. It is a boundary that keeps the client from mistaking a controlled demonstration for a complete release.

6. The Decision

End with the question the demo should help answer.

Should this workflow move into QA? Does the client approve the interaction? Does a requested change replace the next milestone, add time, or wait for version two?

A demo without a decision can become software theater. Everyone watches, says “nice,” and leaves with different assumptions.

The Demo Is Not The Same As QA

This distinction matters.

A demo proves that a chosen workflow is concrete enough for a client or stakeholder to evaluate. QA tries to break that workflow across inputs, states, accounts, devices, permissions, networks, and regressions.

The demo is the shared truth surface.

QA is the attack on that truth.

You need both.

I do not want a client meeting to become the first time I discover that the happy path fails. The workflow should be rehearsed and checked before the call. But I also do not want to hide behind internal QA forever while the client imagines a different product.

The sequence I trust is:

Define the demo outcome.
Build the complete path.
Run a focused QA pass.
Demonstrate the result honestly.
Record the decision and next outcome.

That loop is small enough for a freelancer and strong enough for a team.

Demos Make Scope Changes Visible

Scope creep is slippery when it arrives as a sentence.

“Could we also let attendees message each other?” sounds small in a meeting. Then it touches accounts, permissions, conversations, moderation, notifications, unread states, blocking, data retention, UI, and QA.

The demo gives you a calmer way to respond.

Do not argue about whether the idea is “easy.” Turn it into a delivery choice:

Swap: Replace part of the current demo outcome with the new request.
Add: Keep the current outcome and extend the milestone, price, or timeline.
Park: Save the request for a later demo after the contracted workflow works.

Now the conversation is not developer versus client. It is one visible outcome versus another visible outcome.

The client can still choose the new feature. The project simply stops pretending the choice has no cost.

AI Should Prepare Evidence, Not A Victory Speech

AI coding tools are very good at producing confident summaries of what they changed.

That is useful until the summary starts describing intention as completion.

“Implemented the event flow” might mean the files exist. It does not necessarily mean a user can finish the flow, the data persists, permissions are correct, and the build survives a relaunch.

So I ask AI to prepare a demo brief with evidence.

Here is a prompt shape I would use:

We are preparing the next client demo for this user outcome: [OUTCOME]. Inspect the current project and produce a demo brief. Include the required starting state, exact user steps, expected result after each step, persistence or permission proof, known gaps, regression checks, and the client decision this demo should support. Do not claim a step works unless you can point to verification evidence. List anything that still needs manual testing before the meeting.

Then I run the path myself.

The AI can help assemble the checklist. It cannot attend the meeting wearing a tiny suit and magically make an untested workflow true.

If you want more starting points for shaping outcomes, milestones, QA, and deployment conversations with your AI tool, the AI App Builder Starter Prompts are free:

https://marcusykim.gumroad.com/l/ai-app-builder-starter-prompts

The Client Update I Would Send

You do not need a huge report before every demo. You need enough context for the client to understand what changed and what to evaluate.

I would use this structure:

Outcome now working: [One sentence describing what a user can complete.]

Build or link: [Where the client can try it.]

Please test: [Three to five exact steps.]

Known gap: [What is deliberately incomplete.]

Decision needed: [The feedback or approval required.]

Proposed next demo: [The next user outcome.]

That update is useful even if the meeting moves. It gives the client a testable object instead of asking them to interpret a week of developer activity.

It also keeps communication sparse without making it mysterious. I do not believe clients need constant noise. They need meaningful change, visible proof, and a clear place to make decisions.

What A Bad Demo Looks Like

A bad demo usually hides uncertainty instead of resolving it.

Watch for these patterns:

A tour of screens with no complete user journey
Slides describing features that cannot be run
A workflow that only works with one carefully prepared record
A save action that is never checked after refresh or relaunch
A long explanation of code changes before the user outcome is shown
Live improvisation on an untested branch
Known gaps revealed only after the client discovers them
A meeting that ends without an approval, rejection, tradeoff, or next outcome

The goal is not to make every demonstration flawless.

The goal is to make the state of the project difficult to misunderstand.

Let The Next Demo Pull The Project Forward

The demo is not the entire project-management system.

It is the heartbeat.

Your scope says what you agreed to build. Your backlog records the work. Your project rules protect the codebase. Your QA process tests the result. The demo keeps all of those systems attached to a visible user outcome and a real client decision.

That is the operating rule I would give any freelancer building software with AI:

Do not manage the project by asking how much changed.

Manage it by asking what can be honestly demonstrated next.

One person.

One complete outcome.

One known gap.

One decision.

Then let that decision shape the next demo.

If you want a practical way to define that first outcome, I made AI App Builder Starter Prompts, a free pack with planning, build, debugging, QA, deployment, and launch prompts for first-time builders:

https://marcusykim.gumroad.com/l/ai-app-builder-starter-prompts

If you want the full build-along field manual behind the free prompts, AI App Builder From Zero walks through idea generation, scope, stack choice, project rules, prompting, QA, deployment, App Store, Google Play, and launch:

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/

The First Backend I Would Choose For A Beginner AI-Built App In 2026

Marcus Kim — Sat, 11 Jul 2026 23:57:29 +0000

One of the first ways a beginner AI-built app gets complicated is when the AI starts listing services before the app has earned them.

Authentication. Database. Storage. Analytics. Push notifications. Payments. Webhooks. A queue. Three environments. A helpful robot will happily hand you a whole grocery cart of infrastructure for an app that has not yet successfully saved one note.

That does not mean the tools are bad. It means the order is upside down.

Before you choose a backend, ask a smaller question:

What information must still exist after the user closes the app, and who needs to be able to see it?

If the answer is "nothing yet," you may not need a backend for version one. If the answer is "a signed-in user needs their data to persist," you need a simple backend. If the answer is "users need to interact with one another," you need a backend and a deliberately designed data model.

That is the decision tree. It is not glamorous, but it will save you from building a tiny data center for a calculator.

If you want help turning your rough idea into a scoped first build before choosing tools, my free AI App Builder Starter Prompts are here:

https://marcusykim.gumroad.com/l/ai-app-builder-starter-prompts

Start With The App's Memory

I think about a backend as the part of your app that remembers things after the screen changes, the app closes, or another person opens it.

A simple song-idea recorder might need a backend if you want recordings, titles, tags, and project notes to follow a musician across devices. A local-only first prototype might not need it if the goal is simply proving that recording, playback, and export feel good on one phone.

A social app needs a backend much earlier. A post has an author. An event has attendees. A message belongs in a conversation. Those facts have relationships, and the relationships are part of the product.

This is why I do not start by asking, "Should I use Firebase or Supabase?" I start by writing down the facts the app must remember.

For a first version, that list should be boringly specific:

A user has a name, email, and account ID.
A song idea has an owner, title, audio-file location, created date, and optional tags.
An event has a host, time, location, description, and RSVP list.
A message has a sender, conversation, text, and sent date.

If you cannot name the facts, you are not ready to choose the database. The AI can help you turn those facts into a schema, but you should decide what the facts mean first.

My Default: Pick One Managed Backend, Not A Pile Of Services

For a beginner building a real app with accounts and saved data, I would usually choose one managed backend that handles several jobs together.

My two most practical defaults are Firebase and Supabase.

Choose Firebase When You Want The Lowest-Friction Mobile Path

Firebase is often a good fit when you are building an iOS, Android, Flutter, or Expo app and want to move quickly with familiar mobile features in one place.

It can give you authentication, a database, file storage, server-side functions, analytics, crash reporting, and push-notification support without asking you to operate servers.

That is valuable when your product needs things like:

Sign in with email, Google, or Apple
A feed that updates quickly
Photos, recordings, or other uploaded files
Push notifications
Basic mobile analytics and crash visibility

The tradeoff is that Firebase asks you to learn its data model and security rules. Do not let AI create broad-open rules just to make a test work. "Anyone can read and write everything" is not a development shortcut. It is a product-security decision with a fake mustache.

Choose Supabase When Your App's Data Has Clear Relationships

Supabase is usually my first recommendation when the product naturally sounds like tables and relationships.

For example, a band-roster app might have users, bands, rehearsals, game-day events, availability responses, and messages. Those things relate to each other in predictable ways. A relational database gives you a clean way to model that truth.

Supabase provides a hosted Postgres database, authentication, storage, and server-side capabilities. It can work well with web apps, Expo, Flutter, native mobile apps, and modern TypeScript stacks.

The tradeoff is that you need to take your schema seriously. That is healthy. A clear schema forces you to decide what belongs to what before your app starts inventing relationships by accident.

When I was managing iOS work at a startup, we treated schema changes as team-wide decisions. Not because schemas are sacred tablets, but because a casual table change can break several user flows at once. Even when you are a team of one, keep that instinct: change the schema on purpose, document why, and ask AI to identify everything affected.

When You Should Use No Backend Yet

You can often delay a backend when version one is mostly about interaction quality.

Examples:

A metronome with a better recording flow
A habit timer
A calculator or converter
A one-device checklist
A UI prototype that proves a workflow before accounts exist

Local storage is enough when the data belongs to one person on one device and losing it would not destroy the promise of your first test.

That does not mean "never plan for a backend." It means do not force the first version to solve cross-device sync, account recovery, permissions, and cloud storage before you know whether the core interaction helps anyone.

You can tell your AI tool:

Plan this as a local-first version one. Keep the data layer isolated so I can migrate to Firebase or Supabase later, but do not add accounts, cloud sync, or server infrastructure until the core workflow is validated.

That is a useful instruction because it tells the tool both what to build and what not to build.

The Four Questions I Ask Before Letting AI Add A Service

When an AI recommends an integration, I ask it to answer these questions in plain English:

What user outcome does this service enable?
What breaks or becomes manual if I do not add it in version one?
What data does it receive or store?
What is the smallest reversible implementation?

If the answer is vague, the service belongs in the parking lot.

For example, you do not add analytics because "apps need analytics." You add analytics when you need to answer a decision-making question, such as: "Do new users complete their first recording?" Then you track that one event and learn something real.

You do not add payments because a pricing page looks serious. You add payments once the product has a clear paid outcome and a hosted checkout can handle the first transaction safely.

This is the architecture lesson beginners often miss: every integration is a new responsibility. It may be a good responsibility. Just make it earn its seat.

A Practical First-Backend Prompt

Once you have named your users, version-one workflow, and data facts, give your AI tool a prompt like this:

I am building a [web app / iOS app / Android app / Expo app / Flutter app] for [specific user]. The first version must let them [one complete user outcome]. List the information that must persist, who can read or change each piece, and whether version one needs a backend at all. If it does, compare Firebase and Supabase for this exact app. Recommend one managed backend, explain the tradeoffs in beginner-friendly language, propose the smallest schema, and identify what I should deliberately postpone. Do not add services unless they directly support the first user outcome.

Then read the recommendation like a product owner, not a passenger. Ask the AI to explain any table, permission, or service you do not understand. You are allowed to make it slow down.

The Goal Is Not A Perfect Stack

Your first backend does not need to be the forever backend.

You are trying to make a real person complete a useful outcome with data that behaves predictably. Pick the smallest managed foundation that supports that outcome. Write down what it remembers, who owns it, and what permissions exist. Keep the rest out until the app proves it deserves to grow.

If you want the fuller build-along system for idea, scope, stack choices, prompting, QA, deployment, and launch, AI App Builder From Zero is the 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/

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

Marcus Kim — Sat, 11 Jul 2026 23:50:35 +0000

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/

The Project Constitution I Would Write Before Letting AI Build My App In 2026

Marcus Kim — Mon, 06 Jul 2026 18:47:34 +0000

One of the most useful things I ever did on a software project looked boring from the outside.

I wrote down the rules.

Not inspirational principles.

Not a pitch-deck mission statement.

Actual working laws.

When I was helping build a startup iOS app, I managed two junior iOS developers under me. The project had enough moving parts to become messy quickly: reusable views, Firebase data, model structs, branches, pull requests, feature ownership, demos, communication habits, and all the little decisions that quietly turn into daily interruptions if nobody writes them down.

So I built a project constitution in Notion.

That sounds more dramatic than it felt at the time. It was not me standing on a desk with a powdered wig yelling about liberty and database schemas.

It was a living set of operating rules for how we were going to build.

And the surprising lesson was this:

Written rules can create autonomy.

Most beginners think rules slow a project down. Sometimes they do. Bad rules absolutely can become bureaucracy with better formatting.

But good rules do something different. They reduce the number of moments where everyone has to stop and ask, "What should I do here?"

That matters for a small software team.

It also matters when you are building with AI.

If you open Codex, Cursor, Claude, ChatGPT, or any AI coding tool and ask it to build before the project has operating laws, you are basically hiring a very fast teammate with no handbook. It may produce code. It may even produce a lot of code. But it will also make tiny local decisions that slowly reshape the project.

The point of a project constitution is not to predict every possible task.

The point is to define the shared laws so people, and AI tools, can make local decisions without constantly crashing into each other.

If you are still turning a rough app idea into something buildable, I made AI App Builder Starter Prompts, a free prompt pack for beginners who want to scope a first website or mobile app with AI before code starts changing:

https://marcusykim.gumroad.com/l/ai-app-builder-starter-prompts

This article is about one layer I would add before serious building starts: the constitution.

A Constitution Is Not A Plan

This is where I want to separate today's lesson from normal planning.

A build plan says:

"Here are the phases."

"Here are the features."

"Here is the MVP."

"Here are the user stories."

That is useful. I believe in that.

But a constitution answers a different question:

"How do we behave while building?"

That question is easy to ignore because it does not feel like progress. It does not create a screen. It does not ship a feature. It does not make the app look more real.

But it controls the quality of every decision after it.

In the startup iOS project, the constitution covered things like:

when a view should become reusable
when a schema change was allowed
how to notify the team before changing shared data structures
when to create a new model or struct
what a pull request needed to explain
how branches should be named
what commit messages were supposed to communicate
how much mess the linter was allowed to tolerate
when we should use WhatsApp versus Notion
how biweekly demos and retrospectives worked
who owned a feature
what "done" meant for a story

None of those are glamorous.

All of them prevent future confusion.

The most expensive project problems are often not the ones with obvious explosions. They are the little repeated ambiguities.

Should I make a new model for this?

Can I change this field name?

Should this view be reusable?

Where should I ask this question?

What does the PR need to say?

Is this feature done because the screen exists, or because the user can complete the workflow?

If nobody writes the answers down, every developer has to guess. If you are working alone with AI, the AI guesses. If you are working with a team, the team guesses in different directions.

That is how a codebase gets weird.

Not all at once.

One reasonable little exception at a time.

The Traffic Law Analogy

The best way I can explain this is traffic laws.

Traffic laws do not tell you where to go.

They do not pick your destination. They do not decide whether you are going to the grocery store, the beach, a client meeting, or the DMV because apparently society still needs a place where time goes to get processed by fluorescent lights.

Traffic laws define how everyone moves while pursuing their own destination.

Stay in your lane.

Stop at red lights.

Signal before turning.

Do not drive straight through someone else's car because you had a strong personal vision.

Those rules create freedom because everyone can make local decisions inside a shared system.

That was the point of the startup constitution.

Each developer had a destination: a feature, a user story, a definition of done.

They did not need me to micromanage every turn. They needed shared laws that kept their route compatible with everyone else's route.

That is the same reason a beginner building with AI needs project rules.

You do not want to prompt every tiny decision from scratch.

You want the AI to know:

what version one is allowed to become
what it should not add without asking
how it should treat data changes
when it should create abstractions
when it should avoid abstractions
what counts as done
how it should report uncertainty
what it must verify before claiming success

The constitution turns repeated judgment into reusable context.

That is the whole game.

The Mission Command Version

There is another useful analogy: Mission Command.

The simple version is this: leadership defines the what and the why, while the people closest to the work own the how within shared tactics and constraints.

I like that because it avoids two bad extremes.

One bad extreme is micromanagement.

Every decision has to go through the leader. Every question becomes an interruption. Every developer waits for permission. The project moves only as fast as the bottleneck person can answer messages.

The other bad extreme is chaos wearing a startup hoodie.

Everyone has "autonomy," but nobody shares the same rules. One person changes the schema casually. Another creates a new model for every small use case. Another builds a beautiful reusable component that nobody else understands. Another opens a pull request that explains nothing except "updates."

That is not autonomy.

That is distributed confusion.

The useful middle is:

Here is what we are trying to accomplish.

Here is why it matters.

Here are the laws we follow while doing it.

Now own your feature.

That is what I want from AI tools too.

I do not want to supervise every keystroke. That defeats the point of using a capable tool. But I also do not want the tool making silent architectural decisions because I forgot to define the rules.

AI is at its best when it has enough freedom to execute and enough constraint to stay inside the project.

That balance does not happen by accident.

You write it down.

The Sections I Would Put In A Beginner Project Constitution

If I were starting a new AI-assisted app today, I would write a short constitution before serious coding.

Not a 40-page document.

Not a corporate wiki that makes everyone wish software had stayed a hobby.

Something small enough to read and real enough to enforce.

Here are the sections I would include.

1. The Project Boundary

Start with what the project is and what it is not.

This is not the full roadmap. This is the legal fence around version one.

For example:

Version one helps one musician record a rough song idea, tag it, find it later, play it back, edit the name, and delete it.

Version one does not include collaboration, public profiles, AI mastering, subscriptions, teams, comments, social feeds, or cloud sharing unless I explicitly approve a scope change.

That kind of boundary matters because AI tools are helpful in the most dangerous way possible.

They are happy to add things.

If you do not tell the tool what the app is not, it may treat every plausible future feature like a current requirement.

Your constitution should make expansion a decision, not a default.

2. The Data Law

Data changes deserve special respect.

In the startup project, schema discipline mattered because shared data structures affected everyone. If someone changed a field, renamed a property, or altered an expected shape, the effects could ripple through multiple features.

That is why the constitution made schema changes visible.

For a team, that might mean:

Do not change the schema without notifying the team and getting buy-in.

For a solo AI-assisted build, that might mean:

Do not add, remove, or rename database tables, fields, model properties, storage paths, or API response shapes without first explaining why the change is necessary, what code it affects, and how we will migrate or test it.

That one rule can save you from a lot of mysterious breakage.

AI tools can be casual about data if you let them. They may add a field to solve one local problem without realizing they just changed the contract the rest of the app depends on.

The data law says:

Shared structure is not a scratchpad.

Treat it like infrastructure.

3. The Reuse Law

Beginners often swing between two mistakes.

One mistake is copy-pasting everything.

Every screen gets its own slightly different button, card, form, spacing pattern, and data formatter until the app becomes a museum of small inconsistencies.

The other mistake is abstracting too early.

Suddenly a simple screen has generic factories, clever helpers, and reusable components that look like they are preparing for a future product line nobody asked for.

So write the reuse law.

Something like:

Create reusable views and helpers when the same pattern appears at least twice and the shared behavior is stable. Do not create a new abstraction just because it feels professional. Do not copy a component three times without asking whether it should be shared.

That rule gives AI a better target.

It does not say "reuse everything."

It says "reuse when reuse reduces real duplication."

That distinction matters.

Good software is not code that looks clever.

Good software is code that stays understandable while the product changes.

4. The Model And Struct Law

In iOS work, model and struct discipline matters because these objects become the nouns of the system.

The same idea applies everywhere.

If AI creates a new type for every little situation, the project vocabulary bloats. If it refuses to create real models, the app becomes a pile of loose dictionaries, anonymous objects, and fragile assumptions.

A constitution can define the rule:

Create a new model, type, struct, interface, or schema object only when it represents a real concept in the app or protects a contract used in more than one place. Before adding one, explain what concept it represents and where it will be used.

This forces the tool to connect code structure to product meaning.

That is what beginners need.

Not more files.

More understandable files.

5. The Pull Request Law

Even if you are working alone, a pull request template is useful.

Why?

Because a PR template makes the work explain itself.

In the startup constitution, PRs needed to communicate the point of the change. Branch names and commit messages also had expectations. Not because naming branches correctly is a spiritual discipline, but because unclear version control becomes painful when people have to review, debug, or reconstruct what happened.

For a beginner using AI, the PR law can become a "change summary law."

Before calling a task done, the AI should answer:

what changed
why it changed
which files changed
what user behavior is now possible
what risk remains
what was tested
what was not tested

That is not busywork.

That is how you stop a fast tool from leaving you behind inside your own project.

It is also why a free prompt pack is useful at the beginning. The free AI App Builder Starter Prompts are meant to give you practical ways to make AI explain scope, rules, build steps, debugging, QA, and launch instead of just producing files:

https://marcusykim.gumroad.com/l/ai-app-builder-starter-prompts

The tool should not just change the code.

It should help you understand the change.

6. The Communication Law

On the startup project, communication rules mattered because interruptions have a cost.

If every uncertainty becomes a WhatsApp message, the lead becomes the team's notification center.

That does not scale, even on a tiny team.

So a constitution should define where different kinds of communication belong.

For example:

Use the project-management tool for feature status, blockers, decision records, and retrospective notes. Use direct chat only for urgent coordination, time-sensitive unblockers, or issues that cannot wait until the next check-in.

For AI-assisted solo work, the communication law looks different, but the principle is the same.

You can tell the AI:

Keep a running project log. When you make an important decision, record it. When you discover a blocker, summarize it. When you finish a task, update the next-action list. Do not assume future sessions will remember unstated context.

That is how you avoid restarting the whole project mentally every time you come back.

Your brain should not be the only database for project truth.

That database is unreliable and occasionally wants snacks.

7. The Demo Law

The startup team ran biweekly demos.

That cadence mattered because it forced work to become visible.

A feature is not done because the code exists.

A feature is not done because the screen loads.

A feature is not done because the AI says, "The implementation is complete."

A feature is done when the intended user behavior works.

The demo law can be simple:

Every work cycle should produce one visible user improvement or one clearly explained technical improvement that protects the user's workflow.

For a team, that might mean a demo every two weeks.

For a solo beginner, it might mean:

At the end of every build session, show the exact user path that now works, record what still fails, and write the next test.

This keeps you from drifting into fake progress.

You are not collecting files.

You are building user behavior.

8. The Retrospective Law

The constitution should be amendable.

This is important.

A constitution is not a sacred tablet. It is a living operating system.

In the startup project, retrospectives gave us a place to ask:

What slowed us down?

What caused confusion?

Which rule helped?

Which rule needs to change?

What should we stop doing?

What should become part of the constitution?

That is how the document stays useful instead of becoming a stale shrine to decisions made when everyone knew less.

For an AI-assisted beginner project, I would run a tiny retrospective every few sessions:

Where did AI drift?
Which instruction did I repeat too many times?
Which bug came from an unclear rule?
Which project fact should be written down?
Which new law would prevent this next time?

That last question is the whole mechanism.

If you keep correcting the same behavior, you do not need more patience.

You need a rule.

What This Looks Like As An AI Prompt

Here is a practical starter prompt:

I am building [app idea] with AI assistance.

Before we write code, help me create a short project constitution.

The constitution should define:
1. the version-one project boundary
2. data and schema-change rules
3. reusable component rules
4. model/type creation rules
5. change summary or pull request rules
6. communication and project-log rules
7. demo or verification rules
8. retrospective rules for improving the constitution

For each rule, explain:
- why it exists
- what mistake it prevents
- what the AI coding tool must ask before violating it

Keep the constitution practical enough to paste into a Notion page, AGENTS.md file, or project rules document.

Then paste the result somewhere the project can actually use it.

Not just in a chat that disappears.

Put it in Notion.

Put it in AGENTS.md.

Put it in your repo docs.

Put it wherever you and the AI will see it before work starts.

The location matters less than the behavior:

The rules must be visible while decisions are being made.

Autonomy Needs Boundaries

This is the part beginners often misunderstand.

Autonomy does not mean no rules.

Autonomy means the rules are clear enough that people can move without asking permission for everything.

That is why the constitution helped on the startup project. It reduced ad hoc feedback. It reduced random interruptions. It made feature ownership easier because the developers had shared tactics instead of a blank field of possible decisions.

The same thing applies to AI tools.

If you have to correct the AI every five minutes, the tool is not the whole problem.

Your project may not have enough written law.

Write the law once.

Then make the tool operate inside it.

That is a much stronger habit than trying to remember every preference, every rule, every constraint, every warning, and every decision yourself.

A project constitution is not a replacement for judgment.

It is a way to preserve judgment so you do not have to regenerate it from scratch every session.

The practical takeaway:

Before you ask AI or a small team to build faster, write the operating laws that make faster safe.

Not a giant plan.

Not a rigid bureaucracy.

A living constitution.

The what and why stay clear.

The how has room to breathe.

And the project stops relying on constant correction as its main management system.

I made a free AI App Builder Starter Prompts pack for beginners who want to turn a rough app idea into a scoped first build with AI:

https://marcusykim.gumroad.com/l/ai-app-builder-starter-prompts

If you want the full build-along field manual behind the free prompts, AI App Builder From Zero walks through idea, scope, stack, prompting, QA, deployment, and launch:

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/

The Beginner App Idea Checklist Before You Ask AI To Code In 2026

Marcus Kim — Sat, 04 Jul 2026 18:42:50 +0000

The most dangerous moment in an AI-built app project is not when the code breaks.

It is earlier.

It is the moment where your idea is still blurry, the AI coding tool is sitting there politely, and you type:

Build me an app that...

That sentence feels productive.

It also gives the tool permission to make a pile of decisions you have not made yet.

Who is the app for?

What is version one?

Which workflow matters first?

What data has to exist?

What should not be built yet?

What would make the first version successful?

If those answers are missing, AI has to guess. And AI guessing at product shape is how beginners end up with a login system, dashboard, profile editor, notifications panel, admin area, billing flow, and settings page before one real user problem has been solved.

That is not momentum.

That is software confetti.

I like AI coding tools. I use them heavily in real app work. But the tool gets much better when the project has boundaries before code starts changing.

So before you ask AI to code your first app, run the idea through a checklist.

Not a giant business plan. Not a pitch deck. Not a 47-tab spreadsheet that makes you feel like you joined a corporate strategy retreat by accident.

A practical beginner checklist.

The goal is simple: turn a rough app idea into something AI can help you build without inventing the whole product for you.

1. Can You Name The Person?

Do not start with "users."

Start with one person you can picture.

Bad:

This app is for people who want to be more productive.

Better:

This app is for freelance designers who need one place to track client feedback, revision status, and final file delivery.

Bad:

This app is for musicians.

Better:

This app is for guitarists who want to capture riff ideas quickly on their phone without opening a full mobile studio app.

Bad:

This app is for students.

Better:

This app is for college students who want to scan textbook chapters and turn them into study notes before an exam.

When you name the person, the app gets less abstract.

The AI no longer has to build for a foggy market. It can reason about a real situation.

Ask:

Who is one specific person this app helps?
What are they trying to get done?
What is annoying about their current workaround?
Why would they care enough to try a new tool?

If you cannot answer those questions, do not code yet.

The app idea may still be good. It is just not shaped enough.

If this is the point where you usually get stuck, I made AI App Builder Starter Prompts, a free prompt pack for turning a rough website or mobile app idea into a scoped first build with AI:

https://marcusykim.gumroad.com/l/ai-app-builder-starter-prompts

Use the free prompts before the code prompt. The blank prompt box gets much less weird when the first job is "help me shape the idea," not "build the entire thing."

2. Can You Explain The Pain Without Naming The App?

A useful app idea should make sense even before you describe the product.

Try this sentence:

[PERSON] has a hard time doing [JOB] because [CURRENT WORKAROUND] is [SPECIFIC PROBLEM].

Examples:

Freelance designers have a hard time tracking client revisions because feedback gets scattered across email, texts, PDFs, and meeting notes.

Beginner musicians have a hard time organizing phone recordings because voice memo apps capture audio quickly but do not understand tempo, key, song sections, or export paths.

Local event organizers have a hard time knowing who is actually coming because RSVPs, group chats, payment links, and reminders live in separate places.

This matters because beginners often fall in love with the app category before they understand the pain.

"A social app for runners" sounds like an idea.

But what is the actual pain?

Are runners trying to find partners at the same pace?

Are they organizing local meetups?

Are they logging routes?

Are they comparing shoes?

Are they trying not to get ghosted by their Saturday morning running group?

Those are different products.

AI can help you build any of them, but it cannot know which one you mean unless you say it.

3. Can You Describe One Complete Workflow?

An app is not a list of features.

An app is a workflow a person can complete.

That sentence saves beginners a lot of pain.

A feature list might say:

accounts
profiles
events
chat
notifications
search
payments
settings

That looks official. It also tells you almost nothing about what the first user does.

A workflow says:

A local organizer creates an event, shares it with a small group, collects RSVPs, and sends one reminder before the event starts.

Now you have a path.

For a musician app:

A guitarist opens the app, starts a new idea, records a riff, adds tempo and key notes, tags it, and finds it later.

For a client feedback app:

A freelancer creates a client project, adds a deliverable, records feedback, marks revisions, and sees what is ready to send.

This is where AI becomes much more useful.

You can ask it to build around one path instead of dumping a feature buffet into the editor.

Use this prompt:

Here is my rough app idea:
[APP IDEA]

Help me define one complete version-one workflow.

Use this format:
Target person:
Problem:
Workflow start:
Workflow steps:
Workflow finish:
What the user has after finishing:
What version one should exclude:

Notice the last line.

Exclusions are not negative. They are how you protect the first build.

4. Can You Say What Version One Does Not Include?

The easiest way to make your first app too big is to define only what it includes.

You also need a not-yet list.

For a beginner event app, version one might include:

create an event
share an event link
RSVP yes or no
see attendee count
send one reminder

Version one might exclude:

payments
group chat
friend feeds
profile badges
AI recommendations
admin analytics
public event discovery
complex notification preferences

Could those excluded features matter later?

Sure.

Later is the key word.

Your first app does not need to prove every possible future. It needs to prove one useful thing.

I learned this through software work and freelancing: the app gets easier to build when the boundary is boringly clear. The shiny extra feature usually feels harmless until it touches authentication, data, UI, permissions, QA, deployment, and the next three conversations you have with yourself at midnight.

Make the not-yet list early.

Ask:

Given this app idea and version-one workflow, list:
1. What version one must include.
2. What version one should explicitly exclude.
3. Which excluded features are tempting but dangerous.
4. Which excluded features could become version two.
5. Why each exclusion protects the first build.

If AI argues that everything is essential, ask it to rank by survival:

If I could only build one workflow in the next seven days, which workflow should survive and why?

5. Can You Name The Data?

Beginners often think the database is a technical detail for later.

It is not.

You do not need to become a database expert before building your first app, but you should know what nouns the app cares about.

For an event app, the nouns might be:

user
event
RSVP
attendee
reminder

For a musician recording app:

user
recording
tag
tempo
key
export

For a freelance client feedback app:

client
project
deliverable
feedback item
revision
file

These nouns become screens, tables, relationships, permissions, test data, and edge cases.

If you ask AI to code before you name the data, the tool may create a schema that technically works but does not match the product you meant.

Ask:

For this version-one workflow, identify the core data objects.

For each object, explain:
- what it represents
- what fields it probably needs
- who can create it
- who can edit it
- who can view it
- what could go wrong if the data is designed badly

This prompt is not about perfection.

It is about making AI explain the product's skeleton before it starts stacking code on top of it.

6. Can You Spot The Risky Part?

Every app idea has at least one risky part.

Risk does not always mean "hard algorithm."

Sometimes the risky part is:

login
payments
permissions
file uploads
push notifications
App Store review
moderation
location data
syncing across devices
real-time chat
messy user-generated content
a vague promise like "AI will recommend the best option"

The beginner mistake is treating all features as equal.

They are not equal.

"Show a list of saved recordings" and "sync audio files across devices with sharing permissions" do not belong in the same mental bucket.

Ask AI:

For this app idea, identify the five riskiest implementation areas for a beginner.

For each risk, explain:
- why it is risky
- what could break
- how to simplify it for version one
- what I should test manually
- whether it should be postponed

You are not trying to scare yourself out of building.

You are trying to stop the app from hiding its hardest parts until the end.

7. Can You Define Done?

This is the checklist item beginners skip because it feels too obvious.

It is not obvious.

If you do not define done, AI will define done as "the code exists."

That is not done.

For a first app, done should mean the user can complete the workflow.

Example:

Done means a guitarist can create a recording, add tempo/key notes, tag it, close the app, reopen it, find the recording, play it back, and export it.

Example:

Done means an organizer can create an event, share the event page, collect RSVPs from three test users, and send one reminder that those users can see.

Example:

Done means a freelancer can create a client project, add three pieces of feedback, mark one revision complete, and see which deliverables are still waiting.

That kind of done line changes how you build.

You stop asking whether the app has enough features.

You start asking whether the person can finish the job.

Use this prompt:

Based on this version-one workflow, write a "done when" checklist.

The checklist should include:
- the happy path
- at least five edge cases
- test data I should create
- manual QA steps
- what should happen if something fails
- what I should not accept as done

This is also where the free AI App Builder Starter Prompts can help because several of the prompts are designed to make AI slow down, define the build, and turn the idea into testable work before you ask for implementation:

https://marcusykim.gumroad.com/l/ai-app-builder-starter-prompts

Again, it is free. Use it to make the app smaller, clearer, and easier to verify.

The Full Beginner Checklist

Before you ask AI to code, your app idea should pass these questions:

1. Can I name one specific person this app helps?
2. Can I explain the pain without naming the app?
3. Can I describe one complete version-one workflow?
4. Can I say what version one does not include?
5. Can I name the core data objects?
6. Can I spot the riskiest parts?
7. Can I define what "done" means in user terms?

If the answer is no, your next prompt should not be:

Build the app.

It should be:

Help me make this app idea buildable.

That is a different kind of AI usage.

It is less exciting for the first five minutes and much better for the next five days.

A Good First App Idea Feels Smaller Than Your Imagination

This is the uncomfortable part.

When the checklist works, your app idea will usually feel smaller.

That does not mean the idea got worse.

It means the first build got clearer.

A giant imaginary platform can contain every feature you have ever wanted. It can also stay imaginary forever.

A small useful workflow can be built, tested, shown, repaired, and improved.

That is the point.

You are not trying to impress AI with ambition. AI does not need to be impressed. It will happily build a complicated mess with the emotional confidence of a printer jamming at the worst possible time.

You are trying to give the tool a job it can actually help you finish.

Start with the person.

Name the pain.

Pick the workflow.

Cut version one down.

Name the data.

Respect the risky parts.

Define done.

Then ask AI to code.

I made AI App Builder Starter Prompts for exactly this stage: a free pack of prompts for beginners who want to turn a rough app idea into a scoped first build with AI.

https://marcusykim.gumroad.com/l/ai-app-builder-starter-prompts

If you want the full build-along field manual behind the free prompts, AI App Builder From Zero walks through idea generation, scope, stack choice, prompting, QA, deployment, App Store, Google Play, and launch.

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/

How To Plan Your First AI-Built App In Phases In 2026

Marcus Kim — Thu, 02 Jul 2026 18:12:45 +0000

The fastest way to make AI overbuild your first app is to ask for the whole app at once.

I know that sounds like the obvious thing to ask.

You have an idea. You open an AI coding tool. You want the tool to help. So you type something like:

Build me an app where people can create events, invite friends, chat, post updates, sell tickets, manage profiles, and discover local groups.

Then the tool tries to be helpful.

It gives you authentication, dashboards, profile settings, feeds, payments, notifications, admin controls, search, upload flows, moderation, analytics, and a database schema that looks like it is already preparing for Series A.

That can feel exciting for about five minutes.

Then you realize you do not have a first app. You have a fog machine with folders.

The beginner problem is not that AI refuses to build. The beginner problem is that AI is willing to build before the project has a shape.

Your first app needs phases.

Not because phases sound professional. Not because someone in a collared shirt once said "roadmap" while pointing at a whiteboard.

Phases matter because software is easier to build, test, and explain when every step has a job.

The better first prompt is not:

Build the whole thing.

The better first prompt is:

Help me turn this rough app idea into a phased build plan.

That one change can keep your project from becoming a technically impressive mess.

The App Is Not One Blob

Beginners often talk about an app like it is one object.

"I want to build a social app."

"I want to build a fitness app."

"I want to build a marketplace."

"I want to build an AI note-taking app."

That is normal language, but it is bad build language.

An app is not one blob. It is a set of user workflows, screens, data, permissions, edge cases, and launch constraints that have to cooperate.

If you ask AI to build the blob, the tool has to make hidden decisions for you.

It decides what the first user does. It decides what accounts mean. It decides what data exists. It decides which screens matter. It decides whether the app is web-first or mobile-first. It decides what "done" looks like.

That is too much accidental ownership to give away at the beginning.

I have seen this in software work, startup work, and freelance work: the app gets calmer when the plan moves from vague product name to phased user progress.

The useful question becomes:

What should the user be able to do first?

Not eventually.

First.

If you are stuck at the blank prompt box, I made a free AI App Builder Starter Prompts pack for this exact moment. It helps you turn a rough app idea into a scoped first build before you ask AI to generate too much at once:

https://marcusykim.gumroad.com/l/ai-app-builder-starter-prompts

Use the free prompts to get the project into phases. Then use AI to help you build the first phase instead of letting it invent the entire future of the app.

Phase 1: Name The Person And The Job

Before screens, stacks, frameworks, or databases, name the person.

Not "users."

A person.

Give that person a simple profile:

Maya is a college band conductor who needs a faster way to organize game-day rosters and send practice reminders.

or:

Chris is a beginner guitarist who wants to record song ideas quickly without opening a full mobile studio app.

or:

Jenna is a freelance designer who needs one place to track client feedback, revision status, and final asset delivery.

Now the app has gravity.

You are not building "a productivity app." You are helping Jenna keep client feedback from turning into an archaeological dig.

You are not building "a music app." You are helping Chris catch a riff before it disappears into the same mental drawer as every password he has ever forgotten.

Ask AI:

Here is my app idea:
[APP IDEA]

Help me define three possible ideal users.
For each user, describe:
- who they are
- what problem they have
- what job they want the app to do
- why existing tools might feel annoying
- what version one should help them accomplish

Do not skip this because it feels simple.

If you cannot picture the person, AI will have to build for a blur.

Blur is where scope goes to multiply.

Phase 2: Pick The MVP Value

MVP does not mean "ugly app."

It means the smallest version that proves the main value.

That distinction matters.

If your app is for musicians capturing song ideas, the MVP is probably not social profiles, collaboration rooms, AI mastering, paid sample packs, and a marketplace.

The MVP might be:

A musician can create a recording, add tempo/key notes, tag it, and find it later.

That is still real software.

It has recording, files, metadata, search or filtering, storage, and a clear user path.

But it has a boundary.

Ask AI:

Given this user and app idea, define the MVP as one complete user workflow.

Use this format:
User:
Problem:
Version-one promise:
Core workflow:
What version one includes:
What version one excludes:
What would prove the MVP works:

The exclusion list is not pessimism.

It is project protection.

Most first apps do not die because version one was too small. They die because version one swallowed version three, version four, and a vague enterprise dashboard wearing a fake mustache.

Phase 3: Break The App Into Feature Groups

Once you know the MVP, break the app into feature groups.

In software teams, you might hear these called epics. Beginners do not need to worship the terminology, but the concept is useful.

An epic is a parent bucket of related work.

For an event or social app, examples might be:

accounts
profiles
event creation
event discovery
RSVPs
messaging
notifications
admin tools

For a musician recording app, examples might be:

recording
take library
tags and notes
playback
export
settings

This does not mean you build all of them now.

It means you know what exists in the product universe.

Then you choose which feature group belongs in phase one.

Ask AI:

Break this app into high-level feature groups.

Then mark each feature group as:
- phase 1: required for MVP
- phase 2: useful after MVP works
- later: not needed until there is real usage

Be strict. Protect me from overbuilding.

The last line matters.

AI often defaults to being expansive. You can ask it to be protective.

Phase 4: Design The First Screen Suite

I like getting to screens early.

Not because screens are the whole app.

They are not.

But screens force the idea to stop floating.

If you say "event discovery," that can mean anything. If you sketch the first event list, event detail page, RSVP flow, and confirmation state, the product becomes easier to discuss.

For a beginner working with AI, a first screen suite might include:

home or dashboard
create screen
detail screen
edit screen
empty state
success state
error state

You do not need a museum-quality Figma file before anything can happen. But you do need enough visual clarity that AI is not inventing the interface from vibes.

Ask AI:

Based on this MVP workflow, list the minimum screens needed.

For each screen, include:
- purpose
- main user action
- required data shown
- empty state
- error state
- where the user can go next

If visual quality matters, use a design tool like Figma or an AI design tool to create a first pass. Then turn the design values into a small design system: colors, type, spacing, buttons, forms, cards, navigation, and states.

Your first app does not need a giant design system.

It does need enough consistency that every new screen does not become a fresh style experiment.

Phase 5: Decide The Data Before It Decides For You

Data is where a lot of beginner apps quietly become messy.

The screen looks simple:

Create event.

The data behind it is less simple:

event title
description
location
start time
end time
host user
attendees
RSVP status
visibility
created date
updated date

If you do not define the data model, AI will still create one.

It just might not be the one you meant.

Ask AI:

For this MVP workflow, propose the minimum data model.

Include:
- entities or tables
- fields
- relationships
- required fields
- optional fields
- simple example records
- what should not be stored yet

Then ask:

What part of this data model is most likely to change later?
What should I keep simple now so I do not trap version one?

This is not about becoming a database expert overnight.

It is about noticing the decisions before the project buries them.

The free AI App Builder Starter Prompts include planning prompts for scope, stack, screens, data, QA, and launch, so they can help you create this kind of phase map before code starts piling up:

https://marcusykim.gumroad.com/l/ai-app-builder-starter-prompts

Again, the prompts are free. The point is not to collect prompts like trading cards. The point is to make AI explain the project before it builds the project.

Phase 6: Turn Features Into User Stories

A feature is too vague by itself.

"Messaging" is not a build step.

"A signed-in user can send a text message to another signed-in user and see it appear in the conversation" is closer.

That is a user story.

For beginners, a user story is just a small sentence that describes one thing a person can do.

Good user stories are testable.

Bad user stories are fog with verbs.

Ask AI:

Turn the phase-one feature group into user stories.

Each story should include:
- user action
- expected result
- required screens
- required data
- rough implementation notes
- QA checks
- what would count as done

This helps you build vertical slices instead of random pieces.

A vertical slice means one user path works from the interface to the data to the expected result.

That matters because a pile of half-built screens is hard to test. A small complete workflow is easier to trust.

The first goal is not:

Create every screen.

The first goal is:

Make one important user story work end to end.

Phase 7: Build One Slice At A Time

This is where AI can become genuinely useful.

Once the phase is clear, you can ask the tool to help with a focused slice:

Build the "create recording" workflow.

Use the existing project rules, design system, and data model.
Do not add new features.
Do not introduce a new service.
Implement only what is required for this user story:
[USER STORY]

When finished, give me a QA checklist for this workflow.

That prompt gives AI a job with walls.

Walls are good.

Walls keep the tool from "helpfully" turning your recording feature into a social audio platform with creator monetization and a mascot.

After the slice is built, test it like a user:

Can you start the flow?
Can you complete the main action?
Does the data save?
Does the next screen show the result?
What happens with empty input?
What happens with bad input?
What happens if you refresh, close, or reopen?
Can you repeat the flow twice?

If the answer is no, the slice is not done.

It may be close.

It may be pretty.

It may have generated a lot of files.

But it is not done.

Phase 8: Launch Only After The MVP Workflow Survives Reality

Launch does not have to be dramatic.

For a first app, launch might mean:

a TestFlight build
a small web deployment
a private beta link
a demo to one client
a walkthrough with one target user
a public version-one release

The point is not to make noise. The point is to get the app in front of reality.

Before launch, ask AI for a release checklist:

Create a launch checklist for this MVP.

Include:
- critical user workflows
- account/auth checks if relevant
- data checks
- payment checks if relevant
- mobile or browser checks
- empty and error states
- privacy or permission checks
- deployment steps
- rollback plan
- known issues I should disclose or fix first

This is where beginners are tempted to trust the app because it ran once.

Do not do that.

One successful run is a hint.

Repeated successful runs are evidence.

A real user completing the workflow without you narrating every tap is better evidence.

The Whole Phase Map

Here is the simple version:

1. Name the person and the job.
2. Pick the MVP value.
3. Break the app into feature groups.
4. Design the first screen suite.
5. Decide the data model.
6. Turn features into user stories.
7. Build one vertical slice at a time.
8. QA, deploy, and launch only after the MVP workflow survives.

You can make this more formal later.

You can add story points, sprint planning, issue tracking, pull requests, environments, release notes, analytics, and all the other grown-up software furniture when the project needs it.

At the beginning, you need the habit.

Do not ask AI to build the blob.

Ask AI to help you phase the app.

Then ask it to build the next slice.

Then test the slice.

Then move forward.

That rhythm is slower than the fantasy of one prompt building everything.

It is also much more likely to give you an app you can understand, verify, and improve.

The beginner who wins with AI is not the person who asks for the biggest output.

It is the person who keeps the project small enough to steer.

I made AI App Builder Starter Prompts: a free pack with 25 core planning prompts plus bonus build and deployment prompts for web, iOS, Android, Expo, and Flutter:

https://marcusykim.gumroad.com/l/ai-app-builder-starter-prompts

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/

Why AI Makes Judgment More Valuable For Freelancers In 2026

Marcus Kim — Mon, 29 Jun 2026 21:19:54 +0000

AI makes it easier to build the wrong thing with confidence.

That is the part I think a lot of beginner builders and freelancers miss.

The obvious story is that AI makes execution faster. That is true. I can ask an AI coding tool to explain an error, compare implementation options, inspect a project, write code, refactor a screen, generate a QA checklist, or help me pick up where I left off.

That is a huge change.

But speed is not the whole story.

When the tool gets faster, your judgment becomes more important, not less. You have to decide what the project is allowed to become. You have to decide which tradeoffs are acceptable. You have to decide whether the output actually matches the user's job. You have to decide when the AI is solving the real problem and when it is decorating the wrong one.

In my freelance work, AI changed the job from searching and stitching to directing, reviewing, and verifying.

That sounds cleaner than it feels.

Directing means you need to know what outcome you want.

Reviewing means you need to notice when the answer is plausible but wrong.

Verifying means you cannot treat a green checkmark, a pretty screen, or a confident explanation as proof that the app actually works.

The beginner mistake is believing AI removes the need to think clearly.

The better rule is this:

AI removes some friction from execution, then hands you more responsibility for scope.

The Faster Tool Still Needs A Smaller Job

When I started using AI heavily for software work, the old research loop changed immediately.

Before modern AI tools, a lot of software work meant digging through documentation, old forum posts, Stack Overflow answers, YouTube videos, outdated examples, and half-related blog posts until something clicked. You stitched pieces together and hoped the tutorial you found still matched the version of the framework you were using.

Now you can ask the tool directly.

That is better.

It is also dangerous if you confuse a fast answer with a good product decision.

If you tell AI:

Build me a marketplace app for local creators.

it may give you accounts, profiles, payments, listings, search, messaging, moderation tools, an admin panel, notifications, subscriptions, dashboards, analytics, and a database schema that looks like it has already hired a CFO.

None of that means you have a good first version.

It means you gave the tool a giant empty room and it started moving furniture into every corner.

A freelancer cannot survive that way. A beginner app builder cannot learn that way. A client project cannot stay sane that way.

The faster the tool gets, the more you need to give it a smaller job.

If you are using AI to plan your first app and the blank prompt box is the part slowing you down, I made a free AI App Builder Starter Prompts pack for beginners. It helps you turn a rough app idea into a scoped first build instead of asking AI to invent the whole project at once:

https://marcusykim.gumroad.com/l/ai-app-builder-starter-prompts

Use the free prompts as a starting point, not a substitute for judgment. The point is to create a better conversation with AI, then keep steering it.

Judgment Starts With What You Exclude

Most beginners think judgment means choosing the best tool.

Should I use Firebase or Supabase?

Should I build a web app or a mobile app?

Should I use React, SwiftUI, Flutter, Expo, Next.js, or whatever somebody on the internet is yelling about this week?

Those decisions matter.

But the first judgment call is usually smaller and more boring:

What are we not building yet?

This matters because AI is very willing to be helpful in every direction at once.

If your idea is "an app for musicians to save song ideas," the first version might only need to help one musician record a rough idea, name it, tag it, and find it later.

That is useful.

That is also already enough work.

You do not need public profiles in version one. You do not need collaboration rooms. You do not need a social feed. You do not need AI mastering. You do not need a creator marketplace. You do not need to solve the entire music industry before the app can reliably save a recording.

This is where judgment protects the project.

Judgment says:

This feature is tempting, but not required.
This workflow matters first.
This tool adds more complexity than it removes.
This deadline does not survive the new scope.
This screen looks finished, but the user cannot complete the core job yet.

AI can help you see those tradeoffs, but you have to ask for them.

Try this before building:

Review this app idea as if you are protecting a beginner from overbuilding.

What should version one include?
What should version one exclude?
What feature sounds useful but would create the most risk?
What is the smallest workflow that would make this app valuable?
What does "done" mean for that workflow?

That prompt is not magic.

It just points the conversation at the real decision.

Freelancing Makes The Cost Obvious

Freelancing teaches you that vague scope is not a writing problem.

It is a future calendar problem.

If the promise is blurry, the work expands. If the work expands, the timeline changes. If the timeline changes without a real conversation, everybody starts living inside a weird fog where the app is both almost done and somehow nowhere near done.

AI does not fix that.

AI can make it easier to create more screens, more code, more flows, and more convincing demos before the actual agreement is clear.

That is why I like demo-shaped progress.

A good demo is not "look at all the files that changed."

A good demo is:

Here is one new thing a user can do now that they could not do before.

That rule works for client work, but it also works for your own first app.

If you are building with AI, do not measure progress by how much the tool produced. Measure progress by whether one real user workflow got closer to working.

Can the user create the thing?

Can they save it?

Can they find it again?

Can they edit it?

Can they complete the task without you explaining the interface?

Can you test the path twice and get the same result?

That is where the work becomes real.

The AI may produce the code, but you still own the proof.

The Project Needs A Rulebook

One reason AI goes sideways is that beginners expect it to remember a project that has never been defined.

The tool does not automatically know your product taste, user, constraints, stack decisions, naming rules, design system, data model, or definition of done.

You have to give it a source of truth.

I like creating project knowledge early:

the user
the one workflow
the stack
the screens
the data model
the feature exclusions
the design rules
the QA checks
the launch goal
the definition of done

This does not need to be fancy.

It can be a Markdown file, a project brief, an AGENTS.md, a design-system note, a checklist, or a simple build plan.

The format matters less than the shared agreement.

When the AI starts wandering, you can pull it back to the rulebook:

Use the project rules. Do not add new services, screens, or features unless they are required for the version-one workflow.

That sentence can save you from a lot of expensive cleverness.

This is also where the free AI App Builder Starter Prompts help. They are designed to make you define the idea, scope, stack, screens, data, QA, and launch path before you let AI run too far:

https://marcusykim.gumroad.com/l/ai-app-builder-starter-prompts

The useful habit is not "paste one perfect prompt."

The useful habit is building a project memory that you and the AI can both follow.

Three Questions I Ask Before Trusting The Output

When AI gives me a plan or implementation, I try to slow down around three questions.

1. What decision did the AI make for me?

AI often hides decisions inside confident output.

It chooses a stack. It chooses a data shape. It chooses a screen flow. It chooses a permission model. It chooses what "simple" means.

If you do not notice those decisions, you inherit them.

Ask:

List the major product and technical decisions you made in this plan. For each one, explain the tradeoff and a simpler alternative.

You are not trying to become an expert on everything overnight.

You are trying to stop accidental architecture from becoming the foundation of your app.

2. What would prove this works?

A feature is not done because it exists in code.

It is done when the user can complete the job it was built for.

Ask:

Give me a QA checklist for this workflow. Include happy paths, empty states, invalid inputs, permission problems, and regression risks.

Then actually run the checklist.

This is the part beginners want to skip because the app already looks finished.

Do not skip it.

Pretty is not proof.

3. What can wait?

AI is good at giving you more.

You need to get good at saying "not yet."

Ask:

What parts of this plan can wait until after version one? Remove anything that is not required for the first user workflow.

This is not anti-ambition.

It is sequencing.

A small working app is not a failure. It is evidence. It tells you what is real enough to build on.

The Freelancer Version Of AI Leverage

The dream version of AI leverage is that the tool does all the hard parts.

The practical version is different.

AI helps me move faster when I know how to frame the work. It helps me recover context. It helps me compare options. It helps me inspect problems. It helps me draft plans. It helps me implement.

But it does not absolve me from product judgment.

If I give AI a bad goal, I can get a polished bad result.

If I give AI vague scope, I can get a bigger vague project.

If I skip QA, I can get a nice-looking app with broken trust.

If I let the tool keep adding clever fixes, I can end up with a pile of surgical patches instead of a clean solution.

The value is not in pretending the tool is magic.

The value is in becoming a better operator.

That means writing clearer project rules. Asking better questions. Keeping the first version small. Testing the actual workflow. Having the uncomfortable scope conversation early. Letting the AI propose options, then making the decision yourself.

AI can multiply your work.

That is exactly why your judgment matters.

It can multiply good direction.

It can also multiply confusion.

A Practical Rule For Beginner Builders

If you are building your first app with AI, do not start by asking the tool to build the whole app.

Start by asking it to help you make the project smaller and more testable.

Use this operating rule:

Before AI writes code, it must help me define the user, workflow, exclusions, stack, screens, data, QA checks, and done-when line.

That is not as exciting as watching the tool generate a huge codebase.

It is much more useful.

The beginner who wins with AI is not always the person with the cleverest prompt.

It is often the person who keeps asking:

What are we building?
Who is this for?
What can the user do when it works?
What are we excluding?
How will we prove it works?
What decision did AI just make for me?

Those questions are judgment.

And in 2026, judgment is not less valuable because of AI.

It is the part that keeps the speed pointed at something worth building.

I made AI App Builder Starter Prompts: a free pack with 25 core planning prompts plus bonus build and deployment prompts for web, iOS, Android, Expo, and Flutter:

https://marcusykim.gumroad.com/l/ai-app-builder-starter-prompts

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/