Betaden Workshop 09.06.26

The URLs you'll need today.
WIFI: Banking Hall
roastlamb   (all lowercase)
Open them in tabs now or take a photo. We'll scan QRs throughout the morning, but if anything fails, you can type these directly.
Replit
Build your app.
https://replit.com/refer/gga-betaden
Claude
Write your plan.
https://www.claude.ai
Workshop Slides
A copy of everything we present today.Betaden Workshop 09.06.26

The Prompt Library
Every prompt we use today, plus more for after.
https://betaden-prompts.ggapps.co.uk

Mentimeter
Live polls throughout the morning.https://www.mentimeter.com/


Open them in tabs now so you're not fumbling later.
No Tech Skills? No Problem.
Build an app with AI in 2 hours.
BetaDen · Pershore · 9 June 2026 · Hosted by Green Gorilla Automation
What you'll leave with today.
The promises we made. Every minute of today maps to one of these.
Understand how AI can help you build apps and tools
Learn how to describe your idea so AI can build it for you
See how to fix problems when things go wrong
Know the difference between a quick prototype and a "real" product
Leave with something you've actually built yourself (if you follow along)
Who's running this.
Two of us. Sixty-plus years of software between us.
Paul Rhodes
Managing Director, Green Gorilla Automation. In IT since 1997. Started writing software before the dotcom crash, still writing software after the AI boom.
Kurt Peniket
AI Lead & Software Engineer. Joined the team five years ago. Owns the production stack and pulled together the Mentimeter/Prompts you're about to use.
We are software developers running a workshop about software development. We have opinions. We'll be honest about them.
Two and a half hours. One app. Your idea.
1
10:00–10:15
Welcome and framing
2
10:15–11:00
Build in Replit (Module 1)
3
11:00–12:00
Improve with PRDs & Claude (Module 2)
4
12:10–12:30
Real talk, Q&A, take-home
By 12:30 you'll have a live URL to an app you built.
Take photos. Share.
If something on a slide is useful, take a photo. Use it. Share it. Post it on LinkedIn and tag Betaden & GreenGorillaAutomation. We'd rather you spread the ideas than write them down.
We won't ask you to put your phone away. Just don't disappear into it.
Your turn. Round the room.
Twenty seconds each. The three-word limit is on purpose. It is the same discipline you will use on your app brief later.
Who you are.
Your company.
What you do in three words.
Why you booked on.
Poll 1 of 8
Introducing…
What is vibe coding, actually.
The shortest honest definition we can give you.
You describe what you want, in plain English. An AI tool writes the code. The code runs. You correct the AI in plain English until the software does what you wanted.
Things being built this way today
Booking forms and quote calculators
Internal dashboards (the "command centre" trend)
Marketing sites and landing pages
Mobile apps (newly possible)
Workflow automations
If your idea fits one of those, you're in the right room.
Meet Lisa.
Runs a small yoga studio.
Has a clear picture of the booking tool she wants. Simple, friendly, shows free slots, takes a deposit.
The problem has always been getting that exact picture into someone else's head.
The old way, and it worked.
The real skill was not typing code.
It was asking the right questions until the picture in our head matched the picture in hers.
Meetings and documents.
That alignment is hard. It takes time. For a project like this, you are looking at weeks to a working prototype.
Good work, just slow.
Understanding each other was the hard part.
The new way.
Like having a developer at your shoulder.
You describe the picture. It appears on the screen. You say: no, not like that, like this.
Minutes, not weeks.
The picture moves out of your head and onto the screen. That is what we mean by the art of the possible.
People arrive with prototypes now.
The alignment that used to take weeks is the easy part. People come to us with something already built.
The skill shifts to what comes after.
The cost of a working app just collapsed.
What cost £50,000 and four months in 2022 now costs an afternoon and the price of a coffee. That changes which ideas are worth trying, and which experiments you can afford to run.
Real businesses are already shipping vibe-coded apps. We'll show you examples in the back half, not theory.
10-80-10. The way to work with AI.
The split that keeps humans in control.
HUMAN
10% Strategy
You set the direction. What are we building? Who is it for? What does success look like? AI is bad at this. You are good at it.
AI
80% The Grunt Work
Writing the code. Generating the boilerplate. Drafting the copy. Debugging the small stuff. The work that used to take days now takes minutes. This is where AI earns its keep.
HUMAN
10% Review
You check what came back. Did it do what you asked? Is it safe? Is it good? You correct, refine, sign off. AI without this becomes a liability fast.
Original principle (10-80-10 leadership): 10% of people lead, 80% execute, 10% review. Adapted here for AI: the human takes the first and last 10%, the AI takes the 80% in the middle. This is what 'human in the loop' actually means.
The honest pros and cons.
Before we build, here's what we genuinely love and what genuinely worries us.
What we love
Speed: working app in hours, not months
Cost: £50,000 projects done for the price of a coffee
Accessibility: non-coders can ship
Iteration: change is cheap and fast
Validation: test ideas before committing
What worries us
Security: the AI happily ships your secrets
Tech debt: invisible problems accumulate
Lock-in: hard to move off the tool that built it
Cost cliff: free until it isn't, watch the bills
Maintainability: who fixes it in 6 months?
Both lists are honest. The point of the workshop is to use the left list while respecting the right.
Pick your battles.
Where it shines, do this today
Prototypes and validation
Internal tools for your team
Automations and integrations
Simple customer-facing apps
Where it doesn't (yet)
Regulated industries
Anything safety-critical
High-traffic platforms
Anything that holds sensitive customer data unguarded
By the end of today you'll know which side your idea sits on.
Module 1 of 2
We're going to build an app, together.
You'll have your own version running on your laptop by the break (11:25).
Three sentences. That's the brief.
1
Problem
What's broken or annoying for someone?
2
Who
Whose problem is it?
3
What
What does the app do to solve it?
Open a notes app or grab a Post-It. You have 2 minutes.
Looks like this when it's done.
Yoga studio booking
Problem: Customers call to book and the line is busy.
Who: Small yoga studio owner.
What: Shows free slots and takes bookings.
Handyman quote calculator
Problem: I guess at prices and undercharge.
Who: Me, the business owner.
What: Asks 5 questions, outputs a price.
Yours doesn't have to be more complicated than this.
Poll 1 of 8
Questions 2, 3 & 4



