DEV Community: Marcus Kim

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/

25 Prompts For Planning Your First Website Or Mobile App With AI In 2026

Marcus Kim — Sat, 27 Jun 2026 18:52:30 +0000

The most dangerous beginner prompt is also the most tempting one:

Build me an app for [idea].

It feels direct. It feels efficient. It feels like the whole point of using AI.

But if you are building your first website or mobile app with AI, that prompt is usually too empty. It asks the tool to make product decisions, architecture decisions, scope decisions, design decisions, data decisions, and launch decisions before you have told it what kind of project you are actually trying to make.

That is how a small idea turns into a pretend platform.

You wanted a simple app for tracking workout routines. AI gives you accounts, subscriptions, social features, leaderboards, wearable integrations, dashboards, an admin panel, and a database schema that looks like it should have a board of directors.

The answer looks impressive.

That does not mean it is a good first build.

Before I let AI write serious code, I want it to help me do three boring but useful things:

Make the idea smaller.
Name the one workflow version one must complete.
Define what "done" means before the project starts growing extra heads.

That is the real job of planning prompts. They are not there to make you feel like a prompt wizard. They are there to keep the project from becoming harder than your current skill level, attention span, and actual use case can support.

If you want a ready-made version of this planning flow, I made a free AI App Builder Starter Prompts pack for beginners who have an app idea but do not know what to type first:

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

Use the prompts below as a practical planning sequence. You do not need all 25 for every project, but if you are a beginner, running through them once will probably save you from a lot of fake progress.

How To Use These Prompts

Do not paste all 25 prompts at once.

That is how you turn AI into a very confident document blender.

Use them in passes:

First, pressure-test the idea.
Then define the user and workflow.
Then choose the platform and stack.
Then map the screens, data, and rules.
Then ask for a build plan, QA plan, and launch plan.

At each step, make the AI explain tradeoffs in plain English. If it uses a term you do not understand, stop and ask. If it proposes something too big, tell it to shrink the plan.

The goal is not to look technical.

The goal is to build a project you can actually finish.

1. The Rough Idea Prompt

Use this when your app idea still feels like a paragraph instead of a project.

I have a rough app idea: [describe the idea].

Help me turn this into a clearer app concept. Identify the likely user, the problem they have, the main workflow, and the smallest useful version one. Keep the explanation beginner-friendly and do not suggest advanced features yet.

The important phrase is "smallest useful version one."

Without that, AI often tries to describe the grown-up version of the product. You need the first useful slice, not the whole imaginary company.

2. The One User Prompt

Use this to avoid building for "everyone."

For this app idea, help me choose one specific first user. Give me three possible user types, explain which one is easiest to build for first, and recommend one user to target for version one.

"Everyone" is not a user. It is a fog machine.

You want one person you can picture. A student planning assignments. A musician saving song ideas. A freelancer tracking client demos. A gym owner managing class signups.

The more specific the first user is, the easier the app becomes to scope.

3. The One Workflow Prompt

This is one of the most important prompts in the whole list.

Define the one workflow version one of this app must complete from start to finish.

Use this format:
"Version one helps [one user] do [one job] from [starting point] to [finished result]."

Then list what is outside the scope for version one.

Your first app does not need ten workflows.

It needs one workflow that actually works.

4. The Too-Big Detector Prompt

Use this before AI starts flattering your idea into a monster.

Review this app idea as if you are trying to protect a beginner from overbuilding.

What parts are too big for version one?
What parts can wait?
What parts are probably unnecessary until real users ask for them?
Give me a smaller version I could realistically build first.

I like prompts that give AI a job besides "be helpful."

Here, the job is to protect the beginner from scope creep.

5. The Web Or Mobile Prompt

Use this when you do not know whether to start with a website, mobile app, or cross-platform build.

For this app idea, should a beginner build version one as a web app, native iOS app, native Android app, Expo app, Flutter app, or something else?

Compare the options using:
- difficulty
- speed to first version
- deployment complexity
- user expectations
- payment or account needs
- long-term tradeoffs

Then recommend one path for version one.

The point is not to find the "best" platform in the abstract.

The point is to pick the least confusing path for your first real version.

6. The Stack Explanation Prompt

Use this when AI throws tool names at you like confetti.

Recommend a beginner-friendly stack for this app and explain every part in plain English.

For each tool or service, tell me:
- what it does
- why this app needs it
- what could go wrong if I misunderstand it
- whether there is a simpler alternative for version one

If the AI cannot explain the stack clearly, you should not let it build the stack yet.

Confusion compounds. A tool you do not understand becomes a debugging problem later.

7. The No-New-Tools Prompt

Use this when AI keeps adding services because it can.

Simplify the stack. Assume I want the fewest tools possible for a working version one.

Remove any tool, service, framework, database, or integration that is not necessary for the first user workflow. Explain what we are giving up and why that tradeoff is acceptable for version one.

This is a good correction prompt when the plan starts sounding expensive, brittle, or too clever.

8. The Screen List Prompt

Use this before asking for UI code.

List the minimum screens this app needs for version one.

For each screen, include:
- screen name
- user's goal on that screen
- primary action
- data shown
- data entered
- where the user goes next

Do not include screens that are not needed for the one main workflow.

Screens are easier to reason about than vague features.

Once you can see the screens, you can start noticing whether the app is actually small.

9. The First Screen Prompt

Use this to avoid starting with a giant dashboard.

Which screen should I build first for this app, and why?

Choose the screen that teaches me the most about the core workflow. Explain what must work on that screen before I move on.

Beginners often start with the prettiest screen.

Sometimes that is fine. But usually, you want to start with the screen that proves the core action can work.

10. The Data Model Prompt

Use this when you need to know what information the app stores.

Create a simple data model for version one of this app.

Use beginner-friendly language. For each data object, explain:
- what it represents
- what fields it needs
- which fields are required
- which screen creates or edits it
- which screen displays it

Keep the model as small as possible.

Your backend is not a storage closet.

Do not let AI throw every possible field into the database just because the field might be useful someday.

11. The Data Privacy Prompt

Use this before you build accounts, profiles, uploads, or anything personal.

What sensitive or private data might this app handle?

List what data should be avoided in version one, what data must be protected, and what beginner-friendly design choices reduce privacy risk.
Do not give legal advice. Focus on practical product and engineering caution.

This prompt is not a substitute for real legal or security advice.

It is a sanity check. If your tiny first app suddenly needs sensitive data, you may need a smaller first version.

12. The Authentication Prompt

Use this before adding login.

Does version one of this app actually need user accounts?

Explain:
- what works without login
- what breaks without login
- the simplest acceptable account approach if login is necessary
- what should wait until after version one

Authentication is not just a button that says "Sign in."

It creates password resets, account states, private data rules, error states, permissions, and support problems. Sometimes you need it. Sometimes you are adding a bouncer before the room exists.

13. The Permissions Prompt

Use this for apps that need camera, microphone, files, location, contacts, notifications, or payments.

List every permission this app might request.

For each permission, explain:
- why the app might need it
- whether version one can avoid it
- what user trust issue it creates
- what fallback experience should exist if the user says no

Permissions are product decisions, not just technical switches.

If a user says no, your app still has to behave like it was designed by someone awake.

14. The Feature Priority Prompt

Use this when your feature list is getting noisy.

Here is my feature list: [paste list].

Sort these into:
1. Must exist for version one
2. Nice later
3. Probably a distraction

Explain each choice based on the one main user workflow.

The main workflow is your judge.

If a feature does not support that workflow, it probably should not be in version one.

15. The Acceptance Criteria Prompt

Use this to define "done."

Write acceptance criteria for version one of this app.

Use simple "done when" statements. Focus on what a user can successfully do, not on internal code tasks.
Include happy paths, empty states, common mistakes, and one or two failure cases.

Acceptance criteria are boring in the same way seatbelts are boring.

You notice them when you need them.

16. The Project Rulebook Prompt

Use this before the build starts.

Create a short project rulebook for this app.

Include:
- version one goal
- target user
- main workflow
- out-of-scope features
- stack decisions
- UI style rules
- data rules
- QA rules
- when to ask me before adding complexity

Write it so I can paste it into my AI coding tool as project context.

AI behaves better when the project has a source of truth.

The rulebook is how you stop re-explaining the app every fifteen minutes.

17. The Build Sequence Prompt

Use this when you are ready to turn the plan into tasks.

Turn this app plan into a beginner-friendly build sequence.

Break it into small milestones. Each milestone should produce something I can run, click, test, or inspect. Do not create a giant task list where nothing works until the end.

This matters because a beginner needs visible progress.

If the first seven tasks are invisible setup tasks, you will not know whether the app is real or just accumulating folders.

18. The First Milestone Prompt

Use this to start smaller than your ego wants.

Define the first milestone for this app.

It should be small enough to complete quickly and should prove one important part of the main workflow. Include what files or screens are likely involved, what I should test, and what not to touch yet.

Your first milestone is not "finish the app."

It is "prove one piece of the app is alive."

19. The UI Direction Prompt

Use this before AI designs a pile of generic cards.

Give me a simple UI direction for this app.

Describe the layout, navigation, visual hierarchy, and interaction style. Avoid nested cards and decorative clutter. Make the interface clear for the main workflow, and explain how the design helps the user know what to do next.

AI-generated UI often overuses boxes inside boxes inside boxes.

You can prevent some of that by telling it what clarity means before it starts drawing rectangles for a living.

20. The Empty State Prompt

Use this because every new app starts empty.

For each main screen, describe the empty state.

What does the user see before they have created anything?
What action should the empty state encourage?
What should the app avoid saying or showing?

Empty states are not filler.

They are the first version of onboarding.

21. The Error State Prompt

Use this before something breaks.

List the most likely beginner-level error states for this app.

For each one, explain:
- what went wrong
- what the user should see
- what the user can do next
- what the app should log or preserve

A project starts feeling real when it handles imperfect input, failed saves, missing data, bad network states, and user confusion.

22. The QA Checklist Prompt

Use this before trusting the app.

Create a QA checklist for version one of this app.

Organize it by workflow, screen, data, permissions, edge cases, mobile/desktop behavior, and deployment. Keep it practical enough that a beginner can run the checks manually.

AI can produce code faster than you can understand it.

That makes QA more important, not less.

23. The Bug Report Prompt

Use this when something fails and you do not know what to say.

Help me write a clear bug report for this issue:
[describe what happened]

