
Every prompt we used at the BetaDen Workshop, plus a few more for after.
BetaDen x Green Gorilla Automation
Kidderminster · 21 May 2026
Pershore · 9th June 2026
These prompts are templates. Square-bracketed bits like [INSERT IDEA] or [BUSINESS TYPE] are placeholders, replace them with your own words before pasting into Replit or Claude. They are not part of the prompt; they are instructions to you.
Each prompt has a one-line "use this when..." above it so you can scan and find the right one fast. You do not need to read this from front to back. Jump to the section you need.
The workflow: prompts in sections 1, 2 and 3 chain together. Start with an idea (Section 1), turn it into a PRD (Section 2), then feed the PRD to Replit (Section 3). Sections 4 onwards are for when something goes wrong or you want to take things further.
Straight from Replit's official prompting docs. The whole library follows these.
"Build a website" is vague. "Build a portfolio site with Home, About, and Contact sections in a clean modern style" works. The more detail you give, the less the AI has to guess.
Ask the AI to describe what it is going to do before it does it. Approve the plan, then say go. This one habit saves more time than anything else.
Do not ask for a complete app in one prompt. Ask for the scaffold, then add one feature at a time. Smaller steps = fewer surprises.
Source: docs.replit.com/tutorials/effective-prompting
Before you build anything, make sure the idea is worth your time. Three prompts to find, pressure-test, or sharpen an idea before you spend a single minute in Replit.
Use this when: You know your business has tedious tasks but no specific app idea yet.
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.Use this when: You have an idea but you are not sure if it is worth building.
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.Use this when: Your idea is fuzzy and you need to nail it down before writing a PRD.
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.A PRD is the brief you give Replit. A good PRD means Replit builds what you asked for. A bad PRD means weird inventions and burned credits. Three prompts to write, check, and trim your brief.
Use this when: You have a clear idea and want a structured brief Replit can consume.
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.Use this when: You have a draft PRD. Before you hand it to Replit, find the gaps.
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?Use this when: Your PRD is too ambitious for the time you have actually got.
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?Four prompts to get from PRD to working app, without burning credits on weird inventions. Follow them in order: scaffold first, mobile second, then features one at a time.
Use this when: You have a PRD. You are ready to scaffold the app. This is the most important prompt in the library.
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 yetUse this when: After the scaffold is built, make sure the app works on a phone.
Make 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.Use this when: The app is just for you and your team. No public users, no need for accounts.
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.Use this when: Every time you want to add a new feature to a working app.
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.When (not if) something breaks. Five prompts, pick the one closest to your situation. You do not need all five; just find the one that matches what you are looking at right now.
Use this when: The app runs, but it is behaving wrong, not crashing, just not right.
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.Use this when: A wall of red text appeared. You have no idea what it means.
I got this error. Please explain what it means in
plain English, then fix it:
[paste error message exactly as it appeared]Use this when: You have asked it to fix the same thing three times. It keeps doing the same thing.
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.Use this when: Nothing changed on your end. Something changed somewhere else.
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.Use this when: That last change made things worse. Go back.
Undo the last change you made and put the app
back to how it was before.Visual changes work best when you describe the feeling, not the technical detail. Two prompts, one for the overall feel, one for a specific element that is annoying you.
Use this when: The app works, but it looks wrong for your audience.
Make the app look more [professional / playful /
clean / trustworthy / minimal].
Keep the same content and layout, just change
the styling.Use this when: One thing on the screen is annoying you and you want to fix just that.
Make the [button / heading / form / menu /
card] [bigger / less cluttered / a different
colour -- describe in words].
Do not change anything else.Getting it on the internet. Replit usually handles this with a single button, here is the prompt for when the button does not work, or you want to be certain it is done correctly.
Use this when: The Deploy button is not working, or you want to be sure the app is properly public.
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.Use this when: You own a domain (yourbusiness.com) and want the app to live there instead of a replit.app address.
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.One prompt to plan a v2 once your v1 is in the wild and people are using it. Do not build v2 until v1 is live and you have heard from at least one real user.
Use this when: V1 is live. People are using it. You are getting feedback. Now what?
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.When real customers depend on the app and downtime costs you money, this is the prompt for the honest conversation about going production-ready. Most people only need this once, but it is worth knowing it is here.
Use this when: You have gone past the prototype. Real users depend on it. Time to find out what needs to change.
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.Open your live URL and score yourself honestly against these seven.
The gaps are your to-do list. If a low score worries you, that is the moment to talk to someone.
Use this as your index. Scan the Stage column, find where you are, and jump to that section.
Thanks for spending the morning with us at Betaden. The fact that you are reading this means the workshop did its job.
If you get stuck or want a second pair of eyes on what you built, book a call. The link is on the production slide.
Green Gorilla Automation
paul@ggapps.co.uk
We update this library as the tools change. The link does not change, bookmark it once and re-scan whenever you need it.
BetaDen · Kidderminster · 21 May 2026 · Green Gorilla Automation
Vibe Prompt Library