Scoping your first AI-built app

Last updated 2026-05-31 - 9 min read - By Divyam Chandel - Cohort instructor

A reference for non-engineers scoping a first project for AI builders: how to spot when an idea is too big, the cut-down move, and the five-week shape.

Most non-engineers who try to build with AI fail at the same step. Not the prompting. Not the tool. The scope.

This page is the reference for that step: what to build first, how to know if your idea is too big, and how to cut it down to something a coding agent can actually ship in a few weekends.

The two essays on this site, the standing brief and the verification ladder, are about how to direct the agent. This page is about what to point the agent at in the first place. Scoping is upstream of both.

The two ways first projects fail

Almost every first AI-built project fails in one of two ways.

The first way is the common one. The idea was too big. The non-engineer described “a CRM for my agency” or “an internal tool with a dashboard and a workflow builder and reminders,” and the coding agent took the description literally. Three weeks in, the app has six half-finished features, no working end-to-end flow, and every new prompt breaks something that used to work. The builder gives up. They blame the tool.

The second way is rarer. The idea was small enough but it solved nothing real. The builder shipped a personal to-do list that nobody used, or a calculator with no clear input. The app is technically done. It just does not get opened. The lesson here is harder to see, because nothing visibly broke.

The dominant failure is the first one. Roughly nine non-engineers out of ten who quit do so because their first scope was too big, not too small.

The cut-down move

The single most useful exercise for a first project is to name three things, in this order.

One user. A specific person. Not “sales teams.” Anna, the outbound rep at your company. If the user does not have a name, the scope has not been cut yet.

One workflow. A discrete moment in that user’s day. Not “Anna manages leads.” Anna sees on Thursday morning that lead X has not replied since Monday and needs a follow-up.

One screen. Where the workflow happens. Not “Anna’s dashboard.” A single page that, when Anna opens it, shows her exactly the leads she needs to follow up with today.

If you can write those three lines on a napkin in under two minutes, the scope is workable. If any of the three lines spans more than one item, cut.

Five signals your idea is too big

The signals below show up in nearly every too-big project we see in the workshop. Any one of them is a warning. Two or more is a sentence.

You used the word platform, tool, or system to describe what you are building.
The description has more than three user types in it (admin, customer, partner, etc.).
The phrase “and also” or “and we can add” appears more than once.
The first useful version of the product requires authentication, payments, and a database before any user benefits.
You cannot draw what the user sees on a single sheet of paper.

When any of these fire, cut before you build. Picking a smaller scope at hour one is the cheapest decision in the project.

Categories that work for a first project

The categories below are not exhaustive. They share a structure: one user is reachable on day one, the workflow already exists in another tool or in someone’s head, and the success criteria are visible.

Internal tools. Replacements for a Google Sheet, an Airtable view, or a recurring email that you or a colleague already maintains by hand. The user is reachable. The feedback loop is one day. The data sensitivity is low. The success criterion is that the existing manual workflow disappears.

Personal utilities. A daily-use script for a workflow you currently do in your head. A reading-list extractor. A meeting-notes formatter. A recurring-task checklist that is not a generic to-do list. The user is you, which means the iteration loop is minutes.

Niche calculators or single-input generators. One question in, one answer out. A pricing calculator for a specific service business. A name generator for a specific industry. A regex builder for a specific log format. The smaller the input space, the more concrete the success criterion.

Status boards and intake forms. A single-screen dashboard that shows the current state of one process, populated by a Google Sheet or an Airtable. An intake form that funnels submissions into a structured destination. Both ship in days, both have a real first user.

Categories that do not work as a first project

The categories below share a structure too: they require something a non-engineer cannot verify on day one, or they need a network effect to produce any feedback at all.

Social apps. A network with no users is invisible. Without users, there is no feedback loop. Without a feedback loop, the agent’s work cannot be evaluated.

Marketplaces. Two-sided supply and demand at once is two products to build, not one. The chicken-and-egg problem becomes the unsolvable scoping problem.

Anything that requires payments, authentication, and multi-user state on day one. The combination of Stripe, Supabase auth, and shared database state compounds three fragile systems at once. Non-engineers can ship apps with one of those three. Two is risky. Three is where week four becomes week twelve.

AI-replacing-AI products. A wrapper around an existing model with no distinct workflow has no defensible scope and no first user who cares.

Anything you have never personally felt pain for. You cannot iterate on a workflow you have never used. The early product calls require you to imagine what is wrong, and that is the same as guessing.

The five-week shape

A first project that ships in five weeks tends to follow this rhythm. The rhythm is not the goal, but if any week ends without the milestone below, the project is behind and the scope needs another cut.

Week 1. A working version of the single user flow is visible on the screen. The flow can be ugly. The data can be hardcoded. The point is that the user can complete the one workflow end to end, even with placeholder data.