Ask me for any missing details. Then produce a bug report with:
- expected behavior
- actual behavior
- steps to reproduce
- likely area of the app
- what evidence I should collect before asking AI to fix it

Bad bug prompts create random fixes.

Good bug prompts give the AI enough evidence to work like a teammate instead of guessing in a dark room.

24. The Deployment Plan Prompt

Use this before the app leaves your machine.

Create a beginner-friendly deployment plan for this app.

Explain:
- where this app should be deployed first
- what accounts or services I need
- what environment variables or secrets might exist
- what can go wrong during deployment
- how I can confirm the live app works

Deployment is where your app meets reality.

The earlier you understand that path, the less mysterious the project feels.

25. The Launch Readiness Prompt

Use this before you show the app to anyone.

Review this app as a version-one launch candidate.

Tell me:
- what must be fixed before anyone sees it
- what can be imperfect for a first version
- what I should test one more time
- what I should ask first users after they try it
- what I should not build until I get feedback

This prompt protects you from polishing the wrong thing.

The first launch is not a coronation. It is a learning event.

The Best Prompt Is Usually A Smaller Prompt

The pattern underneath all 25 prompts is simple:

Make AI explain the project before it builds the project.

That one habit changes the whole experience.

Instead of asking AI to invent a complete product from a vague sentence, you make it help you narrow the user, workflow, platform, stack, screens, data, edge cases, QA, and launch path.

That is how you stay in control.

You do not need to become a senior engineer before using AI to build your first app. But you do need to stop treating the AI like it can read your mind.

It cannot.

It can only work from the context you give it, the constraints you enforce, and the checks you run after it produces something.

If you want these ideas in a more guided sequence, the free AI App Builder Starter Prompts pack is built for exactly this first planning conversation:

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

The useful starting question is not:

Can AI build my app?

The better question is:

Can I describe the first useful version clearly enough that AI has something sane to build?

That is the whole game.

Final Takeaway

If you are a beginner, your first app should not prove that AI can generate a lot of code.

It should prove that one person can complete one useful workflow.

Start there.

Use prompts that make the project smaller, clearer, and easier to verify. Then build.

If you want a practical place to start, 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.

Free starter prompts

Full e-book

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 Stop AI From Overbuilding Your First App In 2026

Marcus Kim — Thu, 25 Jun 2026 20:21:53 +0000

The fastest way to make your first AI-built app harder is to sound too ambitious too early.

You type:

Build me an app for local musicians to record song ideas.

That sounds reasonable.

Then the AI comes back with user accounts, teams, cloud sync, collaboration rooms, AI mastering, social sharing, notifications, public profiles, a subscription dashboard, an admin panel, and a database schema that looks like it is trying to get acquired before lunch.

The answer feels impressive.

It may even feel like progress.

But if you are a beginner, that kind of progress can quietly bury you.

AI overbuilding is not always dramatic. It usually looks like helpfulness. The tool tries to give you the "complete" version of the idea. It fills in gaps you did not know existed. It adds features that would be normal in a mature product but absurd in a first build.

The problem is not that AI has too few ideas.

The problem is that AI has too many ideas too quickly.

Your job is to turn a giant possibility cloud into one useful workflow.

That is the operating rule I want you to keep in mind:

Do not ask AI to build your app until you have taught it what not to build.

Overbuilding Starts Before The Code

Beginners often think overbuilding happens later, after the AI has already made too many files.

That is only the visible part.

Overbuilding usually starts in the first conversation.

If your first prompt is too open, AI has to guess:

who the app is for
which platform matters first
how big version one should be
whether accounts are needed
whether data is private or shared
whether the app is a prototype, a client demo, a SaaS, a mobile app, or a weekend experiment
what "done" means

When those choices are missing, AI does what a lot of software people do when they are not constrained: it designs a bigger system.

Not because it is evil.

Because bigger systems sound more complete.

This is where beginners get trapped. The plan looks professional, so they trust it. But "professional-looking" is not the same thing as buildable.

A twenty-table database schema can be nonsense for your first app.

A polished auth flow can be a distraction.

A beautiful dashboard can be a fake finish line if the core user action still does not work.

Before I let an AI coding tool build something meaningful, I want the project to get smaller in writing. I want the tool to explain the smallest useful version. I want it to list what we are excluding. I want it to define the one workflow that has to work before anything else earns a seat at the table.

If you are staring at a rough app idea and do not know how to start that conversation, I made a free AI App Builder Starter Prompts pack for beginners. It gives you a practical sequence for turning a messy idea into a scoped first build:

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

The point is not that one prompt fixes everything.

The point is that your first conversation with AI should reduce the project, not inflate it.

Give AI A One-Workflow Contract

The best beginner constraint I know is the one-workflow contract.

Not a feature list.

Not a vague product vision.

A workflow.

Use this sentence:

Version one of this app is only responsible for helping [one user] do [one job] from start to finish.

For a musician recording app, that might be:

Version one of this app is only responsible for helping one musician record a song idea, name it, tag it, and find it later.

That is already a lot.

It has a user. It has a job. It has a beginning and an end.

It also blocks a pile of tempting extras.

No public feed.

No followers.

No marketplace.

No AI mastering.

No collaboration.

No group chat.

No "creator economy" language stapled to the side of a recorder that cannot reliably save audio yet.

The one-workflow contract gives AI a boundary it can obey.

Try this prompt:

Here is my app idea:
[describe the idea]

Before writing code, reduce it to one version-one workflow.

Answer in this format:
1. Primary user
2. One job the user needs to complete
3. Start of the workflow
4. End of the workflow
5. Features required for that workflow
6. Features to exclude from version one
7. The "done when" line for the workflow

Do not suggest extra features unless they are required for that one workflow.

This prompt does something subtle but important.

It changes AI from "imagine the whole product" mode into "define the first useful path" mode.

That is the difference between an app you can start and an app you can only admire from a distance.

Make An Exclusion List Before You Make A Feature List

Feature lists are seductive.

They make you feel like the product is becoming real.

But for a beginner, the exclusion list is often more valuable.

The exclusion list protects you from future-you.

Future-you will be tired. Future-you will see a shiny idea. Future-you will think, "This would only take a second." Future-you is a liar with good intentions.

Write the exclusions down while you are still calm.

Ask AI:

Given this version-one workflow, create a version-one exclusion list.

For each excluded item, explain:
1. why it is tempting
2. why it should wait
3. what version-one risk it creates if we include it now

The explanation matters.

If AI says "social sharing should wait," that is useful.

If it says "social sharing should wait because it adds auth, privacy decisions, moderation, sharing permissions, UI states, and extra QA paths before the private recording workflow is reliable," that is much better.

Now you understand the cost.

Beginners often underestimate features because they only picture the happy path.

"Add comments" sounds small.

Then you need authorship, editing, deletion, timestamps, empty states, moderation decisions, notification behavior, data rules, abuse handling, and UI for every state.

"Add payments" sounds small.

Then you need checkout, receipt handling, entitlements, refunds, failed payments, support flows, tax/platform constraints, and a decision about whether web payments or mobile in-app purchases make sense.

Every feature brings a little invisible government with it.

You do not need to abolish ambition. You need to sequence it.

Your first app should prove the core workflow before it starts acting like a company.

Cap The Screen List

One practical way to stop AI from overbuilding is to cap the number of screens.

For a first app, I usually want fewer screens than the first AI plan suggests.

Ask:

Design the smallest screen list that supports the version-one workflow.

Rules:
- Maximum 4 screens unless you can prove more are required.
- No dashboard unless the user needs it to complete the workflow.
- No settings screen unless a setting is required for version one.
- No admin area.
- No profile screen unless profile data is part of the core workflow.

For each screen, explain the user action it exists to support.

That last line is the key.

Every screen has to defend its existence.

If a screen does not help the user complete the one workflow, it probably does not belong in version one.

This is especially important because AI coding tools love dashboards.

Dashboards sound official. Dashboards look like apps. Dashboards give the UI somewhere to put charts, cards, numbers, lists, filters, buttons, and status boxes.

But many beginner apps do not need a dashboard first.

They need a working action.

Can the user record the idea?

Can the user save it?

Can the user find it?

Can the user edit it?

Can the user delete it?

Can the user trust that the data is still there after a refresh, restart, or reinstall?

That is less glamorous than a dashboard.

It is also closer to a real app.

Cap The Data Model

AI overbuilding also shows up in the data model.

You start with a simple idea, and suddenly the database has users, teams, memberships, roles, invitations, activity logs, subscription plans, notification preferences, analytics events, tags, categories, projects, comments, reactions, attachments, audit trails, and a table that appears to exist because the AI got lonely.

Data structure matters because it becomes the skeleton of the app.

If the skeleton is too complicated too early, every feature becomes harder to reason about.

Try this prompt:

For version one, propose the smallest data model that supports the one workflow.

Rules:
- Use the fewest entities possible.
- Do not add teams, roles, payments, notifications, analytics, or social features unless required.
- For each entity, explain why it must exist.
- For each field, explain which screen or user action uses it.
- List any fields you are deliberately postponing.

This forces AI to connect data to behavior.

That connection is where beginner clarity lives.

If the app has a Recording object, why?

Because the user records a song idea.

If it has a tag field, why?

Because the user needs to find related ideas later.

If it has a collaboratorRole field, why?

Maybe it does not.

Maybe that belongs to version three after the private recording workflow works.

The goal is not to make the data model tiny forever.

The goal is to keep version one understandable enough that you can test it, explain it, and fix it.

Force A Done-When Line

If you only take one habit from this article, take this one:

Before code, write the done-when line.

Not "done when the recording feature is built."

That is too vague.

Use observable behavior.

This workflow is done when a user can open the app, start a recording, stop it, give it a name, add one tag, save it, close the app, reopen it, find the same recording, play it, edit the name, and delete it.

Now the AI has a target.

You have a QA checklist.

The project has a finish line.

The done-when line also makes overbuilding easier to catch.

If AI suggests comments, ask:

Does this help the user satisfy the done-when line?

If AI suggests public profiles, ask:

Does this help the user satisfy the done-when line?

If AI suggests a dashboard with trend charts, ask:

Does this help the user satisfy the done-when line, or is the app dressing up as a bigger product before the basic workflow works?

This is not anti-feature.

It is pro-finish.

In freelance work, I like demo-shaped progress for the same reason. A demo is strongest when one user can do one new thing from start to finish. That is much clearer than showing a pile of half-connected pieces and saying, "The foundation is coming together."