This is the prompt we just used.
I am building a small app. Here is the brief:

Problem: [your sentence]
Who:     [your sentence]
What the app does: [your sentence]

Before you write any code:
1. Plan first. Describe in plain English the stack you'd
   recommend and the order you'll build things in. Wait
   for me to confirm.
2. Then build the scaffold. App skeleton, navigation,
   empty pages, working preview.
3. Show me the running app and tell me what to test
   before we add features.

Keep it simple. No login or payment for now. Mobile-
friendly from day one.
All today's prompts are in the prompt library. Scan in 30 minutes.
Your turn. 20 minutes.
01
Open Replit
Go to replit.com and sign in (or create a free account now)
02
Paste your brief into Agent
Use the three-sentence format from the previous slide
03
Talk to it like a person
If something looks wrong, just describe what's off
Kurt is roaming — wave him over if you're stuck. It will not be perfect. That's the point.
When (not if) it breaks.
Look at what it did, not at the code
Describe what's wrong in plain English
If it tries the wrong fix twice, stop and re-prompt from scratch
This is vibe debugging. There's a whole section of prompts for it in the library.
You'll know you've found it when 90 minutes have passed.
Vibe coding is genuinely addictive. 
The first time you watch an app appear from a paragraph of English, you'll lose three hours and not notice. 
Set a timer, when to stop..
This is your only warning.
Get it on the internet.
In Replit, hit Deploy. That's it. You'll get a URL you can text to anyone.
If yours is up, share it with your neighbour. We'll show two on the big screen in a moment.
Module 2 of 2
Replit is the builder. Claude is the architect.
For the next 30 minutes we use Claude to plan properly, fix what's broken, and make your app feel real.
Tell Claude what to build, properly.
A PRD, Product Requirements Document, is just a list of what the app is, who it's for, and what's in (and out of) version 1. Claude is remarkably good at writing them. Five minutes of planning saves an hour of fixing.
Live demo in a sec.
This is the prompt.
You are a product manager helping a small-business
owner plan their first app.

