
I run a [BUSINESS TYPE, e.g. small accountancy practice /
online clothing brand / two-vehicle haulage business].
My biggest weekly time-suck is [DESCRIBE THE TASK].
I spend roughly [HOURS] per week on it, and the parts
that frustrate me most are [SPECIFIC FRUSTRATIONS,
e.g. copying data between systems, chasing the same
questions every week, hand-formatting spreadsheets].
Help me think about whether this task could be solved
by a small app. Walk me through:
1. What an "ideal" version of this workflow looks like
2. What inputs and outputs the app would need
3. Whether this is a real candidate for a small app,
or whether I should just buy an off-the-shelf
tool instead
4. If it is a candidate, what the simplest possible
first version would be
Be honest. If an app is not the right answer, tell me.I have an idea for a small app:
[DESCRIBE THE IDEA IN ONE OR TWO SENTENCES].
Help me pressure-test this idea before I commit time
to building it. Specifically:
1. Who exactly would use this and what problem does
it solve for them?
2. What is the simplest version that would still be
useful?
3. What existing tools already solve this (and why
might mine be different)?
4. What could go wrong -- what makes this idea harder
than it looks?
5. On a scale of 1-10, how clearly defined is this
idea right now, and what is the one thing I should
clarify next?
Be honest. If the idea has holes, tell me where
they are.I want to build something that does
[VAGUE DESCRIPTION].
Help me sharpen this. Ask me 5-7 questions to clarify
the problem, the user, and what success looks like.
After I answer, write me a single-sentence problem
statement in this format:
"For [SPECIFIC USER], who [SPECIFIC PROBLEM], my app
provides [SPECIFIC SOLUTION], unlike
[EXISTING ALTERNATIVE]."
Then stop. Do not write any code yet.I want to build a small app. Here is the idea:
[INSERT IDEA OR PROBLEM STATEMENT FROM SECTION 1]
Write me a product requirements document (PRD) I can
give to an AI coding tool like Replit. The PRD must
include:
1. One-sentence summary -- what the app does and
who it is for
2. Core features (MVP) -- the 3-5 features the app
absolutely needs
3. Nice-to-haves (post-MVP) -- features for later,
not version 1
4. User flow -- the main path a user takes through
the app, step by step
5. Data model -- what gets stored, what the main
"things" in the system are
6. Screens / pages -- what views the user sees
7. Success criteria -- how I will know the MVP
is working
8. Out of scope -- what the app deliberately does
NOT do
Keep each section to 3-6 lines. Use plain English.
Assume the reader is a junior developer who has never
seen my business before.Here is a draft PRD for a small app I want to build:
[PASTE PRD]
Review it as if you are a senior product manager.
Specifically:
1. What is unclear or ambiguous? Where would a
developer have to guess?
2. What is missing? Is there a hidden assumption
that needs to be made explicit?
3. What is over-scoped? Which features should be
cut from the MVP?
4. What is under-scoped? Is there something
fundamental I have not thought of (e.g. login,
payments, data export, mobile)?
5. If you had to ask me three questions to sharpen
this PRD, what would they be?Here is my full PRD:
[PASTE PRD]
I have [TIME -- e.g. 4 hours / one weekend / two weeks]
to build the first version, and I want to show it to
[AUDIENCE -- e.g. my business partner, one early
customer, my team].
Cut this down to the smallest version that is still
useful and demonstrable. For the MVP:
- Which features stay?
- Which features get deferred to a v2?
- What can I fake or hard-code for the first demo
(e.g. dummy data, manual processes) rather than
actually building?
- What is the riskiest assumption I should test
first?I am building a small app. Here is the PRD:
[PASTE PRD]
Before you write any code, do this:
1. Plan first. Describe in plain English the tech
stack you would recommend, the main pages, the
data model, and the order you will build things
in. Wait for me to confirm before writing code.
2. Then build the scaffold. Once I confirm, build
the basic structure: app skeleton, navigation,
empty pages, data model, working database
connection. Do not add features yet.
3. Show me the running app and tell me what to test
before we add the first feature.
Important constraints:
- Mobile-friendly from day one (responsive layout,
no horizontal scroll)
- Use Replit's hosted Postgres database, not
in-memory storage
- Do not add login or authentication unless my PRD
asked for it
- Do not add any features beyond what is in the PRD
- Keep the styling clean and minimal -- do not spend
time on visual polish yetMake sure this app works well on a phone. Specifically:
1. All pages should be readable and usable on a
360px-wide screen (typical mobile)
2. Buttons and tap targets should be at least 44px
tall
3. Forms should use the right mobile keyboards
(email, number, phone)
4. No horizontal scrolling at any width
5. Test the layout at three widths: mobile (360px),
tablet (768px), desktop (1280px)
Do not redesign anything -- just make the existing
layout responsive.This is an internal tool that only I (and maybe my
team of [NUMBER] people) will use. We trust each
other. I do not want to spend time on login screens,
password resets, or account management.
Build the app so it:
1. Skips all login and authentication
2. Has a single "Settings" page where I can paste
in any API keys or credentials it needs
3. Uses Replit Secrets for any sensitive values
4. Has no public-facing signup page
I will restrict access by keeping the Replit URL
private and sharing it only with the people who
need it.The app currently works. Do not change anything that
is already there. I want to add ONE new feature:
[DESCRIBE THE FEATURE -- e.g. "Let users export the
contact list as a CSV file"]
Before you change anything, tell me:
1. Which files you will need to edit
2. What new files (if any) you will create
3. What you will add to the database (if anything)
4. How I can test it once you are done
Wait for my "go ahead" before writing code. If you
spot a problem with my idea, say so first.The app is doing [DESCRIBE WHAT IT IS DOING]
but I want it to do [DESCRIBE WHAT YOU WANT].
[Optional: paste error message OR describe what
you see on screen.]
Please fix it without changing anything else.I got this error. Please explain what it means in
plain English, then fix it:
[paste error message exactly as it appeared]Stop. The last [N] attempts have not worked.
Let's start fresh. The behaviour I want is:
[describe in plain English].
The current behaviour is: [describe].
Do not change anything else in the app.
Walk me through what you think is wrong before
you change any code.The app worked yesterday. Today it is broken
with this behaviour: [describe].
Please look at the most recent changes and tell
me which one likely caused it before you fix
anything.Undo the last change you made and put the app
back to how it was before.Make the app look more [professional / playful /
clean / trustworthy / minimal].
Keep the same content and layout, just change
the styling.Make the [button / heading / form / menu /
card] [bigger / less cluttered / a different
colour -- describe in words].
Do not change anything else.Deploy this app so I have a public URL I can
share. Use the simplest deployment option.
Tell me the URL when you are done.I own the domain [yourdomain.com]. Walk me
through how to point it at this Replit
deployment, step by step.
Assume I have never set up DNS before.Here is what my app does today: [describe].
Here is what I am hearing from users / what I
want next: [describe].
Give me a list of 5 things I could build next,
ranked by impact-to-effort. For each, tell me
roughly how big a change it is.I built this app on Replit using vibe coding.
It works but now real users depend on it. I want
to understand what needs to change before I trust
it with real business data.
Please give me a checklist covering:
1. Security and credentials
2. Data backup and recovery
3. Environment separation (dev / staging /
production)
4. Monitoring and alerting
5. Tests so future changes do not break what works
For each item, tell me what good looks like, what
the bad version is, and roughly what it would cost
a small business to fix.