Sometimes the foundation is coming together.

Sometimes the project is just becoming a very expensive junk drawer.

The done-when line helps you tell the difference.

Make AI Ask Permission Before Expanding Scope

One rule I like giving AI is:

Do not add features, screens, data fields, packages, integrations, or architectural layers outside the version-one workflow without asking me first.

This sounds obvious.

It is not.

AI tools can be very good at making "reasonable" additions during implementation.

They add a helper because it might be useful.

They add a settings page because apps have settings.

They add a role system because future collaboration may need it.

They add a package because it solves a problem you may not actually have yet.

Each addition can be defensible by itself. Together, they turn a beginner project into something harder to finish, debug, and trust.

So make the permission rule explicit.

Put it in the prompt. Put it in your project notes. Put it in an AGENTS.md or project rules file if your tool uses one.

Use language like this:

Project rule:
Version one is intentionally small. If an implementation choice expands scope, adds a new dependency, creates a new screen, changes the data model, or introduces a new user role, stop and ask first. Explain the tradeoff before changing the plan.

That rule will not make the tool perfect.

But it changes the default.

Instead of AI silently expanding the project, it has to surface the expansion as a decision.

That is what you want.

You do not need AI to be less capable.

You need its capability to pass through your judgment.

The free AI App Builder Starter Prompts pack now includes 25 core planning prompts plus bonus build and deployment prompts because the useful workflow is not "ask once, then hope." It is a sequence of constraints and checks:

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

Watch For These Overbuilding Clues

AI is probably overbuilding if the first plan includes:

more than one primary user type
an admin panel before a user workflow works
accounts before private local data has been considered
payments before value has been proven
analytics before there are users
roles and permissions before there are teams
notifications before there is something worth notifying about
a dashboard before there is a repeated workflow to summarize
social features before the private version is useful
a complex stack before the app has a simple job

None of these are always wrong.

They are just expensive.

A beginner should treat them like hot stove features.

You can use them when the app actually needs them, but do not lean on them just because they make the project look serious.

Serious is not the same thing as large.

A tiny app that reliably solves one annoying problem is more serious than a fake platform full of optimistic menu items.

Use A Scope Reset When The Project Starts Wandering

Even with good rules, projects drift.

You will add something.

AI will misunderstand something.

A fix will create a second problem.

You will get excited.

The app will start developing a second personality.

When that happens, I like to run a scope reset instead of continuing to patch around the confusion.

Use this:

Stop implementing for now.

Compare the current project against the original version-one workflow:
[paste the workflow]

Tell me:
1. where the project has expanded beyond version one
2. which additions are harmless
3. which additions create real complexity
4. what should be removed, postponed, or simplified
5. the smallest path back to the done-when line

Do not change files until I approve the simplification plan.

This is the moment where AI becomes more useful as a thinking partner than as a typing machine.

You are asking it to evaluate the project against the rule, not just keep generating code.

That is a higher-leverage use of the tool.

And it is the kind of habit beginners need most.

The real skill is not getting AI to produce more.

The real skill is getting AI to produce less of the wrong thing.

Your First App Should Feel Narrow On Purpose

If version one feels a little too small, you may be doing it right.

That does not mean it should be useless.

It means the usefulness should be concentrated.

One user.

One workflow.

One clear data shape.

A few screens.

A visible done-when line.

A short exclusion list.

A QA pass that proves the main path works.

That is not a boring app.

That is a controllable app.

And control is what beginners usually need more than imagination.

AI can supply imagination all day.

It can generate feature lists, architecture options, UI variations, launch plans, and future product ideas until your laptop starts to feel like it needs a project manager and a nap.

What it cannot do for you is decide what matters.

That is your job.

So before you ask AI to build, ask it to shrink.

Before you ask for features, ask for exclusions.

Before you accept the screen list, cap it.

Before you trust the data model, make every field defend itself.

Before you call anything done, write the done-when line.

Your first app does not need to look like a startup pitch deck.

It needs to help one person do one useful thing reliably.

That is enough.

That is also hard enough.

Free starter prompts

Full e-book

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 Beginners Should Ask AI More Questions Before Building An App

Marcus Kim — Mon, 22 Jun 2026 18:48:23 +0000

The beginner mistake with AI is not asking a bad first question.

That part is normal.

The real mistake is accepting the first answer as the plan.

You type something like:

Build me an app for musicians to record song ideas.

Then the AI comes back with a confident wall of features, files, stack choices, user flows, auth decisions, database tables, integrations, edge cases, and a UI direction that somehow already has a dashboard.

It feels productive because the answer is big.

But big is not the same thing as clear.

A lot of beginner AI app-building goes sideways because the builder treats the first output like a blueprint when it is really just a guess with excellent formatting.

That is why I ask AI more questions than feels natural.

Before I let it build, I want it to explain the project back to me, argue about scope, name the risky parts, compare options, define what version one is not, and tell me what it would need to know before touching code.

That sounds slower.

It is usually faster than letting the tool sprint confidently into the wrong project.

AI Is Not A Mind Reader With A Code Editor

AI coding tools are powerful, but they are not sitting inside your life.

They do not know which part of the idea matters most.

They do not know your real constraint.

They do not know whether you want a weekend prototype, a client demo, a first App Store submission, a tiny internal tool, or the first brick in a much bigger business.

They will infer.

And if you do not make the project smaller, sharper, and more explicit, they will often infer too much.

That is where the mess starts.

I see this in app-building, freelancing, and my own work with Codex. The tool can move fast enough that unclear thinking becomes expensive almost immediately.

You ask for an app.

It gives you a system.

You ask for a feature.

It gives you a small software suburb.

You ask for a fix.

It patches the visible symptom, then something nearby starts wobbling like a table with one short leg.

The better move is to turn the first conversation into a narrowing process.

If you are at the stage where you have an app idea but do not know what to ask first, I made a free AI App Builder Starter Prompts pack for beginners. It gives you a practical starting sequence for turning a rough app idea into a scoped first build:

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

The important habit is not "use my exact wording forever."

The habit is this:

Do not ask AI to build until you have asked it enough questions to understand what it thinks it is building.

The First Answer Is A Draft, Not A Decision

I like AI most when I treat its first response as raw material.

Not truth.

Not a final plan.

Raw material.

If I ask Codex how to approach a project, I usually do not want it to immediately start editing files. I want a map of the territory.

What is the app trying to do?

Who is the user?

What is the smallest useful workflow?

Which parts are easy?

Which parts are risky?

What needs a decision from me?

What should be postponed?

That last question matters a lot.

Beginners usually ask AI what to include. They do not ask what to exclude.

Exclusion is where scope control starts.

If you are building a musician recording app, version one might need quick audio capture, take names, simple tags, and export.

It probably does not need social sharing, collaboration rooms, AI mastering, public profiles, a marketplace, and a landing page that describes the product as "redefining creative flow."

That phrase should be illegal until the save button works.

The first answer from AI may include all of those things because the tool is trying to be helpful.

Your job is to turn helpful into controlled.

Ask AI To Shrink The Project Before It Builds

One of my favorite early questions is:

What is the smallest useful version of this app that still solves the core problem?

That question changes the conversation.

Without it, AI tends to produce a complete-looking app plan.

With it, AI has to prioritize.

For a beginner, prioritization is more valuable than ambition.

You do not need version one to prove every possible future.

You need version one to prove one workflow.

Try asking:

Here is my rough app idea:
[describe the idea]

Before suggesting code, help me shrink this into version one.

Tell me:
1. the core user
2. the one workflow version one should prove
3. the features I should include now
4. the features I should deliberately postpone
5. the riskiest assumption
6. what "done" should mean for the first build

That prompt does something useful: it makes AI act less like an overeager contractor and more like a project partner.

It also makes you confront the boring truth that good first apps are usually smaller than your imagination wants them to be.

That is not a defeat.

That is how you get something working.

Ask For Tradeoffs, Not Just Recommendations

Another beginner trap is asking AI for "the best" stack, tool, architecture, or path.

Best for what?

Best for speed?

Best for learning?

Best for iOS?

Best for Android?

Best for a web prototype?

Best for a future SaaS?

Best for someone who has never opened Xcode and starts sweating when a terminal window appears?

The word "best" hides your criteria.

So instead of asking:

What stack should I use?

Ask:

Compare three reasonable stack options for this beginner app idea.

For each option, explain:
1. why it fits
2. why it might be a bad fit
3. what I would have to learn
4. what deployment path it implies
5. what future limitation I should know about

Then recommend one option for a beginner version one and explain the tradeoff.

This is how you keep AI from giving you advice that sounds decisive but does not match your actual situation.

I care about this because I did not enter software through the clean front door. I had to piece together my foundation through prerequisite classes, a software engineering master's degree, portfolio work, freelancing, and a lot of trial and error.

That path made me sensitive to a specific kind of beginner pain:

When you do not yet know the vocabulary, every answer can sound equally official.

Asking for tradeoffs helps you build judgment faster.

You start seeing why a choice is being recommended, not just what the recommendation is.

Ask AI What It Is Assuming

This question catches more problems than people expect:

What assumptions are you making about this project?

AI is always making assumptions.

It assumes the user type.

It assumes the feature depth.

It assumes a platform.

It assumes what "simple" means.

It assumes what authentication needs to do.

It assumes whether data is private, shared, public, editable, deletable, searchable, or synced across devices.

Some of those assumptions may be fine.

Some may be wildly wrong.

The problem is that invisible assumptions become visible bugs later.

You thought the app was local-only.

AI assumed accounts.

You thought the first version was one user saving private notes.

AI designed a collaborative workspace.

You thought "events" meant a simple date and location.

AI added invitations, RSVPs, comments, notifications, roles, moderation, and a calendar integration because apparently your weekend prototype needed to apply for zoning permits.

Ask for the assumptions early.

Then correct them before the code exists.

That is much cheaper than fixing them after the project has absorbed the wrong idea into its bones.

Ask For The Done-When Line

The phrase I keep coming back to is:

This is done when...

A done-when line turns a vague build into a testable promise.

Bad:

Build the project screen.

Better:

This workflow is done when a signed-in user can create one project, add a name and description, save it, refresh the page, see the same project, edit it, and delete it without another user seeing it.

That second version is longer, but it is much more useful.

It gives AI a target.

It gives you a QA checklist.