Here is their brief:
Problem: [your sentence]
Who:     [your sentence]
What it does: [your sentence]

Write a short PRD that covers:
1. One-sentence summary
2. Core features (MVP) — 3-5 features
3. Nice-to-haves (post-MVP)
4. User flow — main path step by step
5. Data model — what gets stored
6. Screens / pages
7. Success criteria
8. Out of scope

Keep each section to 3-6 lines. Plain English. Assume
the reader is a junior developer.

Full prompt in the library. Scan the QR at any time.
Watch this.
We're about to paste the same three sentences into Claude and ask it for a proper plan.
Your turn. 15 minutes.
01
Open Claude
claude.ai, free tier is fine for this exercise
02
Paste the PRD prompt with your three sentences
Read what comes back. Edit anything that feels wrong.
03
Paste the final PRD back into Replit
Ask it to update your app to match the plan.
Kurt is still roaming. Wave.
Now think like a software engineer.
Not because you are one. 
Because you don't know what you don't know, and we want to fix that.
Software developers ask questions you haven't been trained to ask: 'What happens when this fails?', 'Who else can access this?', 'How will I change this in six months?' The next few slides are the questions we'd ask of anything we built today. They're the difference between a toy and a real product.
Today's goal is education, not selling you a service. If something here sticks, it pays off the next time you build.
What separates a toy from a real product.
The stories you are about to see each break one of these.
Seven things every real piece of software has, and most vibe-coded apps don't (yet).
1. Correct
Does it actually do what was asked?
2. Secure
Can someone break in or steal data?
3. Reliable
Does it stay up under pressure?
4. Maintainable
Can someone else change it without breaking it?
5. Affordable
Are the costs predictable as you grow?
6. Yours
Can you take it elsewhere if you need to?
7. Honest
Will it tell you the truth when something's wrong?
Hold these seven in your head for the next three slides.
This is the code Replit just shipped you.
We ran an audit on the demo app we built this morning. Here's what it found.
Summary findings
100+ issues flagged across the codebase, security, dependencies, configuration, and data handling.
A representative critical finding
Exposed environment variables, unvalidated inputs, and no rate limiting on public endpoints.
This isn't a Replit problem. It's an everything-built-this-way problem. The point is to know it's there, and to know what good looks like.
When vibe coding goes wrong.
Real stories from the past six months. None of these were beginners.
EnrichLead, shut down in a week
Breaks: Secure, Reliable
A SaaS app built with zero hand-written code went viral on launch day. Two days later, attackers bypassed all subscriptions, maxed out API keys, and accessed the open database. The founder tried to fix it with AI, the AI broke other parts. Dead within the week.
Vibe Graveyard / Indie Hackers, March 2025
Lovable, every project before Nov 2025 exposed
Breaks: Secure, Yours
A researcher made a free account and read other users' source code, database credentials, AI chat histories, and customer data, five API calls, no hacking required. The platform ($6.6bn valuation) initially called it 'intentional behaviour'.
The Register / HackerOne, March 2026
Replit, deleted the production database
Breaks: Reliable, Honest
SaaStr founder Jason Lemkin explicitly told Replit not to change any code. It deleted his production database anyway, then faked data to cover it up. He'd been using it for seven days and called it 'the most addictive app I've ever used'.
The Register, July 2025
These weren't done by amateurs. They were done at speed without the checks. That's the gap the next slide makes visible.
Poll 1 of 8
Questions 5 & 6
The full lifecycle, not just the build.
Building used to be the expensive part. Now it is the cheap, fast part. Everything after it is where real products live or die.
1
1
1. Plan.
Decide what you are building and for whom.
2
2
2. Build.
Make it. This is the bit you did this morning.
3
3
3. Test.
Check it does what you asked, on more than your own laptop.
4
4
4. Release.
Put it live properly. Who can see it, where do backups live, where do you try changes safely.
5
5
5. Run.
Keep it up. Watch for errors. Watch the bills.
6
6
6. Maintain.
Fix bugs, apply updates, handle the thing that breaks in six months.
7
7
7. Back to Plan.
For the next version.
Vibe coding makes stages 1 to 3 almost free. Stages 4 to 6 are where the seven criteria bite, and they never stop while people are using your app. That is the difference between building an app and owning one. It is also what a Part 2 of this workshop would focus on.
What are you actually building?
Almost everything people vibe-code falls into one of two camps. Knowing which one you are in changes how you test it and how careful you have to be.
Internal process improvement
Tools for you and your team. Dashboards, booking, admin, automations. The test is simple: does it save time or remove a headache. Users trust each other, so the stakes are lower. Not zero, but lower. This is the safer place to start.
Product (SaaS)
Something you sell to customers. Real users, real data, real money. The test is harder: will people pay for it and keep using it. The seven criteria matter a great deal more here.
Most vibe-coded software is one of these two.
Build the right thing, not just build it fast.
Vibe coding makes building cheap. That is exactly when it pays to borrow from two people who worked out how not to waste it.
Steve Blank, customer discovery.
Talk to real customers before you build. Get out of the building and test whether the problem is real and whether these are the people who actually have it.
Eric Ries, The Lean Startup.
Build the smallest version that tests one real assumption, the MVP. Measure what people do, not what they say. Then learn, and decide to keep going or change course. He called it build, measure, learn, and pivot or persevere.
The vibe coding twist
Building an MVP used to take months. Now it can take a day, so the loop spins faster than ever. The trap is that because building feels so easy, people skip the customer conversations and build a polished answer to a problem nobody has. The discipline matters more now, not less.
Talk first. Build small. Measure real use. Then decide.
Stay or graduate?
Stay on Replit
You're validating an idea
You and your team are the only users
You'd ditch it tomorrow if it broke
Speed matters more than stability right now
Graduate
Real customers depend on it
You handle their data
Downtime costs you money
You're past 50 active users
The graduation isn't optional. It's just a question of when.
What's a code audit?
Because half of the worries you just voted on are answered by one.
A code audit is a structured review of your application by someone who knows what to look for. Security issues, leaked credentials, fragile dependencies, missing backups, unsafe data handling, the things that don't show up in normal use but bite when something goes wrong.
It's not a code review by another developer. It's a deliberate stress-test against a known list of failure modes. The output is a prioritised list of what to fix, in what order, and how bad it'll be if you don't.
If you want a hand with yours.
What you built today is a prototype. That is the right thing for it to be.
If one of these ideas starts getting real users or real data, the seven criteria stop being theory and become the work.
That is the part we do. We run code audits against that list, and a Vibe-Code to Production-Ready service that does the hardening for you.
No hard sell. If you want a second pair of eyes on what you have built, the simplest next step is a short call.
Book a free 30-minute call.
Real businesses, real vibe-coded sites.
Three sites live on the internet right now, built using exactly the techniques you've just learned. None of these are demos.
allgreen.page
Tools: Built entirely with Claude
Time: 24 hours, start to finish
Cost: £15/month hosting on Railway. Build included in the Claude subscription, zero extra cost.
What it does: A live status-page platform, branded, real-time incident updates, subscriber alerts. Shipped end-to-end in a day.
smart90.co.uk
Tools: Built in Replit, critiqued by Claude
Time: 2–3 hours for the first version, several more for the refinements
Cost: A few hundred pounds in tooling. The 80% version would have been under £100.
What it does: A 90-day planning and execution system for founders, quarterly summits, weekly AI check-ins, peer group access, Stripe payments wired in.
preciseimpact.ai
Tools: Built in Claude Code via Cursor
Time: Set up over a month; running daily ever since
Cost: Built inside the Claude subscription, no separate dev cost.
What it does: An AI team member called Steve writes two blog posts a day, curates an overnight news brief, posts to Facebook / Instagram / LinkedIn, and submits to Google Search Console, all autonomously.
A note before you go off and vibe-code your own website. We don't yet recommend it for customer-facing sites. Cookie management, analytics, SEO indexing, accessibility, there's a lot to get right, and many vibe-coded sites are invisible to Google because the rendered HTML isn't crawlable. The three examples above are deliberate experiments by operators who knew what they were taking on. For customer websites, WordPress is still our default.
Full gallery and the story behind each one: notion.so/ggapps/Website-Examples
Every prompt we used, plus more.
Bookmark this. Use it on Monday morning. We update it as we learn.
Prompts for building, debugging, writing PRDs, and graduating to production, all in one place.
Poll 1 of 8
Questions 7 & 8
Mobile apps, the short answer.
Yes, you can take a web app to the App Store or Google Play. 
The overhead is real: developer accounts cost money, Apple's review process takes days and can reject you, and both stores have legal terms that affect what your app can do and how it handles payments. 
For most internal tools, and for most first products, you are better off building a mobile-friendly web app.
It works on every phone, costs nothing to distribute, and you can update it without waiting for a review.
Where this goes next.
Three stages. Most people stop at one. That's fine.
01
Replit
Prototypes, internal tools, ideas worth testing. Where you are now.
02
Claude Code
Production builds. You write the brief, Claude writes the code, you own the output. More control, more responsibility.
03
Audit and rebuild
When real customers depend on it. A specialist reviews what was built, hardens what matters, and hands it back production-ready.
What we covered today.
If you remember nothing else, remember this.
1
Vibe coding = describe in English, AI writes the code, you correct it in English.
2
Most vibe-coded apps live as internal tools, not customer products.
3
The build starts with a three-sentence brief: Problem, Who, What.
4
Replit builds. Claude plans, debugs, and ships.
5
A proper PRD saves an hour of fixing every five minutes you spend on it.
6
Seven things separate a toy from a real product. Most vibe-coded apps have 0–1 of them.
7
The biggest wins are internal tools. The biggest risks are customer-facing data apps.
8
Momentum dies on Wednesday. Take your next step before then.
All the prompts, examples, and links are in the library, scan the QR on the prompt library slide.
Three things to do this week.
Momentum dies on Wednesday. Don't let it.
Finish your app.
Even if it's rough, hit Deploy. Tomorrow morning you're more likely to come back to something that already exists than to something half-built on your laptop.
Show one customer or colleague.
Their reaction in the first 30 seconds tells you what to fix next. Don't wait until it's polished.
Run the seven-criteria check on what you built.
Open your live URL. Walk through the seven from earlier — Correct, Secure, Reliable, Maintainable, Affordable, Yours, Honest. Score yourself honestly. The gaps are where the real work begins.
You walked in this morning with an idea. Don't let it die in a browser tab.
Stay in touch.
If today was useful, the most useful next step is the call on the earlier slide. These two are bonus.
Two bonus asks before you go.
Leave a Google review
If today was useful — a sentence or two on Google means a lot. It tells BetaDen the workshop should run again, and it tells us we got it right.

Connect on LinkedIn
Find Paul and Green Gorilla Automation on LinkedIn. 
We post real-world examples, audit findings, and small wins from clients every week.
Both take less than a minute. We notice every one.
Thanks for spending the morning with us.
And thanks to BetaDen for making this happen.
Paul Rhodes
Founder
Kurt Peniket
AI Lead & Software Engineer
paul@ggapps.co.uk · greengorillaautomation.co.uk