A practical guide to going from idea to a simple working app you can launch and test. Written out in full. No
videos. No fluff.
Idea Clarity
App Brief
Build Prompt
Launch Basics
Most people who try to build their first app with AI get stuck in the same place — not because the technology
is hard, but because they jumped in before they had a clear idea of what they were actually building.
They skip the thinking. Start prompting before the idea is clear. End up with something that looks like an app
but doesn't quite do anything useful — and then don't know where to take it next.
This mini course walks through the full process, step by step.
Eight lessons. How to choose a good first idea, keep the scope simple, write a proper brief, build it with
AI, get it live, and find your first testers.
It's honest, practical, and free.
Read it top to bottom. Then build.
The 8 Lessons
LESSON 01
The Foundation
Why Most People Build the Wrong First App — And How to Avoid It
You can build a working app in a weekend with AI. That part is real. But building is actually the easy part
now.
The hard part is choosing the right thing to build. Most first-time builders get excited about an idea, open a
tool, start prompting — and end up with something that looks good but doesn't quite fit any real need. It's
not a bad effort. It's just the wrong starting point.
The gap between a finished app and a useful one is almost always in the idea, not the code.
Get the idea right first, and everything after it gets easier.
The Most Common First-App Mistakes
Building something technically interesting that nobody actually needs. Trying to build for everyone, which
usually means the app doesn't quite fit anyone. Picking an idea that's too big to finish as a first version.
And starting to build before you've thought clearly about what the app is actually supposed to do for a
specific person.
Most first-time builders follow this path: idea → build → launch → hope. A better path is:
idea → clarify → keep it simple → build → test. The clarify and simplify steps don't take long. They
just take honesty about what you're actually making and for who.
What changes when you start with a clear idea
Every build session moves in a clear direction instead of in circles.
The first version is smaller, faster, and actually finished — instead of a permanent work in progress.
You have something real to test and learn from, instead of something that's almost ready but never quite
there.
LESSON 02
Market Research
How to Map an Entire Market in One Afternoon Using AI
Before AI, market research meant buying reports, crawling forums for hours, and hiring consultants. That's
over. You can now map a full market — buyers, problems, competitors, gaps, opportunities — in under two hours
with five prompts.
Run these in order. Each one zooms in closer.
Prompt 1 — Market Snapshot
Act as a senior market research analyst specialising in digital products and SaaS. Give me a complete
overview of the [MARKET] space, covering: 1. Who the main buyers are and what they typically spend on tools
2. The top 5 existing products and their price points 3. The most common complaints and unmet needs across
buyer reviews 4. Any underserved niches or audience segments 5. Where buyers in this space typically gather
online
Prompt 2 — Pain Excavation
Based on the [MARKET] space, list the 10 most painful recurring problems that buyers face that existing
tools don't fully solve. Rank by: (a) how often the pain occurs, (b) the cost when it goes unsolved, (c) how
likely buyers are to pay to fix it.
Prompt 3 — Niche Drill-Down
List 8–10 specific audience sub-niches within [MARKET] where a solo builder could create a focused tool and
dominate. For each, estimate: — Approximate audience size — What they currently pay for (tools,
subscriptions, hiring) — Where they spend time online — The biggest unmet need right now
Prompt 4 — Trend Radar
What are 5 shifts — in technology, platforms, buyer behaviour, or business models — creating new needs in
[MARKET] that didn't exist two years ago? For each trend, describe what type of new tool it could justify
building.
Prompt 5 — Idea Generator
Based on all of the above, suggest 5 specific SaaS app ideas for [MARKET] that: — Solve a specific repeated
problem for a clearly defined audience — Could be built by one person in under 4 weeks — Could realistically
charge $29–$149/month — Have a clear path to the first 10 paying customers
AI research gives you direction, not truth. Cross-check the most important findings on Reddit, G2, Capterra,
and App Store reviews.
Real complaints in real reviews are the most reliable signal you can find without talking to customers
directly.
LESSON 03
The Idea
The Best First App Is Usually a Boring One — Why Simple Beats Clever Every Time
The app ideas that feel exciting to build are usually the hardest to actually finish and get people to use.
Big, complex, ambitious — and perpetually "almost ready."
The apps that tend to actually get finished, used, and grown are usually the boring ones. A specific tool that
handles one annoying task for one type of person. Not exciting to describe at a dinner party. But very
practical to build and very easy to explain to the right person.
A good first app has four things in common. If yours has all four, you're in a good position.
Four signs a first app idea is worth building
It's useful, not inspiring. A specific task that has to happen every week — onboarding,
invoicing, following up, reporting — and it's annoying every time it's done manually.
Missing it has a real cost. A missed follow-up means a lost client. A late invoice means
cash problems. When the problem has a dollar cost, the value of your tool is easy to explain.
It's built for one specific type of person. Generic client management has 200 competitors.
Onboarding for online course creators — almost none. The more specific you go, the less competition and the
easier it is to reach the right people.
Nobody finds it exciting enough to build. Which is exactly why it's often wide open. You
can own a simple, focused niche in ways you could never compete in a flashy one.
The best first app is often the one that solves a boring problem someone is currently solving with a free
spreadsheet.
— Keep It Simple
A simple idea audit: List 3 types of people you have real access to — freelancers, coaches,
consultants, small business owners. For each, list 5 tasks they do every week that are repetitive and
annoying. Score each one: how often it happens, how much it costs when it goes wrong, how specific the
audience is. The highest scorer is your starting point.
LESSON 04
Validation
How to Test Your Idea Before You Spend Too Much Time Building It
Before you build, it's worth spending a little time checking whether the idea is actually something people
want. Not to get permission — just to avoid building something for weeks and then finding out it doesn't quite
land.
This doesn't have to be complicated. Run these four steps in order. Even getting through the first two will
tell you a lot.
1Talk to 5 people. Find 5 people who match the person you're building for. Don't pitch.
Just ask: "How do you currently handle [the problem]?" If they shrug or change the subject — that's useful
to know. If they rant for ten minutes about how annoying it is — you're on to something.
2Ask what it's worth. Once they've described the problem, ask: "If something handled this
automatically, what would that be worth to you?" You're not committing to a price — you're just
calibrating. Their answer tells you a lot about how real the pain is.
3Build a one-page description. Write up the problem and your solution in plain language.
No code yet. Show it to a few people. See if they get it immediately. If you have to explain it three
times, the positioning needs work — and that's much easier to fix before you've built anything.
4Try a waitlist or early access offer. If you want to go further — put up a simple page
and invite a few people to join a waitlist. Real signups from people who don't know you personally is a
good early signal that the idea is worth building.
The "Everyone Says It's a Great Idea" Trap
When you describe your idea, people will almost always say it sounds great. Friends, followers, people in
online groups. This feels encouraging. It doesn't mean much. People are kind. They're picturing the best
version of your idea. The more useful signal is whether they ask questions, share a problem they have, or
want to be involved. Enthusiasm without any action is just noise.
The goal here isn't to prove the idea is perfect before you build. It's just to make sure you're building in
roughly the right direction. A few honest conversations before you start can save you a lot of building in the
wrong direction.
Want help getting a first version built? The next four lessons walk through the full build
process. But if you'd rather do it with someone alongside you, that option is below.
Stop Prompting Like a Tourist — The Brief That Makes AI Build What You Actually Want
There are two kinds of people building apps with AI. The first gives short, vague prompts and keeps
re-prompting as the output drifts further from what they wanted. The second briefs the AI like a contractor —
specific, structured, clear — and gets it right in fewer passes.
The difference is the brief. Fill this in before you touch any tool:
Master App Brief Template
I am building an app for [specific person in a specific situation]. Their core problem is: [exact pain,
described in their own words]. After using this app, they will: [specific outcome — what changes in their
day/week]. The app should feel: [3 adjectives]. The app should NOT feel: [3 adjectives — the anti-brief].
The v1 screens are: [list every screen, in user journey order]. Tech stack: React + Tailwind, Supabase,
Stripe, Vercel. Explicitly out of scope for v1: [list features you are NOT building].
Once the brief is written, add it to your Vision Codex — one living document with your
one-line pitch, your user profile, your screen list, your business model, and your brand feel. Paste the
relevant section at the top of every major prompt going forward. The AI will make decisions that match your
intent instead of just guessing.
The 4 Phrases That Cut Re-Work
"Don't change anything else." — End every prompt with this. Without it, AI makes nearby changes it
thinks are helpful. These compound. After 10 unscoped prompts, you have an app that doesn't quite do
anything you planned.
"Tell me every file and function this will affect before you change anything." — Use this before
touching existing features. Forces the AI to plan first.
"Only change [X]. Leave everything else exactly as it is." — When fixing one specific thing. Keeps
every change contained.
"What's the minimum change needed to get [outcome]?" — Stops over-engineering. AI often proposes a
complex fix when a simple one works fine.
LESSON 06
The Build
The Foundation Prompt — How to Build a Complete Working App in One Pass
Your first build prompt is the most important one you'll write for this project. It sets the structure
everything else gets built on. Get it right and every prompt after it builds cleanly. Get it wrong and every
new feature creates a conflict somewhere.
A strong first build prompt has five parts, in this order:
The Foundation Prompt — Use This Once, At the Start
// CONTEXT I am building a SaaS app called [App Name]. It helps [specific user] to [core outcome] without
[specific pain]. It should feel: [3 feel words]. It should NOT feel: [3 anti-words]. // TECH STACK Stack:
React + Tailwind CSS. Database and auth: Supabase. Payments: Stripe. Deploy target: Vercel. Colour palette:
[hex codes]. Font: [font name]. // SCREENS (v1 only, in user journey order) [List every screen by name] //
DATABASE SCHEMA [Paste your pre-designed schema here — tables, columns, relationships] // INSTRUCTION Build
the complete foundation: all screens scaffolded with navigation working, Supabase connected, login/signup
functional, visual style consistent throughout. Do not add any features or screens not listed above. When
complete, confirm what was built and list any assumptions made.
After the foundation build: click every screen, test every button, check every edge case before your next
prompt.
The AI sometimes changes things you didn't ask it to change when fixing something you did. Catch these
immediately — before you build another layer on top — and your build stays clean.
The Build Order That Works
Foundation prompt — all screens scaffolded, navigation working, Supabase connected.
Core feature — one screen at a time, one prompt each, ending with "don't change anything else."
Auth — its own prompt: login, signup, logout, and protected routes. Nothing else.
Stripe — its own prompt: pricing screen, checkout, webhook, subscription status in Supabase.
Polish pass — visual consistency across all screens. No new features.
The Most Common First-Build Mistakes
Prompting without the Vision Codex — you get something that looks like an app but fights you on every next
step. Asking for too much in one go — "build the full app with all features including payments and
notifications." The AI produces something unstable. Scope the foundation to navigation, screens, and auth
only. And never move to the next prompt without clicking through the previous output first.
LESSON 07
Ship It
Don't Ship Broken Things — Domain, Security, and the Launch Checklist
Your app works on your machine. That's not the same as it working for real users, on real devices, with real
internet connections. This is the unglamorous part that turns a demo into an actual product.
Domain in 20 minutes. Buy from Namecheap or Cloudflare Registrar. In your Lovable or Bolt
project, click Deploy — connect GitHub, Vercel creates a deployment. In Vercel: Settings → Domains → Add your
domain. Go to your registrar DNS settings, add the A record and CNAME Vercel shows you. Done. HTTPS provisions
automatically.
Environment variables — don't skip this. Every secret key (Supabase API keys, Stripe secret
key) goes in Vercel's environment variables. Never in your code. Never in GitHub. If you ever paste a secret
key directly into code "just temporarily" and push it — bots scrape GitHub continuously. Leaked Stripe keys
get charged to your account.
Run This Before Every Launch — Full RLS Audit
Review my Supabase database schema and generate complete RLS policies for every table that contains user
data. Schema: [paste your table list and columns] For each table, generate policies for: — SELECT:
authenticated users can only read their own rows — INSERT: authenticated users can only insert rows with
their own user_id — UPDATE: authenticated users can only update their own rows — DELETE: authenticated users
can only delete their own rows Flag any tables that should be publicly readable and generate the appropriate
open SELECT policy for those.
Without Row Level Security, any logged-in user can read every other user's data by querying the table
directly.
This is not a rare edge case. It is the default Supabase state if you don't enable RLS. Run the audit
before you tell anyone the app is live.
☐Custom domain live at https://yourdomain.com — padlock active in browser
bar.
☐All environment variables in Vercel production settings — no test keys,
nothing hardcoded.
☐RLS enabled on every user data table. Two accounts cannot see each other's
data.
☐Real payment completed with a real card. Webhook fires. App updates. Stripe
in live mode.
☐Tested on iPhone Safari. No horizontal scroll. No broken layouts.
☐Privacy Policy and Terms of Service pages accessible from footer.
☐Sentry error monitoring installed and receiving test events.
LESSON 08
First Testers
How to Get Your First Test Users and Early Feedback
Getting your first few people to try your app is not a marketing problem. It's a conversation problem. You
don't need a launch campaign or a big audience. You need to personally reach out to a small number of the
right people.
Your first testers will almost always come from direct messages — not posts, not SEO, not ads. Ten to twenty
targeted conversations with real people who have the exact problem you built for. That's the whole playbook
for the first version.
Four simple messages that work:
Script A — Warm Network (Personal DM)
Hey [Name] — hope things are going well on your end. I've been building something for the past few weeks and
I'm looking for a handful of [freelancers / coaches / consultants] to be my first real users and tell me
what's broken. It solves [the exact problem in their language]. Takes about 10 minutes to try the core
thing. No sales pitch — genuinely just want eyes on it from people who'd actually use something like this.
Would you be up for a quick look?
Script B — Community Response (Reply to a Post)
Saw your post about [specific problem they described] — I've been dealing with the same thing with my
clients for years. I actually built something to handle exactly this. It's brand new and I'm looking for
feedback, not sales — would you be willing to take a look and tell me what you think? Happy to share the
link if you're curious.
Script C — Cold Email / LinkedIn
Subject: Quick question for [freelancers / coaches] Hi [Name], I noticed you're a [their role] — I'm running
an experiment and I need your help for 10 minutes. I'm building a tool to [solve specific pain] and I'm
looking for 5 more people to test it and tell me what's wrong before I launch. No pitch. No follow-up sales
sequence. Just honest feedback from someone who'd actually use this. Worth a look? [Your name]
Script D — Follow-Up (Send Once, 5–7 Days Later)
Hey [Name] — just bumping this up in case it got buried. Still looking for a few [their role] to try this
before I launch. Happy to share what I've learned building it if you're curious. No worries either way.
Warm outreach (people who know you) tends to get a 15–25% reply rate. Cold outreach gets 5–10%. To get 10–15
testers you only need 20–30 messages. That's very doable in a few days if you're reaching the right people.
What to do with early feedback
Watch what they actually do, not just what they say. If testers say they love it but never
use it again, that's important information. If they keep coming back and bring it up unprompted — that's a
real signal.
Ask one simple question after they try it. "What was confusing?" or "What did you wish it
did?" One clear question gets better feedback than a long survey.
Don't build everything they suggest. Your job is to find patterns. If three different
people struggle with the same thing, that's worth fixing. One person's feature request is just one opinion.
The goal at this stage is simple: get ten real people to try it, listen to what happens, and decide whether to
keep building, adjust the idea, or start something different. That clarity is worth more than a polished
launch to an audience you haven't built yet.
What Comes Next
If you've made it this far, you have a real roadmap.
Idea clarity. A simple brief. The build prompt. Security basics. And a plan for getting your first
testers.
That's a complete first-version process — and it's all here for free.
But reading it and actually doing it are two different things.
The part where most people slow down is the middle of a build — something doesn't work, the scope creeps, and
what felt like a weekend project quietly turns into a month of half-finished work. Having someone alongside to
help you choose the idea, keep the scope tight, and get unstuck when things break makes a real difference.
If you want help getting your first version built, that's what the sprint is for.
Want help? I'll build it with you — or for you.
48h Mini App Sprint. First Version. Done.
You bring the idea and the app brief. I help you keep it simple, build it properly, and get a first
version live and ready to test. By the end of the sprint you have a clear, working app and a practical
next step.
🔨
I Build It For You
You bring the brief. I build the full first version — live domain, working core feature, auth and
database set up cleanly. A real working app without you writing a single prompt.
🤝
We Build It Together
Side by side over 48 hours. You drive, I co-pilot — helping you choose what to build, reviewing
prompts, keeping scope simple, and getting unstuck when things break.
Earnings Disclaimer: We don't believe in get-rich-quick programs. Results shown or discussed
are not typical and are not a guarantee of what you will achieve. Your results will depend on your effort,
your idea, and how you execute. Nothing on this page is a promise of income or financial outcome.