It gives the project a finish line that is not based on vibes.

In freelance work, I like demo-shaped progress for the same reason. A client update is stronger when I can show one new thing a user can do now that they could not do before.

The demo is cleaner when the done-when line is clear.

The code is cleaner too.

Ask For A Plan Before A Fix

When something breaks, the lazy prompt is:

Fix this.

I still use some version of that sometimes because I am a human being and not a laminated productivity poster.

But if the bug is meaningful, I would rather slow down first.

Ask:

Before changing code, explain:
1. what you think is causing the bug
2. which files or flows are likely involved
3. what behavior should be true after the fix
4. what tests or manual checks I should run afterward
5. the smallest safe change you recommend

This is especially important when AI starts making surgical fixes without real progress.

That pattern is easy to miss.

The tool changes one line.

Then another.

Each change sounds reasonable in isolation, but the project is not actually getting healthier.

When that happens, I often ask AI to step back, build a fresh model of how the feature should work, compare the current implementation against that better model, and then recommend a cleaner path.

That is not just debugging.

That is project control.

The free AI App Builder Starter Prompts pack now includes 25 core planning prompts plus bonus build and deployment prompts because the useful AI workflow is not one magic prompt. It is a sequence of better questions:

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

The Real Skill Is Direction

AI can write code.

It can explain code.

It can compare tools.

It can help you debug.

It can make a plan.

It can also confidently build the wrong plan if you do not direct it.

That is why I do not think AI removes judgment.

I think it makes judgment more valuable.

When the tool can move quickly, your questions become steering.

Your constraints become guardrails.

Your definitions become tests.

Your ability to say "not yet" becomes a real technical skill.

This is true for beginners, freelancers, founders, and anyone trying to build software with leverage.

The people who get the most out of AI are not the ones who worship the first answer.

They are the ones who keep asking until the project is small enough, clear enough, and testable enough to build.

A Simple Question Stack For Beginners

If you are about to build an app with AI, start with this:

1. What problem does this app solve for one specific user?
2. What is the smallest useful version one?
3. What should I deliberately exclude?
4. What assumptions are you making?
5. What stack options fit, and what are their tradeoffs?
6. What is the one workflow version one must prove?
7. What does "done" mean in plain English?
8. What could go wrong during build, QA, or launch?
9. What should I test manually before trusting the result?
10. What decision do you need from me before writing code?

That question stack is not glamorous.

It will not make a dramatic screenshot.

It will make your build less chaotic.

And for a beginner, less chaotic is a massive win.

The practical takeaway is simple:

Do not use AI like a vending machine where you insert one prompt and hope a finished app falls out.

Use it like a project partner that needs direction, correction, constraints, and enough questions to stop guessing.

Ask more before you build.

You will usually build less.

That is why the app has a better chance of getting finished.

Free starter prompts

Full e-book

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 QA Checklist I Would Run On Any AI-Built App In 2026

Marcus Kim — Sat, 20 Jun 2026 17:30:00 +0000

The most dangerous moment in an AI-built app is not when the app is obviously broken.

That part is annoying, but at least it is honest.

The dangerous moment is when the app looks done.

The buttons are there. The screens load. The AI says it fixed the bug. You click around for thirty seconds and nothing immediately catches fire.

Then your brain starts whispering the sweetest lie in software:

"We are probably good."

Probably good is not a QA strategy.

It is a tiny trap door with nice lighting.

If you are a beginner building with AI, you need a first QA pass that is simple enough to actually run. Not an enterprise test plan. Not a 400-line spreadsheet created by someone who uses the phrase "quality gate" recreationally.

Just a practical checklist that proves the app can survive normal use, bad input, empty data, account boundaries, and the bugs AI tends to hide while it is "fixing" something else.

The point is not to become a full-time QA engineer before you ship version one.

The point is to stop treating "the AI said it works" as evidence.

The Rule: Test The Workflow, Not The Vibe

When I use AI coding tools, I do not trust the app because the code looks busy.

I trust it more when I can walk through a real user workflow and see the app behave correctly from beginning to end.

That distinction matters.

Beginners often test randomly. They click a few screens, refresh, maybe create one record, and then call the app done because the visible parts seem alive.

But a useful app is not a pile of screens.

A useful app is a workflow.

Someone has a goal. They enter information. The app saves it. The app shows it back. The app handles mistakes. The app protects the wrong person from seeing the wrong thing. The app does not collapse when the user does something slightly inconvenient, like leaving a field blank or using the back button.

That is what you are testing.

If you are still at the stage where you have an app idea but do not know what to ask AI before building or testing it, 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 with AI:

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

For QA, the useful question is not:

"Does the app look done?"

The useful question is:

"Can the user complete the promised workflow without me standing over their shoulder explaining the weird parts?"

That is the first pass.

1. Write The One Workflow You Are Testing

Before touching the app, write one sentence:

A user should be able to [do one specific job] so they can [get one specific result].

Examples:

A musician should be able to record a song idea and tag it by key and tempo so they can find it later.
A car enthusiast should be able to create an event and invite nearby drivers so the group can coordinate.
A freelance client should be able to submit a project request so I can review scope before a call.
A student should be able to save study notes and search them before an exam.

This sentence becomes your QA target.

Without it, you will test the app like you are wandering through a furniture store.

"This button works. This page exists. This dropdown opens. This couch is somehow on sale."

Everything looks like progress, but you are not proving the thing that matters.

You are proving that separate parts exist.

QA starts when the parts are forced to work together.

2. Run The Happy Path Slowly

The happy path is the normal path.

It is what should happen when the user does everything correctly.

For a simple app, the happy path might be:

Create an account.
Log in.
Create a record.
Save it.
Leave the page.
Come back.
Confirm the record is still there.
Edit it.
Delete it.
Confirm it is gone.

Do not rush this.

AI-built apps can fail in boring places. The save button looks like it worked, but the data never persisted. The edit screen opens, but it is editing the wrong field. The delete button removes the item visually, but it comes back after refresh like a software boomerang.

Run the happy path slowly and write down every expectation before you test it.

Good QA sounds boring:

When I create a note called "Practice riff" and save it, I should see it in the notes list after refreshing the page.

That sentence is stronger than "check notes feature."

"Check notes feature" is a fog machine.

Specific expected behavior is a flashlight.

3. Refresh More Than Feels Necessary

One beginner mistake is trusting the screen state too much.

Modern apps can make something look saved before it is actually saved where it needs to live.

So refresh.

Refresh after creating data.

Refresh after editing data.

Log out and log back in.

Close the tab and reopen it.

If it is a mobile app, kill and reopen the app.

You are checking whether the app has real persistence or just temporary optimism.

This matters especially with AI-generated code because the tool may wire up a beautiful interface before the data flow is truly correct.

The screen can be convincing while the backend is silently shrugging.

I want to know:

Does the created data survive refresh?
Does the edited data stay edited?
Does deleted data stay deleted?
Does the list reload from the real source of truth?
Does the app show stale data after a change?

If the answer is unclear, the app is not done.

It is wearing a done costume.

4. Try Empty Inputs

Users do not lovingly fill out every field like they are completing a sacred ritual.

They skip things.

They paste weird text.

They submit forms early.

They type one letter and then get distracted by a microwave beep or the sudden realization that they forgot to respond to an email from four days ago.

Your app needs to handle this.

For every important form, test:

all fields empty
one required field missing
spaces only
very short input
very long input
duplicate values when duplicates should not exist
invalid email formats
weird characters
pasted text with line breaks

You are not trying to be dramatic.

You are trying to find the places where the app assumes the user behaves like the developer.

That assumption is usually false.

AI-generated code can be especially optimistic here. It may build the form, connect the button, and skip the boring validation rules unless you explicitly ask for them.

Ask for them.

Then test them yourself.

5. Test The Empty State

An empty state is what the app shows when there is no data yet.

Beginners forget this constantly because they build while staring at fake sample data.

The app looks great when it has five beautiful placeholder records.

Then a real new user signs in and sees a blank void with a navigation bar.

That is not a first impression.

That is a small abandoned warehouse.

For each main screen, ask:

What does a brand-new user see?
Does the screen explain what to do next?
Is there a clear first action?
Does the app avoid broken-looking blank space?
Does the empty screen match the actual workflow?

A good empty state does not need to be clever.

It just needs to answer:

"What now?"

If your app cannot answer that, the user has to guess.

Guessing is friction.

Friction is where beginner apps quietly lose people.

6. Test Account Boundaries

If your app has accounts, this part is not optional.

You need at least two test accounts.

Not one.

Two.

Account A should not see Account B's private data.

Account B should not edit Account A's records.

Logged-out users should not reach private screens just by typing a URL.

This is where "it works on my machine" becomes dangerous, because your machine is probably logged in as the same test user all the time.

Create two accounts and test:

Can Account A create private data?
Can Account B see it?
Can Account B edit it?
Can a logged-out visitor reach it?
What happens if you paste a private URL into another browser session?
What happens after logout?

Do not rely on vibes here.

Authentication is the bouncer at the door.

If the bouncer is asleep, the furniture arrangement does not matter.

7. Make AI Give You A Test Plan Before Fixing Bugs

When something breaks, the beginner instinct is to paste the error into AI and say:

"Fix this."

That can work.

It can also create a chain of tiny surgical fixes that solve the visible symptom while quietly damaging the larger workflow.

I prefer to slow the tool down.

Before asking for a fix, ask for a test plan.

Use a prompt like this:

I am testing this workflow:
[describe the workflow]

The bug I saw is:
[describe the bug]

Before changing code, explain:
1. the likely causes
2. which files or areas might be involved
3. what behavior should be true after the fix
4. what regression checks I should run
5. the smallest safe fix you recommend

Do not write code yet. Give me the plan first.

This is one of the reasons I include QA and debugging prompts in the free AI App Builder Starter Prompts pack. The useful move is not asking AI to magically fix everything. The useful move is forcing it to name the expected behavior before it changes the project:

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

That step protects you from the AI tool becoming a very confident racetrack for random patches.

Planning before fixing sounds slower.

In practice, it often saves time because you stop turning one bug into three new bugs wearing different hats.

8. Re-Test The Thing That Used To Work

This is the regression pass.

Regression is when a new change breaks something that used to work.

AI can do this very easily because it is often focused on the local task you just gave it.

It fixes the signup bug, but now profile editing breaks.

It fixes the save button, but now the list does not refresh.

