Cut an app idea down to one user, one job and one screen for the first version.
Priya works in an operations team and is building her first real app with a coding assistant. Her first plan was a customer insights platform: staff would log in, upload feedback from email, WhatsApp and the website form, see dashboards by region and week, get weekly AI reports, share them with managers, and pay per seat once other teams wanted it.
She described all of it to her coding assistant. After two weekends she had a login page that half worked, a database with eleven tables, and no summaries. Most first projects that die fail this way, because the builder tries to build too much at once, and seldom because the idea is bad. To finish a first project, you cut the idea down until it can be finished.
A first version should do one job for one kind of user, on one screen if possible. This is the one user, one job, one screen rule.
The user is a specific kind of person, never "anyone", and ideally people you can reach and ask for feedback. Priya picked the team leads in her operations team, five people she sits near and can ask what they think.
The job is the one task your user does that the app makes faster. For Priya it was reading a day's customer feedback and spotting what went wrong. Storing feedback, trend reports and sharing with managers were deferred.
The screen is where the job happens. Priya's version one is a single page with a box to paste a batch of feedback, a button, and a table of results. Each row shows one item's sentiment, issues and one-line summary, using the schema she built in module 2. Nothing else is on the page.
If a version like this looks too small, it is fine as long as it does one useful thing. Real people can use it soon, and Priya's team leads could use hers next week. Their reactions will show her what to build second better than her own guesses would.
For every feature, ask whether the job can be done without it. If yes, it waits. If the job genuinely cannot work without it, it stays. Three features turn up in almost every first plan and almost always belong in a later version:
Accounts and login. Doing these properly is a large job: sign-up, passwords or sign-in with an existing account, password resets, sessions, and keeping each user's data separate. If your first users are a few colleagues, protect the app another way, by running it only inside the company network or using the simple password protection many hosting services offer. Add real accounts when strangers need to use the app. Payments. These bring a payment provider, webhooks, receipts, refunds and tax questions. Nobody will pay for version one anyway, so prove the app is useful first. Settings. A settings page looks small but multiplies quickly: choice of language, choice of summary length, choice of model. Each setting is another path to build and test. Pick sensible defaults and hard-code them instead.
The same question tells you what stays. Priya kept a small server because the API key must be kept on a server, never in the browser. Lesson 1.2, "Keep your API key on the server, never in the browser", explains why. She dropped the database for version one. Results appear in the table and the team leads copy what they need.
A stack is the set of languages, frameworks and services an app is built with. For a first app, pick one that is widely used and well documented, such as a popular web framework in JavaScript or Python with a mainstream hosting service.
AI coding assistants learned from public code, so they write better code for tools that appear in a lot of public code. If you use an assistant with a niche framework released last year, expect more errors, more invented functions that don't exist, and more time debugging. Ask your assistant which stack it would suggest for your app and why, then check that its suggestion is a common one.
Avoid mixing several new things at once. Projects stall when the builder is learning a new framework, a new database and a new hosting service while also building the app. Keep the number of unfamiliar pieces as small as you can.
Describe the app in two sentences: who it is for and what it does for them. This is the two-sentence test. If you can't, or the second sentence keeps growing commas and "and also", the scope is still too big. Writing the two sentences forces the cuts.
Priya's final version passed. She described it as a one-page tool for her team leads, who paste in a day's customer feedback and get a table with sentiment, issues and a one-line summary for each item.
Every feature you remove goes on a written list for later, so it is deferred and kept rather than lost.
For the activity below, take your own app idea through these steps: one specific user you can ask for feedback, one job, one screen, each feature checked against the job, settings replaced with hard-coded defaults, and a common stack with few unfamiliar pieces. Then write your two sentences, saying who the app is for and what it does for them, and under them write the list of features you have cut for later.
Describe your app in two sentences. Then list three features you will leave out of the first version.
Junxiong-WFG Organisation is an authorised representative of AIA Financial Advisers Private Limited (Reg. No. 201715016G).