Week 2. Real data is wired up. Airtable, Supabase, or a Google Sheet is reading and writing. The user can use the app with their actual data, even alone, even without login.

Week 3. The second user can use it, if the project genuinely needs more than one. Authentication is added only if the workflow requires it. Most first projects do not.

Week 4. The one workflow is polished end to end. No broken states. The verification ladder passes for the asked-for flow and at least one unrelated flow. The app feels finished.

Week 5. The app is shared with one real user outside the build process. Feedback is collected. The brief is updated with what was learned.

If week one ends with no visible end-to-end flow, the scope is too big. Cut features, not corners.

Common scoping mistakes

The mistakes below show up across cohorts and pre-cohort workshops with the highest frequency.

The first is treating “MVP” as a smaller version of everything, instead of a complete version of one thing. An MVP that does login, dashboards, settings, and notifications poorly is much weaker than an MVP that does one workflow well and has nothing else.

The second is building for a future user. The user in week one is the user you can talk to in week one. If your real user is a future customer who has not been found yet, the scope is too speculative.

The third is treating the first project as the eventual business. The first project is for learning to direct an agent and to verify work. It is not the company. If the first project happens to grow into the business, that is luck. Plan for it to be practice.

The fourth is underestimating auth and data persistence. Both feel like small features. Both compound complexity faster than any other category of work. If they are not strictly required for the one workflow, skip them in version one.

The fifth is picking a problem you have never faced. The early iterations require you to know what good looks like. If you do not know what good looks like, every prompt is a guess.

Frequently asked questions

The FAQ block in the metadata at the top of this page answers ten common scoping questions, including how to tell if your idea is small enough, what to do if you do not have an idea yet, whether a non-engineer can build a SaaS as a first project, and how to handle authentication, payments, and multi-user state. The answers there are the same advice we give in the Saturday workshop.

Questions

How do I know my idea is small enough to build in five weeks?

Name the one user (a specific person, not a role), the one workflow (a discrete moment in their day), and the one screen where it happens. If you can write all three on a napkin in under two minutes, the scope is workable. If the description spans two screens, three user types, or includes the word platform, cut further before you start.

What if I don't have an idea yet?

Pick a Google Sheet, Airtable, or recurring email thread that you or someone close to you already maintains by hand. The first project should replace existing friction, not invent new value. The fastest path to shipping is choosing a workflow that already exists and that you understand in detail.

Can a non-engineer build a SaaS product as a first project?

Not the full SaaS, no. A first project can be the smallest standalone piece of what would later become a SaaS: one workflow, one screen, one type of user. The full SaaS (auth, billing, roles, dashboards, and integrations together) compounds technical debt faster than a non-engineer can verify changes, and the project stalls in week three. Build the smallest piece first. Sell it. Then expand.

How long should a first project actually take?

For a non-engineer working a few hours a day with a coding agent, the first shippable version of a well-scoped first project takes about four to six weeks. Five is a common landing point. If week one ends and you cannot show a working version of the single user flow on screen, the project is too big and needs to be cut before week two starts.

Should I rebuild something that already exists or invent something new?

Rebuild something that exists. A first project is for learning to direct an agent and to verify the work. Inventing the product idea adds a second unsolved problem on top of the first. Picking a workflow you already use (a personal CRM in Notion, a content calendar in a spreadsheet, a follow-up tracker in your inbox) lets you focus on building, because you already know what the answer should look like.

What if my idea genuinely needs authentication, payments, or multi-user data?

Build the version that does not need those things first. If your idea is a tool for sales reps to track leads, the version-one is a tool for one specific rep, on their machine, with no login. Add auth in version two only after the one-user version is genuinely useful for one week. Most first projects that try to include auth, payments, and multi-user state in week one never reach week four.

Is an internal tool too unambitious for a first project?

No. Internal tools are the highest-leverage first project category for non-engineers. The user is reachable (you, a colleague, a friend), the feedback loop is fast, the data sensitivity is low, and the success criteria are concrete. Most consumer apps fail on day one because there are no users. An internal tool has at least one user from the first commit.

Should I show my idea to anyone before I start building?

Yes, but the conversation is short. Find one person who would use the smallest version, describe it in one paragraph, and ask whether they would use the smallest version specifically. Do not ask whether they would use the eventual full version. The answer to the full version is almost always yes and almost always wrong.

What if the AI keeps adding features I didn't ask for?

Two fixes. First, write a what-this-product-is-not list at the root of your project (see /learn/claude-md) so the model has explicit negative scope it has to honor. Second, ask for the smallest implementation of each change, name the files that should not be touched, and run the verification ladder after every change. Scope drift in the agent is a downstream symptom of unclear scope from you.

What if my first project succeeds and I want to add a second feature?

Treat the second feature as a separate scoping exercise. Name a new user (often the same person on a different day), a new workflow, a new screen if needed. The brief you wrote for version one stays. The new work goes on top. Do not start by rewriting the version-one brief; add to it.