It fixes the mobile layout, but now the desktop layout looks like someone folded the page in half and sat on it.

After every meaningful fix, re-test:

the original broken behavior
the happy path
any nearby feature that uses the same data
login/logout if accounts are involved
refresh/persistence
mobile and desktop if the app supports both

This is not glamorous.

It is also where a lot of real software quality lives.

The question is not:

"Did AI fix the bug?"

The question is:

"Did the app still keep its promises after the fix?"

9. Test One Bad Network Or Loading State

You do not need to simulate every disaster for version one.

But you should at least check what happens when loading is slow or data is missing.

Beginner apps often fail because they assume everything appears instantly.

Then the real world arrives with a weak connection, a slow request, a failed upload, or a backend rule that rejects something.

Check:

Does the app show a loading state?
Does the button prevent double-submit when needed?
Does the app show a useful error?
Can the user retry?
Does the app avoid saving half-complete data?

Even one pass here can reveal a lot.

If your app shows nothing while loading, users may click again.

If your app shows a technical error, users may leave.

If your app silently fails, users may think they did something wrong.

Silence is not a user experience.

It is a mystery novel with no ending.

10. Define "Done" In Plain English

Before you call the app done, write a done-when line.

This workflow is done when a new user can create an account, create one project, edit it, see it after refresh, delete it, and confirm another account cannot access it.

That is much stronger than:

Project screen finished.

Finished according to whom?

Finished under what conditions?

Finished until which user clicks which cursed button?

A done-when line gives you a finish line you can test.

It also gives AI a better target. If you tell the tool exactly what done means, it has less room to wander into cosmetic improvements, extra features, or random refactors that do not help the first version.

This is one of the main lessons I keep learning in freelance work and AI-assisted development:

Clear definitions beat heroic effort.

The app does not care how hard you worked.

The user does not care how many files changed.

The workflow either works or it does not.

My First QA Pass, Condensed

If I had to turn this into a simple checklist, I would run this:

1. Write the one user workflow.
2. Run the happy path slowly.
3. Refresh after create, edit, and delete.
4. Test empty and invalid inputs.
5. Check brand-new empty states.
6. Use two accounts and test boundaries.
7. Ask AI for a test plan before bug fixes.
8. Re-test old behavior after every fix.
9. Check one loading or error state.
10. Write the done-when line in plain English.

That is not a complete QA department.

It is a first pass.

But a first pass is much better than the usual beginner pattern:

Click around, feel hopeful, ship, panic.

AI can help you build faster.

It can also help you create a mess faster.

QA is how you slow the project down just enough to keep control.

The practical takeaway:

Do not ask, "Does the app look done?"

Ask, "Can the user complete the promised workflow, recover from mistakes, and trust the data afterward?"

That question will make your AI-built app better immediately.

Free starter prompts

Full e-book

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/

Web App or Mobile App: What Should a Beginner Build First With AI in 2026?

Marcus Kim — Thu, 18 Jun 2026 17:30:00 +0000

One of the first ways beginners make their app harder is by choosing the wrong first platform.

Not wrong forever.

Wrong for version one.

That distinction matters.

If you are using AI to build your first real app, you are already asking your brain to hold a lot at once: the idea, the user, the screens, the data, the stack, the prompts, the bugs, the deployment path, and the little voice in the back of your head asking whether you accidentally built a haunted spreadsheet with buttons.

Then people add one more question:

Should this be a web app or a mobile app?

That question sounds technical, but it is really a scope question wearing a technical jacket.

I like mobile apps. I started in native iOS. I have built iOS projects, worked on a startup social app, managed junior iOS developers, and I am finishing a freelance iOS project now.

So this is not me saying mobile apps are bad.

This is me saying your first AI-assisted build should be judged by the path that gets you to a controlled, testable version one.

If you want a practical place to start, I made a free AI App Builder Starter Prompts pack for beginners who want to turn a rough website or mobile app idea into a scoped first build with AI:

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

That word "scoped" is doing a lot of work.

Most beginner app failures are not caused by bad ambition. They are caused by ambition with no walls.

Start With The User Workflow, Not The Platform

Before you choose web or mobile, describe the first useful thing a user should be able to do.

Not the dream version.

Not the investor deck version.

Not the version where your app has notifications, subscriptions, social sharing, payments, a recommendation engine, a dashboard, three account types, and a settings screen that looks like it escaped from an enterprise SaaS product.

Version one.

Try this sentence:

"A user should be able to [do one specific job] so they can [get one specific result]."

Examples:

A musician should be able to record a quick riff and tag it with tempo and key so they can find it later.
A freelance client should be able to submit a project request so the builder can review scope before a call.
A car enthusiast should be able to create an event and invite nearby drivers so the group can coordinate without losing the plan in chat.
A college student should be able to scan a textbook page and turn it into study notes so they can review faster.

Once you can say the workflow clearly, the platform choice gets easier.

The question is not:

"Do I want this on phones?"

Of course you do. Everyone wants everything on phones.

The better question is:

"Where can I prove this workflow with the least platform-specific friction?"

That is the question AI can actually help you answer.

When I Would Start With A Web App

If you are a true beginner, I would usually start with a web app when the first version can work in a browser.

That is not because web is magically easy.

Web development can also turn into a swamp if you let it.

But web apps have a few beginner-friendly advantages.

First, sharing is easier.

You can send someone a link. They do not have to install anything. They do not have to trust an unknown app on their phone. They do not have to find you in an app store. They click, try it, and tell you where it breaks.

That is valuable when your real goal is learning whether the workflow makes sense.

Second, deployment can be more direct.

A simple web app can often move from local development to a hosted URL faster than a mobile app can move through device testing, certificates, store setup, review requirements, and platform-specific release details.

Third, AI tools tend to have a lot of practical web examples in their training and current working patterns.

You still need judgment. You still need QA. You still need to understand what the code is doing well enough to avoid becoming a passenger in your own project.

But if your app is basically:

forms
dashboards
saved records
search
simple accounts
admin tools
content pages
internal tools
client portals
booking flows

then a web app is often the cleaner first build.

That does not mean it can never become mobile later.

It means you do not have to pay the mobile complexity tax before you know whether the core workflow deserves it.

When I Would Start With A Mobile App

Mobile makes more sense when the phone is not just a smaller screen.

The phone is the actual environment where the job happens.

That is a different situation.

For example, my own product instincts often come from music. I have wanted a simple musician recording app that sits somewhere between Voice Memos and GarageBand on iPhone.

Voice Memos is fast, but not musician-specific enough.

GarageBand is powerful, but too fiddly when I just want to capture an idea quickly.

In that case, mobile is not just a distribution choice. The phone is part of the workflow. The user has the guitar in hand, the idea is happening now, and the app needs to use the device as a quick capture tool.

That kind of idea probably wants mobile early.

Other mobile-first examples:

a camera-based scanner
a location-based field tool
a push-notification habit app
a workout tracker used away from a desk
a simple event check-in tool
a field service app used on-site
a creator tool built around phone media capture

Mobile can be the right first choice when the device capabilities are central:

camera
microphone
GPS
contacts
local notifications
background behavior
offline capture
app-like gestures

But be honest with yourself.

Do you need those capabilities for version one, or do you just like the idea of saying "I am building an app" and picturing an icon on a home screen?

I understand the appeal. It feels more real.

But real is not the same as useful.

A useful browser link beats an imaginary App Store listing every time.

The Trap: Building For The Final Dream Instead Of The First Proof

Beginners often choose the platform based on the final dream.

"Eventually this should be a mobile app."

That may be true.

But eventually is not a build plan.

Eventually is where scope creep goes to put on a nice suit.

If the first proof can be a web app, build the web app.

If the first proof genuinely needs the phone, build the mobile app.

But do not choose mobile just because the final polished version might live there someday.

The first job is not to impress your future self.

The first job is to make the core workflow survive contact with reality.

This is where AI can create a weird kind of confidence problem.

Because AI can produce files quickly, you start thinking every platform decision is reversible and cheap.

Sometimes it is.

Often it is not.

Choosing native iOS, Android, Flutter, Expo, or a web stack affects your data model, authentication flow, payments path, deployment process, testing plan, and maintenance work.

If you make that choice casually, you can spend days untangling a decision you made in five minutes.

Ask me how I know.

Actually, do not. I will start describing build settings and everyone will have a worse afternoon.

A Simple Decision Rule

Here is the rule I would give a beginner:

Start with web unless the phone is essential to the first workflow.

That is it.

Not because web is always better.

Because web is often the shortest path to a testable version one.

Use mobile first when the job only makes sense on a phone.

If your app needs the camera, microphone, location, local capture, push notifications, or a phone-in-hand use case from day one, mobile may be right.

If your app mostly needs accounts, records, workflows, admin views, content, forms, search, and sharing, web is usually a better first proof.

This is also a good place to use AI before you ask it to code.

Ask it to compare the platforms against your specific workflow.

Not generally.

Specifically.

Here is a prompt you can use:

I am a beginner building my first app with AI.

My app idea is: [describe the idea].
The first user workflow is: [describe one complete workflow].
The user needs to complete this workflow in this context: [desktop, phone, on-site, while traveling, during work, at home, etc.].

Compare a web app and a mobile app for version one.

For each option, explain:
- what would be easier
- what would be harder
- what features I should postpone
- what stack you would recommend
- what I should test before calling version one done

Then recommend the simpler first build and explain the tradeoff.

That kind of prompt is exactly why I made the free AI App Builder Starter Prompts pack. The point is not to make AI decide your whole business. The point is to use AI to expose the tradeoffs before you accidentally bury them under code.

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

Do Not Let The Stack Become The Product

One of the funniest traps in beginner software is that the stack starts acting like the product.

You begin with a simple idea:

"I want to help local tutors manage student sessions."

Three AI conversations later, you are comparing five backend services, debating native push notification architecture, asking whether you need microservices, and wondering if your calendar integration should support seventeen edge cases.

The user still cannot book a tutoring session.

But the imaginary architecture is wearing a tiny crown.

This is where my software engineering brain and my entrepreneurship brain agree.

A first app is not only a coding decision.

It is a business decision.

The platform should serve the proof you need.

If the proof is "can users complete this workflow and care enough to use it again?" then your stack should stay boring enough to let you answer that question.

AI will happily help you explore every possible tool. That can be useful. It can also become a very expensive form of procrastination if you never ship the simple thing.

Your job is to keep returning to the workflow.

Who is the user?

What are they trying to do?

Where are they when they do it?

What is the smallest version that proves the app deserves more complexity?

Those questions beat platform vibes.

My Practical Recommendation

If you are a beginner building with AI in 2026, here is the simple path I would follow.

First, write the one-sentence workflow.

Second, ask AI to compare web and mobile for that workflow.

Third, choose the platform with fewer nonessential obstacles.

Fourth, postpone everything that does not prove the core use case.

Fifth, build a version one that someone can actually test.

For many people, that means a web app first.

For some ideas, it means mobile from the start.

The point is not to make a religious decision.

The point is to make a smaller first decision that keeps the project alive.

I think that is the real beginner advantage with AI tools.

You do not need to know every stack before starting.

You do need to ask better questions before building.

When you do that, AI becomes much more useful.

Not because it magically knows your app.

Because you stopped asking it to guess.

The practical takeaway:

Build the platform that proves the workflow fastest.

If the phone is essential, go mobile.

If a browser can prove the idea, start web.

Do not make version one carry the emotional weight of the final dream.

Make it prove one useful thing.

Then earn the next layer.

Free starter prompts

Full e-book

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/

Freelancing Got Easier When I Stopped Carrying the Whole Project in My Head

Marcus Kim — Mon, 15 Jun 2026 23:07:01 +0000

When people imagine freelancing, they usually picture freedom.

Flexible schedule. Working for yourself. Laptop life. Coffee shop mythologies. The usual propaganda.

What they do not picture is the mental load.

That was one of the first things that hit me once I started doing real freelance work.

The coding matters, obviously. But the part that wears you down is not always the code itself.

It is trying to hold the entire project in your head at once.

What did I finish last time?

What broke when I changed that screen?

What does the client still need to see?

Which feature is actually next?

What did we agree on originally?

What was part of scope, and what quietly wandered in through the side door wearing a fake mustache?

That is the kind of stuff that makes a project feel heavier than it technically is.

I am finishing my first major freelance app project right now, and one of the biggest lessons has been that freelancing is not just about doing the work.

It is about building a work system that lets you keep doing the work without turning your own brain into a junk drawer.

That sounds less glamorous than "be your own boss," but it is much more useful.

My early mistake was treating memory like infrastructure

When I first started freelancing, I approached project management in a pretty primitive way.

Part of it was a normal beginner mistake. Part of it was me being optimistic in a slightly stupid way.

I thought if I stayed close enough to the project, I could just remember everything.

The next tasks.

The open bugs.

The half-finished screens.

The client expectations.

The tool setup.

The design details.

The new requests.

The "I will fix that later" list that somehow grows like mold in a damp apartment.

That works for about eleven minutes.

After that, your attention starts leaking all over the floor.

The problem is not that you forget everything.

The problem is that you spend too much energy reloading context.

And context reload is sneaky because it feels like work.

You open files. You scan notes. You click around the app. You reread messages. You try to reconstruct what Past You meant by some vague task like "clean up event flow maybe."

You are technically busy.

But you are not moving.

That is one of the least fun forms of fake productivity.

Freelancing is systems design in disguise

The more I do this, the less I think freelancing is mainly about technical skill.

Technical skill matters. You still have to build the thing.

But day to day, freelancing feels more like systems design.

You are designing:

how you pick the next task
how you preserve project context
how you communicate progress
how you protect the timeline
how you prevent scope from mutating into a swamp creature
how you keep enough momentum to finish

That is true even if you are a team of one.

Especially if you are a team of one.

In my current project, I am handling development, debugging, design coordination, backend management, and client execution. I am using Codex heavily, along with tools like Firebase, Figma, and Xcode.

That setup can be powerful, but only if there is some operating structure around it.

Without a system, AI does not save you from chaos.

It can actually help you produce chaos faster.

That has become one of my strongest beliefs about AI in work generally.

AI is leverage, not order.

If you already have a decent working system, AI can multiply it.

If your workflow is messy, AI can multiply the mess with shocking efficiency.

The biggest upgrade was offloading project memory on purpose

One of the most useful shifts in my workflow was simple:

I stopped expecting myself to carry the whole project mentally.

Earlier on, I used todo lists that Cursor and I would both update and manage. That was better than nothing, but it still depended a lot on me manually holding the thread together.

Now I lean on Codex much more directly for project continuity.

I can sit down, ask where the project left off, see what remains, and pick up the next concrete task instead of rebuilding the whole mental map from scratch.

That matters more than it sounds like it should.

Because when the startup cost of beginning work is lower, you work more.

You hesitate less.

You waste less momentum.

You spend less time doing archaeological fieldwork on your own half-finished app.

I think a lot of people underestimate this part.

They think AI helps because it writes code faster.

That is true, but for me one of the bigger wins is that it helps me preserve and reload context faster.

That is operational leverage.

And operational leverage is what makes consistent output possible.

Meaningful updates beat constant updates

Another thing I had to learn is that communication gets easier when the work is organized around demonstrable progress.

My client communication is intentionally sparse, but meaningful.

We do webcam meetings every so often, and the conversations work best when I have something real to show.

Not a vague status report.

Not a pile of effort.

Not "I was super busy this week."

Something concrete.

A feature that works.

A workflow that completes.

A screen that now behaves correctly.

A user action that was impossible before and is possible now.

That changed how I think about task breakdown.

Instead of trying to move ten pieces at once, I try to complete one use case at a time.

That way each demo answers a simple question:

What can the user do now that they could not do before?

That is a much cleaner unit of progress.

It also reduces my own stress, because "finish one use case" is easier to manage than "make the project generally better."

The second one sounds ambitious.

It is also a good way to drift for six hours and emerge holding three bugs and a broken layout.

Scope creep is not just a client problem

Freelancers love complaining about scope creep, and sometimes that is justified.

Clients really do ask for new features like they are adding fries to an order.

But scope creep is not only a client behavior problem.

It is also a system weakness problem.

If the project does not have clear boundaries, every new idea gets treated like a small adjustment instead of what it often is: new work with new timeline consequences.

I learned this the hard way.

Accepting additional features after the original contract can seriously affect deadlines. Once that starts happening, you either extend the timeline realistically or you pretend time is fake and suffer accordingly.

I recommend the first option.

A lot of freelance pain comes from trying to preserve the fantasy that the original schedule still makes sense after the project changed shape.

It usually does not.

This is another reason systems matter.

A decent system makes scope visible.

It records what was agreed on.

It makes it easier to say, "Yes, that can be added, but it affects timeline and milestones."

That is not being difficult.

That is protecting the project from becoming a wish fountain.

My work got better when I designed the environment, not just the task list

One of the more boring lessons that turned out to be true is that productivity depends a lot on environment.

Not just physical environment, although that matters.

I mean the whole working setup.

How easily can I start?

How quickly can I figure out what is next?

How much friction is there between intention and execution?

Do I have a clean loop for work, QA, and breaks?

Am I building according to spec, or am I improvising a loose scaffold and planning to make it pretty later?

Because that "later" phase is often where the pain begins.

One lesson I really wish I had internalized earlier is to build the UI according to spec first instead of loosely scaffolding and trying to retrofit the real interface afterward.

Redoing views often spills into functionality. Then what looked like a visual cleanup turns into deeper rework.

That is the sort of thing that makes a week disappear.

So now I care a lot more about setting the environment up correctly before I get too far into implementation.

That includes using AI well.

Not as a slot machine for random code output.

As a teammate inside a controlled process.

The practical rule I keep coming back to

If I had to compress this lesson into one line, it would be this:

Do not build a freelance workflow that depends on you feeling perfectly mentally organized every day.

That person does not exist.

At least not consistently enough to run a real business on.

Build a system that catches you when your brain is noisy.

Use tools that preserve context.

Break work into demoable units.

Make scope visible.

Protect your timeline.

Reduce startup friction.

Treat AI as leverage inside a process, not as a replacement for one.

That is the shift that made freelancing feel more real to me.

Less like improvisation.

Less like carrying a piano up a staircase by myself.

More like actually operating.

If you are freelancing now, or trying to start, the practical takeaway is simple:

Stop asking whether you can handle more in your head.

Start building a workflow that does not require you to.

That is usually where the real productivity begins.

Free starter prompts

Full e-book

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/

Your First App Idea Is Hiding in a Group You Already Belong To

Marcus Kim — Mon, 15 Jun 2026 23:06:17 +0000

The worst place to look for your first app idea is nowhere.

That sounds obvious, but it is what a lot of people do.

They sit down, open a notebook, stare into the middle distance, and ask:

"What app should I build?"

That question is enormous.

It is too big. It has no walls. It gives your brain nothing to grab. It is like asking, "What should I do with my life?" while standing in front of a vending machine.

No wonder people freeze.

Then they do the next predictable thing. They start thinking in giant categories.

Productivity app.

Social app.

Fitness app.

AI app.

Marketplace.

Habit tracker.

Budgeting tool.

Those are not bad categories. But they are too abstract to build from. They sound like app-store shelves, not real human pain.

If you are a beginner trying to build your first app with AI, you do not need a vague category.

You need a person.

You need a problem.

You need a situation you understand well enough to notice what is annoying, inefficient, awkward, confusing, or unnecessarily painful.

That is why I think your first app idea is probably hiding inside a group you already belong to.

Start with your groups

Before you ask AI to help you brainstorm an app, make an inventory of your own life.

Not your resume.

Your groups.

The worlds you already live in.

That might include:

hobbies
profession
education
school or institution
culture
religion or community
age group
local area
family situation
health situation
fandoms
subcultures
tools you use every week
weird little workflows you have accepted as normal

This matters because app ideas rarely appear as fully formed lightning bolts.

Usually they start as friction.

Something takes too many steps.

Something is awkward on a phone.

Something works, but only if you use three separate tools and quietly suffer.

Something is built for professionals when you need the lightweight version.

Something is built for beginners when you need just a little more power.

Something almost solves the problem, but misses the way your group actually behaves.

That last one is where interesting products live.

The goal is not to ask, "What app could everyone use?"

The better question is:

"What group do I understand better than a random person, and what problem do people in that group keep working around?"

That is a much better starting point.

My musician problem

I have been a hobbyist musician since my teens, but I started taking it more seriously in my early twenties.

I played in a few bands while getting my undergraduate degree in entrepreneurship in Boise. I kept practicing. I got better slowly. I learned enough piano, drums, guitar, vocals, and now bass to write songs that make sense.

I am not claiming to be a master of every instrument.

But I can write songs.

I can make an album.

I released one in 2026 under my project, Task Manager Not Responding. The first album is lo-fi pop-punk in the spirit of early Blink-182. The next one I am working on is more southern hardcore, influenced by Maylene and the Sons of Disaster.

I record everything at home with my own equipment.

That means I have lived inside a very specific problem:

Recording quick musical ideas on a phone is still annoying.

The serious way to record music is an audio interface and a DAW.

DAW means digital audio workstation. Think Logic Pro, Ableton, that kind of software.

That setup is powerful. It is also heavier than what I need when I just want to catch a riff before it escapes into the fog.

On the other end, there is Voice Memos.

Voice Memos is fast, which is great. But it is not really a musician tool. I want a built-in metronome. I want one-tap file creation. I want one-tap recording. I want exports that work cleanly with proper music software. I want a workflow that respects the fact that the thing I am recording might be guitar, vocals, drums, a melody, or a rough arrangement idea.

Then there is GarageBand on iPhone.

GarageBand is powerful, but on mobile it feels too fiddly for this use case. Too many features mashed into too many menus and submenus. It can do a lot, but sometimes I do not want a mobile studio.

I want a musical scratchpad with a metronome and clean export.

That is an app idea.

Not because I sat down and asked, "What is a hot market?"

Because I am a musician who keeps feeling the same product gap.

The best ideas often live between tools

A lot of useful app ideas live between two tools that almost work.

For me:

Voice Memos is too simple.

GarageBand is too heavy.

The gap is a simple musician-first recording app.

That is a useful pattern.

You can ask:

What tool is too complicated for the quick version of the job?

What tool is too simple for the real version of the job?

What does my group actually need between those two?

That is how you stop building vague apps and start building precise utilities.

And I like simple utility apps.

If I could make every app the way I want, it would have beautiful UI, be colorful, be playful, still be stately enough to take seriously, and actually function. Not decorative nonsense. Not enterprise-gray sadness. Useful first, memorable second, polished throughout.

That is the kind of product taste that comes from living with tools, not reading a trend report.

Intersections make ideas sharper

One group can give you a market.

Two or three groups can give you a sharper idea.

Musician is a group.

College student is a group.

Sports fan is a group.

Each one can produce ideas:

A better metronome app for musicians.

A textbook scanner and summarizer for students.

A sports research app for sports fans.

But now combine them.

What about music majors?

Maybe they need a sheet-music scanner that plays the scanned music back so they can study faster.

What about college sports fans?

Maybe they need a sports research tool focused specifically on collegiate sports, with responsible-use boundaries if betting is involved.

What about college band conductors?

Maybe they need an iPad app for game-day band rosters, practice coordination, football-game reminders, and band-member chat.

The intersection makes the idea less generic.

"Productivity app" is mush.

"Roster and coordination app for college marching band game days" is something you can actually picture.

That matters because AI coding tools are much better when the product shape is specific.

If you say:

"Build me a productivity app."

You are handing AI a fog machine.

If you say:

"Help me design version one of an iPad app for college band conductors to manage game-day roster attendance, send practice updates, and keep the next football-game schedule visible."

Now there is a person.

There is a workflow.

There is a setting.

There is a first version.

There is something to build.

Your lived experience is market research

A lot of beginners discount their own experience because it feels too ordinary.

They think an app idea has to come from some grand strategic insight.

Sometimes it does.

But a lot of good software comes from noticing that a specific group has a specific problem and the current workaround is ugly.

That is market research too.

Not complete market research. You still have to validate. You still have to talk to people. You still have to check whether the problem is real outside your own head.

But your own irritation is a starting sensor.

It tells you where to look.

I belong to a lot of groups that could generate app ideas.

Musicians. Guitarists. Drummers. Singers. Recording artists. Software engineers. Freelancers. Magic: The Gathering players. Comic readers. Self-improvement people. Indie app builders. Working professionals. People in their thirties. People who have been through the "how do I get experience without a job and a job without experience" loop.

Each group has problems.

Musicians have phone-recording friction.

AI builders need to learn how to wrangle coding tools without turning their apps into chaos.

Freelancers need better project-management philosophy, not just another task list.

College graduates have the first-job paradox.

iOS developers may realize too late that launching iOS-first can create painful Android rewrite decisions later.

Those are not random ideas.

They come from living near the problem.

AI can interview you into an idea

This is where AI becomes genuinely useful.

Do not ask:

"Give me app ideas."

That usually produces a list that sounds like it came from a startup name generator that got trapped in an airport business lounge.

Ask it to interview you.

Use something like this:

Interview me about the groups I belong to: hobbies, profession, education, communities, tools I use, and problems I notice. Then generate app or website ideas from problems inside those groups. For each idea, name the user, problem, current workaround, version-one workflow, and why I might understand this market better than a random builder.

That prompt does something important.

It forces the AI to start from your context.

Not general app categories.

Your groups.

Your frictions.

Your unfair familiarity.

Then you can go one layer deeper:

Take my identity inventory and combine groups into intersection ideas. For each idea, give me the target user, pain, existing workaround, version-one workflow, why the intersection matters, platform recommendation, and smallest useful first version. Avoid giant platforms. Favor apps and websites I can test with real people.

That is much better than asking for genius.

You are asking for structure.

The first version should be boringly clear

Once you have an idea, shrink it.

This is where beginners go wrong.

They find one good problem, then immediately add accounts, social features, analytics, recommendations, subscriptions, chat, notifications, admin dashboards, export settings, teams, payments, and a mascot they will regret later.

Do not do that.

For the musician recording app, version one might be:

Open app.

Choose tempo or start without one.

Tap record.

Capture audio.

Name the take.

Add quick notes.

Export the file.

That is enough to test whether the core idea has legs.

No social network for musicians.

No AI mastering.

No marketplace for session players.

No "community layer."

No full DAW.

Just the core workflow.

If that workflow is useful, you earned the next feature.

If it is not useful, the extra features were just decorations on top of a weak foundation.

Good software still needs value

This is one of the biggest lessons I keep relearning in software and freelancing.

Being good at the work is not enough.

Good process is not enough.

Clean code is not enough.

Beautiful UI is not enough.

An app has to deliver value.

You can build a perfectly engineered app that tells users exactly how to open a Starbucks on an asteroid.

The architecture might be beautiful.

The buttons might be tasteful.

The tests might pass.

The deployment might be flawless.

But the value is limited, at least for now.

That is the point.

Software quality matters. I care about it a lot. But quality only matters after the problem matters.

Your first job is not to invent an impressive app category.

Your first job is to find a real human workflow worth improving.

The easiest place to look is inside the groups you already understand.

Final thought

Your first app idea does not need to fall from the sky.

It can come from your practice room.

Your client work.

Your hobby.

Your school.

Your job search.

Your weekly annoyance.

Your group chat.

Your weird little workaround.

Start there.

Inventory your groups.

Find the friction.

Combine identities until the problem gets sharper.

Then use AI to turn that problem into a version-one workflow.

Do not build for everyone.

Build for a person you can picture.

That is where the app starts becoming real.

Free starter prompts

Full e-book

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/

If You Skip the Map, AI Builds You a Maze

Marcus Kim — Mon, 15 Jun 2026 22:59:05 +0000

You can build software faster than ever now.

That is the good news.

The bad news is that you can also build yourself into a disaster faster than ever now.

I see beginners open an AI coding tool, type something like "help me build my app," and then act surprised when the result looks like a confused intern got locked in a supply closet with a keyboard and three energy drinks.

The code exists.

The app technically does things.

But the product is crooked.

The screens do not line up with the real workflow. The data model is half imagined. The features multiply like rabbits. Nothing is tested properly. Every new fix creates a new bug somewhere else. By the time the person notices what happened, they do not have an app. They have a maze.

This is not really an AI coding tool problem.

It is a mapping problem.

One of the biggest shifts AI coding tools create is that code is no longer the main bottleneck for beginners. The bottleneck moves upward. Now the hard part is defining the system clearly enough that the tool can build the right thing instead of a very fast wrong thing.

That sounds less exciting than "AI builds apps for anyone now," but it is the more useful truth.

I use AI coding tools heavily in real work, and the more I use them, the less I think of them as magic code machines.

I think of it more like a very capable builder that still needs a foreman, a blueprint, a materials list, and somebody on site who notices when the bathroom somehow ended up in the kitchen.

That is why I keep coming back to the same operating rule:

Build the map before you build the app.

That sounds obvious until you watch how people actually use these tools.

Most beginners try to jump straight from idea to implementation.

"Build me an app for restaurant bookings."

"Make me a dashboard for my business."

"Create a mobile app for dog walkers."

That is not a software request. That is a business wish wearing a hoodie.

An AI coding tool can help turn it into something real, but only if you give it enough structure to work with.

When I was learning software, that missing structure used to show up later in the process. You would spend hours digging through old Stack Overflow answers, partial tutorials, and documentation archaeology before discovering you did not actually understand the system you were trying to build.

AI compresses that loop.

Now you can generate code immediately, which feels great right up until you realize you generated confusion at high speed.

That is why judgment matters more, not less.

My software background helped me see this more clearly over time. I came into software through a master's program in software engineering, and one of the most useful things it gave me was not just coding practice. It gave me a view of software as process, architecture, verification, maintenance, and tradeoffs.

That matters because beginners usually think software equals code.

It does not.

Software is also:

what the app is supposed to do
what it should not do yet
how data moves through the system
what the first user workflow actually is
what success looks like
what must be tested before you call something finished

If you skip those questions, your AI coding tool will still try to help you. That is the tricky part.

AI rarely says, "This request is too vague, and you are about to waste three days."

It usually says, "Absolutely," and starts producing files.

That is why the beginner mistake is not lack of effort. It is misplaced effort.

People think the work starts when the files start appearing.

Usually the real work starts before that.

On client projects, this becomes painfully obvious.

I am finishing my first major freelance project right now, and one of the biggest lessons has been that building the software is only one slice of the actual job. I have had to manage scope, architecture, backend assumptions, debugging, design handoff, tool coordination, and client clarity, often while being the only person on the project.

That changes how you use AI.

You stop asking for random code chunks and start building a working system around the tool.

You create shared project knowledge.

You define the stack.

You describe the workflows.

You set rules for what "done" means.

You tell your AI coding tool what to verify.

You give it enough context that it can behave more like a teammate and less like a slot machine.

This is the middle ground that a lot of beginners miss.

They think they have two options:

Ask for one tiny tweak like moving a button six pixels.
Ask for a billion-dollar platform by Friday.

There is a much better middle.

Ask your AI coding tool to help you define version one.

Ask it to propose the smallest useful workflow.

Ask it what data model the app needs before building UI.

Ask it what edge cases should be tested before launch.

Ask it what assumptions are still fuzzy.

Ask it to turn your vague idea into a scoped plan with success criteria.

That is where the leverage starts.

Let me make this concrete.

If you want to build a simple booking app, do not start with "build me the app."

Start with something more like this:

"Help me define the version one workflow for a booking app. The user should be able to view available appointment times, pick one, enter their contact info, and receive confirmation. Admins should be able to set availability manually. No payments yet. No team accounts yet. No SMS yet. Show me the required data model, screens, and QA checklist before we write code."

That single shift changes everything.

Now the AI has boundaries.

Now you have a product shape.

Now you can inspect whether the architecture matches the workflow.

Now you can catch overbuilding early.

Now "done" means something.

This is also why I tell beginners not to romanticize chaos.

People love the fantasy that great software is built in some cinematic blur of energy drinks, half-broken prompts, random feature ideas, and heroic all-nighters.

In reality, chaos mostly creates rework.

The better your environment and source of truth, the better your AI outputs get.

The better your rules, the better your iterations get.

The better your QA expectations, the less fake progress you confuse for real progress.

This is especially important because AI makes it easier to get seduced by visible output.

A new screen appears.

A component renders.

A route works.

A button submits.

That feels like progress.

Sometimes it is.

Sometimes it is just a prettier version of the wrong app.

That is where architecture and QA stop sounding boring and start sounding like self-defense.

Architecture is just the decision-making layer that prevents your app from turning into a pile of disconnected conveniences.

QA is just the habit of proving the thing works the way you think it works.

Neither one is optional if you want to build software that survives contact with reality.

And this is where I think AI coding tools are genuinely exciting for beginners.

Not because they eliminate the need to think.

Because they make good thinking more valuable.

You do not need to know everything before you start.

You do not need to become a senior engineer before opening an AI coding tool.

But you do need to learn how to guide the system:

define the problem clearly
shrink version one aggressively
create shared project knowledge
set success criteria
ask for verification, not just generation

That is a learnable skill.

Honestly, it is one of the main skills that matters now.

The future of software is moving closer to English-to-machine execution. I believe that. AI is a landmark shift.

But if more people are going to build software this way, then more people need to understand that prompting is not the whole craft.

Direction is part of the craft.

Scope is part of the craft.

Testing is part of the craft.

Restraint is part of the craft.

If you skip the map, the tool will happily help you build a maze.

If you build the map first, the tool becomes much more powerful.

That is the real beginner advantage.

You do not need to pretend to be an expert.

You need to become a clear director.

That is a much more reachable job.

And it is the one that actually gets apps finished.

If you are new to this, the practical takeaway is simple: before you ask your AI coding tool to build, ask it to define.

Have it help you shape version one, name the assumptions, outline the architecture, and draft a QA checklist.

Then build.

That order saves a ridiculous amount of pain.

Free starter prompts

Full e-book

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/

I Didn't Enter Software Through the Clean Front Door

Marcus Kim — Mon, 15 Jun 2026 19:45:20 +0000

I did not enter software through the clean front door.

I did not grow up as the kid who was building compilers in middle school, casually reading operating systems books for fun, and saying things like "I just love elegant abstractions" while everyone else was trying to survive algebra.

My path was messier than that.

I did not have a computer science undergraduate degree. I did not have the standard foundation. I did not arrive in software with the quiet confidence of someone who had been speaking the language since childhood.

I got into software by deciding I wanted a master's degree in software engineering, then realizing I had to piece together the prerequisite foundation first.

So that is what I did.

I took C. I took C++. I took data structures. I took some Java. I took web development. Not as part of some neat, coherent undergraduate computer science path, but as loose prerequisite work so I could qualify for the program I wanted to enter.

It was not glamorous.

It was a lot of grinding through unfamiliar concepts, staring at errors, re-reading examples, and slowly building the mental shelf space required to understand what software even is.

There was a lot of elbow grease involved.

Enough elbow grease that, if software had not worked out, I probably could have walked into a mechanic shop and started lubricating engine parts through sheer academic residue.

But it worked.

I got through the prerequisites. Then I went through the software engineering master's program at California State University, Fullerton. That program gave me a much broader view of software than just "write code until the computer stops yelling."

I studied software process, software architecture, software verification and validation, software measurement, maintenance, standards, management, and professional issues. The program ended with a capstone project where we had to build software and document the process like actual software engineers, not just people throwing code at a wall and hoping the wall had good taste.

That mattered.

Because one of the biggest mistakes beginners make with AI coding tools right now is thinking the code is the whole game.

It is not.

Code is part of the game. But software is also scope, architecture, data, user flows, testing, deployment, maintenance, tradeoffs, communication, and knowing what not to build yet.

That is the part beginners usually do not see.

And honestly, it is the part I did not fully see at first either.

After I graduated, I did not immediately stroll into a perfect software job. I graduated into the pandemic era and spent about a year unsuccessfully job searching. Then job searching moved to the back burner while I worked an unrelated customer service job.

That period was frustrating.

It is hard to explain the particular flavor of discouragement that comes from earning a software degree, doing the work, building the projects, learning the concepts, and then still feeling like the industry is standing behind a glass wall.

You can see the world you are trying to enter.

You just cannot seem to get through the door.

Eventually, a friend of a friend who worked at Uber helped mentor me through the job search process. Around that same period, ChatGPT showed up, and that changed the way I worked.

Before AI, my programming process looked like the standard developer scavenger hunt.

Search Google.

Open Stack Overflow.

Find a six-year-old answer.

Realize the library changed.

Open documentation.

Find a YouTube tutorial.

Hope the tutorial is not using a deprecated version.

Copy one piece.

Modify another piece.

Read a forum thread from 2014.

Stitch together five partial answers until the thing finally works.

That was normal.

Developers pretend this was noble, but a lot of it was just inefficient archaeology.

AI compressed that loop.

It did not magically make me good at everything. That is not how this works. But it gave me a way to ask better questions faster. It let me compare options, debug errors, explain unfamiliar concepts, rewrite plans, and move through confusion with less dead time.

So I used it.

I built my portfolio. I applied heavily. I started programming in public. I made a 90-video series of myself building a SpriteKit 2D iOS game.

That public work mattered because it turned me from a resume into a person with visible proof of effort.

Eventually, after a long stretch of pushing, I started getting interviews. Then something unexpected happened.

A couple of startup founders found me on LinkedIn. They liked what I had to say about how I would build their product. They hired me, and I built the first version of their event-based social media app.

That project became a serious step forward for me.

The first version was good enough that they gave me equity and brought in two junior iOS developers under me. I ended up managing the iOS side of the project for about five months.

That was the moment where software stopped being only academic for me.

It became product work.

Real scope. Real tradeoffs. Real people. Real ambiguity. Real pressure.

And later, freelancing made that even more obvious.

When you are the only person responsible for a client project, you learn very quickly that "I can write code" is not enough. You have to understand the app as a system. You have to manage the client relationship. You have to make architecture decisions. You have to use design tools. You have to manage backend assumptions. You have to test. You have to explain tradeoffs. You have to keep the whole thing moving even when the path is not perfectly clear.

That is where AI tools became more than a novelty for me.

I started using Cursor, Figma, Codex, backend tools, browser automation, and AI planning workflows as part of the actual work.

Not as toys.

As leverage.

And that is why I care so much about beginners using AI coding tools well.

Because I know what it feels like to start outside the software world and try to build your way in. I know what it feels like to lack the map. I know what it feels like to ask basic questions and worry that the basic question means you do not belong.

But I also know something else now.

Software is becoming more accessible.

Not easy. Accessible.

That distinction matters.

AI does not remove the need for judgment. It does not remove the need for taste, persistence, testing, product thinking, or architecture. If anything, it makes those things more important, because now beginners can generate much more software much faster.

That is powerful.

It is also dangerous if you have no idea what you are asking for.

A beginner with an AI coding tool should not start by saying, "Build me an app."

That is too vague.

Start by building the map.

What is the app for?

Who uses it?

What is the first workflow?

What should version one not include?

What data exists?

What tools are involved?

What does success look like?

What should your AI coding tool verify before it says the task is done?

That is the real work.

The beginner's job is not to become a senior engineer overnight. The beginner's job is to learn how to direct the tool without letting the tool shape the product by accident.

That is why I wrote AI App Builder From Zero.

I wrote it for people who never thought software was accessible to them. People with app ideas. People with small business problems. People who want to build something useful but do not know what a stack is, what a repo is, what a backend does, or what to type into the chatbox after opening an AI coding tool for the first time.

The internet has plenty of information.

Too much, honestly.

Reddit threads. YouTube tutorials. X posts. Documentation. Hot takes. Tool comparisons. Prompt lists. Arguments about frameworks. People confidently disagreeing with each other in public.

That can be useful once you have a map.

But if you are brand new, it can feel like trying to drink from a fire hose while someone keeps changing the hose into a different hose.

Beginners do not need more noise.

They need a first snowball.

Something small enough to pick up, concrete enough to push, and useful enough to gather momentum.

That is how I think about learning software with AI.

You do not need to know everything before you begin.

You do need a working model of what you are doing.

You need shared project knowledge. You need definitions. You need scope. You need rules. You need a way to ask your AI coding tool to plan, build, test, review, and stop.

That is the difference between using AI as a magic slot machine and using AI as a working partner.

My path into software was not clean.

That is probably why I am interested in teaching this.

I do not think the next generation of builders will all come from traditional computer science paths. Some will. Many will not.

Some will come from business.

Some will come from design.

Some will come from operations.

Some will come from customer service jobs, weird side projects, unfinished app ideas, freelance experiments, and late-night conversations with AI tools.

That is good.

Software should have more doors.

AI is opening some of them.

But walking through still requires discipline.

Learn the tool.

Build the map.

Control the scope.

Test the work.

Keep going.

That is the path.

It may not be the clean front door.

But it is a door.

And for a lot of people, that is enough to start.

Free starter prompts

Full e-book

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/