Assume I have no technical experience and I have never done this before.
Here is a screenshot of exactly what I'm seeing. Tell me exactly what to
click or type next, one step at a time.

Here's a prompt template from my build guide. Fill in the bracketed
placeholders using what you already know about my project (check
SPEC.md and the codebase if you need to). Then treat the filled-in
version as the actual instruction and carry it out.

TEMPLATE:
[paste the full template from the checklist here]

Phase 0 — Ideation & validation

Before you build anything, know what you are building and for whom. Budget: 1 evening. Cost: free.

0.1 — Write your one-sentence idea. Complete this sentence on paper: "My platform helps [WHO] to [DO WHAT] so that [BENEFIT]." If you cannot fill it in one sentence, you are not ready to prompt anything.

0.2 — Define your core loop. What is the ONE repeated action users take? (For HVNG: create/join a hang.) Write it down.

0.3 — Stress-test the idea with AI. Have the AI attack it before the market does:

Act as a brutally honest startup advisor. Here is my idea: [ONE-SENTENCE IDEA].
The core user action is: [CORE LOOP].
1. List the 5 biggest reasons this could fail.
2. List 3 existing products that partially solve this and what they miss.
3. Tell me the "cold start problem" this specific idea will face on day one
   (a social platform is only valuable when full, but starts empty).
4. Suggest the smallest possible version 1 that still proves the idea.
Do not flatter me. I want the version of this conversation that saves me
six months.

0.4 — Decide your platforms NOW. Web only, or web + iOS + Android? This decision goes into your very first architecture prompt — cross-platform parity is a day-one decision, not a bolt-on. Recommended answer for a social product: all three, one React codebase.

0.5 — Check the name. Search it on Google, Instagram/X, and a domain registrar. Confirm the .com or a good alternative is available. Do not fall in love with an unavailable name.

0.6 — Know your budget. Reference running costs for this whole stack: AI subscription (~$20/mo), Vercel (free tier → ~$20), Supabase (free tier → ~$25), Resend (free tier → ~$20), domain (~$10–15/YEAR). You can start on free tiers for almost everything except the AI subscription. Verify current prices — they move.

0.7 — Research the laws of your sector. One afternoon of reading now prevents jail or bankruptcy later:

I am building [IDEA] targeting users in [COUNTRY]. List the legal and
regulatory areas I must research before launch: data protection, age
restrictions, payment regulations, sector-specific rules, and anything
else. For each, tell me the specific law or regulator by name and the
one-paragraph plain-language summary of what it requires of a small
platform like mine. Flag anything that could get me fined or shut down.
This is research guidance, not legal advice — I will verify with a lawyer.

✅ Phase 0 complete when: you have a one-sentence idea, a named core loop, a platform decision, a budget number, and a list of the laws that touch you.

---

Phase 1 — Workspace setup

Install your AI engineer and open the rooms you've been avoiding. Budget: 1–2 hours.

1.1 — Create a Claude account (or OpenAI account if using Codex) and subscribe to a plan that includes the agentic coding tool.

1.2 — Open a GitHub account. This feels like being marched to the dentist. The dread is about the room, not the task — walk in. Use a serious username; it will be visible in your project URLs.

1.3 — Install the prerequisites. You need Node.js and Git. Always use the live docs, not a screenshot from a blog:

Assume I have no technical experience. I am on [WINDOWS / MAC].
Give me the exact step-by-step instructions to install Node.js, Git,
and Claude Code on this machine, including how to verify each one
installed correctly by typing a command in the terminal.

1.4 — Open the terminal for the first time. The black screen is just a place to give clear instructions — the same skill as everything else. Copy commands exactly, read what comes back, paste anything confusing back to your AI.

1.5 — Make a project folder named after your project (lowercase, no spaces).

1.6 — Start Claude Code inside that folder and say hello:

This folder is the home of my new project, [PROJECT NAME]. I am a
non-technical founder and you are my senior engineer. Before we write
any code, confirm you can see this folder, and tell me what you can
and cannot do in this environment.

✅ Phase 1 complete when: Claude Code runs inside your project folder and answers you.

---

Phase 2 — Architecture & specification (the foundation)

Do NOT build screens yet. Excited beginners decorate a house with no foundation. Budget: one focused session.

2.1 — Brain-dump everything. Pour out every feature, platform, and requirement you can think of. Do not organise — that is the AI's job.

2.2 — Generate the architecture and spec document. This is the most important prompt of the whole journey. You are not an architect — outsource the expertise. Use the AI to brief you for the AI:

Act as a senior software architect helping a non-technical founder.

MY PRODUCT: [PASTE YOUR BRAIN-DUMP — what it does, who it's for, every
feature you want, how you imagine people using it]

REQUIREMENTS:
- Platforms: web, iOS, and Android from ONE codebase (React / React
  Native via Expo). Cross-platform parity is a day-one requirement:
  every function must work on every platform.
- Must be scalable from day one — assume it succeeds.
- Must follow security best practices: no secrets in code, Row Level
  Security on all personal data, refresh-token rotation.
- Privacy by design: user emails are private credentials, never public
  identifiers. Users get usernames/display names.
- Data storage must be efficient: image size caps, modern formats
  (WebP), paginated queries.
- Affordable: built on Vercel (hosting) + Supabase (database, auth,
  storage) free tiers, upgradeable later.
- Must support web push notifications (VAPID) and mobile push later.

PRODUCE:
1. A full feature list, split into MUST-HAVE (version 1) and LATER.
2. A simple data model in plain language: every table, what it stores,
   and how tables relate (e.g., "a user has many posts").
3. The recommended technical approach and folder structure.
4. Security and privacy best practices specific to this product.
5. A list of everything I forgot to ask for that a product like this
   will need. Design for where I am GOING, not just where I am.

Explain everything so a smart non-technical person can follow it.

2.3 — Interrogate the output. For every term you don't know:

Explain [TERM] to me like I'm a smart person who has never coded.
Why does my product need it? What happens if I skip it?

2.4 — Trim version 1 ruthlessly. If the must-have list has more than ~6 features:

This v1 list feels too big. Cut it to the absolute minimum set of
features that still lets a user complete the core loop:
[YOUR CORE LOOP]. Move everything else to LATER and tell me why.

2.5 — Save the document as SPEC.md in your project folder:

Save this entire specification as SPEC.md in the project root. From now
on, treat SPEC.md as the source of truth for what we are building.

✅ Phase 2 complete when: SPEC.md exists, you understand every section of it, and v1 is small enough to actually finish.

---

Phase 3 — Scaffold the first working prototype

Build directly on the professional stack — no training wheels, no migration later. Budget: 1–3 sessions.

3.1 — Scaffold the project:

Read SPEC.md. Scaffold this project now:
- Next.js (React) for the web app, structured so we can add React
  Native / Expo for mobile later without rewriting.
- Prepare for Supabase as database, auth, and storage (we will connect
  the real project in the next phase — use placeholder environment
  variables for now, never hardcoded values).
- Set up the folder structure from the spec.
- Create a .env.local file for secrets and a .env.example file showing
  which variables are needed WITHOUT their values.
- Create a .gitignore that excludes .env.local, node_modules, and
  build folders, so secrets never reach GitHub.
Then tell me how to run it locally and what I should see.

3.2 — Run it locally (usually npm run dev → http://localhost:3000) and confirm SOMETHING loads.

3.3 — Build the core loop first. Not the profile page. Not settings. The ONE action your platform exists for:

Build the core user journey from SPEC.md: [DESCRIBE THE LOOP]. Use
temporary local data for now — we wire the real database next phase.
Make it work end to end, then walk me through clicking it myself.

3.4 — Live inside the thing. Click through your own product for 20 minutes as a stranger. Write down every moment of confusion. Friction is where users go to leave.

3.5 — Iterate in plain language. For each item on your friction list:

When I [WHAT YOU DID], the app [WHAT HAPPENED]. It should instead
[WHAT YOU EXPECTED]. Fix it and tell me what you changed.

✅ Phase 3 complete when: you can click through the core journey end to end on your own machine.

---

Phase 4 — Infrastructure: GitHub, Vercel, Supabase, domain

Hire the three workers and go live on the real internet. Budget: 1 session + up to 24h DNS wait. Cost: ~$10–15 for the domain.

4.1 — Push your code to GitHub:

Set up Git for this project and push it to a new PRIVATE repository on
my GitHub account. Walk me through any login or authorisation steps.
Before pushing, verify that .gitignore excludes .env.local — confirm to
me explicitly that no secret will be uploaded.

4.2 — Verify the safety net. On github.com, confirm your files are there and .env.local is NOT. From now on you can always roll back — build fearlessly.

4.3 — Create your Vercel account — sign up with your GitHub account.

4.4 — Import your repository into Vercel → Deploy. It gives you a temporary live URL. The deploy may fail because environment variables are missing — expected; continue.

4.5 — Create your Supabase project. Choose a strong database password (password manager — never in a chat, never in code) and the region closest to your users (Europe is closest to West Africa).

4.6 — Collect your keys from Supabase → Project Settings → API. The Project URL and anon key go in your env files; the service_role key is the master key that bypasses all security — it goes in server-side env vars ONLY, never in frontend code, never in a public repo, never in a chat. Guard it with your life.

4.7 — Place the environment variables in your local .env.local AND Vercel → Settings → Environment Variables:

Here is where I've added my Supabase Project URL and anon key: .env.local
and Vercel environment variables. Tell me the exact variable names this
project expects (e.g., NEXT_PUBLIC_SUPABASE_URL), confirm which keys are
safe to expose to the browser (NEXT_PUBLIC_ prefix) and which must never
be, and then wire the app to connect to Supabase using them. Do NOT ask
me to paste the service_role key into this chat — tell me where to put it
myself instead.

4.8 — Create your database tables — with Row Level Security from day one, not as a later cleanup:

Read the data model in SPEC.md. Create the Supabase tables for it now,
via a migration file I can review. Requirements:
- Enable Row Level Security (RLS) on every table from the start.
- Write policies so users can only read/write what they should: public
  content readable by all, personal data readable only by its owner.
- Emails and private fields must never be readable by other users.
- Include created_at timestamps on everything.
Explain each table and each policy to me in one plain sentence.

4.9 — Set up storage buckets (if your app has images/files):

Create Supabase Storage buckets for [e.g., "profile photos"]. Set the
access policies: images viewable by [everyone / members], uploadable
only by their owner, with a 5 MB file size limit enforced.

4.10 — Wire the app to the real database:

Replace all temporary local data with real Supabase reads and writes,
using the environment variables. Then give me a simple test: what do I
click, and what should I see appear in the Supabase table editor?

4.11 — Redeploy and test live. Run the core loop on the LIVE site and watch your action appear as a row in the Supabase table editor. That row is your product breathing.

4.12 — Buy your domain (~$10–15/yr) and connect it: Vercel → Settings → Domains → copy the DNS records into your registrar exactly.

4.13 — Wait for propagation (1–24 hours). This is normal. Nothing is broken.

✅ Phase 4 complete when: typing your own domain loads your app, and the core loop writes real rows into Supabase.

---

Phase 5 — Authentication: opening the doors

A live site nobody can sign into is a beautiful building with the door welded shut. Budget: 1–2 sessions.

5A — Legal pages first (Google demands them)

5.1 — Draft Terms of Service and Privacy Policy pages:

Draft a Terms of Service page and a Privacy & Security Policy page for
[PLATFORM NAME], a [ONE-SENTENCE DESCRIPTION] operating primarily in
[COUNTRY]. Cover: what data we collect, how we store it (Supabase),
user rights, account deletion, acceptable use, and age requirements
[13+/18+]. Write in clear, honest language. Then create these as pages
on the site at /terms and /privacy, linked from the footer.

5.2 — Have a human review them — ideally a lawyer. At minimum, read every line yourself; you are promising these things.

5.3 — Confirm your platform's name appears on your home page exactly as you use it everywhere. Google checks.

5B — Sign in with Google (OAuth)

5.4 — Open the Google Cloud Console (console.cloud.google.com — NOT Search Console; different building, similar name). Create a project named after your platform.

5.5 — Configure the OAuth consent screen: app name, support email, your domain, and links to your live /privacy and /terms pages.

5.6 — Find Supabase's callback URL: Supabase → Authentication → Providers → Google. Copy it exactly.

5.7 — Create OAuth credentials in Google Console and add as authorised redirect URIs: the Supabase callback URL AND your own domain. One character off = the dreaded redirect_uri_mismatch.

5.8 — Copy the Client ID and Secret into Supabase → Authentication → Providers → Google, and enable it.

5.9 — Build the sign-in UI:

Add "Sign in with Google" to the app using Supabase auth. Put it on a
proper sign-in page styled to my brand: [DESCRIBE BRAND FEEL]. After
building it, verify the result against this brand brief and tell me
honestly where it falls short. This page is the first handshake — it
must look like us, not like a default template.

5.10 — Test end to end with a real Google account on your live domain.

5C — Email & password

5.11 — Enable the Email provider in Supabase. Keep "confirm email" ON.

5.12 — Build the email/password UI:

Add email-and-password sign-up and login using Supabase auth, on the
same branded auth pages. Include proper error messages a human can
understand ("wrong password", not "AuthApiError 400").

5.13 — Confirm token rotation is on:

Confirm my Supabase auth uses refresh-token rotation and short-lived
access tokens, and flag anything insecure about my current auth setup.

5D — Sending email (Resend)

5.14 — Understand the trap: Supabase's built-in email is a deliberate trickle — testing only, never launch.

5.15 — Create a Resend account. If rejected first time, verify your domain and try again — this is common.

5.16 — Verify your sending domain in Resend: add the DNS records (SPF/DKIM) at your registrar. Set up a real mailbox on your domain too.

5.17 — Wire it in:

I have a Resend API key (I will put it in the environment variables
myself — tell me the variable name and where). Set up Resend as the
email sender for all Supabase auth emails: confirmations, verifications,
and password resets, sending from [[email protected]].

5.18 — Send a test email. Goes to spam? Finish the SPF/DKIM verification.

5.19 — Build the forgot-password flow:

Add a complete forgot-password flow using Supabase's password reset:
a "Forgot password?" link on login, the reset email via Resend, and a
page where the user sets a new password. Then I will test the full
loop: request → email → new password → login.

5.20 — Test the full loop yourself. People WILL forget. This is mercy, pre-installed.

✅ Phase 5 complete when: a stranger can sign up with Google OR email, receive real emails, and reset a forgotten password — on a page that looks like your brand.

---

Phase 6 — Onboarding & identity

An email is not a name tag. Identity before access. Budget: half a session.

6.1 — Build the required onboarding form:

Add a required onboarding step for every new user after first sign-in:
name, unique username, [age if needed for legal reasons], and interests.
Gate the app so core features are unusable until it's complete. Keep it
SHORT — every field is a tax on a stranger's curiosity; anything not
essential is optional or asked later.

6.2 — Make the username the public face:

Audit the entire app: find every place a user's email address is
displayed or could be exposed (UI, API responses, page source) and
replace it with their username. Emails are private credentials, not
public identifiers. List every place you fixed.

✅ Phase 6 complete when: every new user has an identity, and no email is visible anywhere a stranger could see it.

---

Phase 7 — Notifications & push (including VAPID keys)

A social product is not a place; it is a heartbeat. People come back when they see movement. Budget: 1–2 sessions.

7A — In-app notifications

7.1 — Decide your triggers. The 3–5 events a user genuinely cares about. Too many notifications teach people to ignore you.

7.2 — Build them:

Add an in-app notification system: a notifications table in Supabase,
a bell icon with an unread count, and a notification created when
[LIST YOUR TRIGGERS]. Use Supabase Realtime so the count updates live
without refreshing.

7B — Web push (this is where VAPID keys come in)

Web push lets your site notify users even when the tab is closed. It requires a pair of VAPID keys. Novices get stuck here because nobody tells them WHERE each key goes: the public key goes in frontend env vars; the private key goes in server-side secrets ONLY — never in code, never in GitHub. Anyone holding the private key can send notifications as you.

7.3 — Generate the pair:

I want web push notifications. Generate a VAPID key pair for me using
the web-push tool (npx web-push generate-vapid-keys) and explain the
output. Do not store the keys in any code file.

7.5 — Build the push system:

Build web push notifications end to end:
1. A service worker that receives and displays pushes.
2. A permission prompt asking the user to enable notifications — shown
   at a sensible moment (after they've done something, not the instant
   they land).
3. Save each user's push subscription to a push_subscriptions table in
   Supabase (with RLS: users manage only their own).
4. A server-side function that sends a push using the VAPID private
   key from secrets (never from code) whenever [YOUR TRIGGERS] happen.
5. Handle expired/invalid subscriptions by deleting them.
Then tell me how to test it: what to click, what should pop up.

7.6 — Test on a real device. Note: iPhone web push only works when the site is added to the home screen.

7C — Email nudges

7.7 — Add sparing email notifications for the highest-value trigger only. With ~3,000 free Resend emails, password resets + one good trigger is a healthy free-tier diet.

✅ Phase 7 complete when: the app has a live heartbeat — in-app bell, working web push with keys in the right homes, and one well-chosen email nudge.

---

Building this with other people beats building it alone. The PxLabs community is a room full of people running this exact checklist — a builders' forum where your stuck-points get answered, a project showcase to put your work up in, Thursday Vibe Sessions where members demo what they're building, and meet-ups across Nigeria. ₦30,000/year.

---

Phase 8 — Testing: find your bugs before users do

Users don't file polite bug reports. They leave quietly, forever.

8.1 — Create a dedicated test account. A clean email + password used ONLY for testing. Never hand the AI a password you reuse across your life.

8.2 — Inventory the platform:

List every page on my platform. Then, for each page, list every function
attached to it (every button, form, and action a user can take).

8.3 — Get a phased test plan:

Design a test plan for all of those functions, in phases, ordered by
importance: core loop first, then auth, then everything else. For each
phase, list the exact steps to test, what SHOULD happen, and what
failure would look like.

8.4 — Run the plan WITH the AI. For each failure:

[FUNCTION] is not working. When I [STEPS], it [WHAT HAPPENS] instead of
[EXPECTED]. Fix it, and make sure it also still [RELATED THINGS THAT
MUST NOT BREAK].

8.5 — Then test by hand, yourself, on the live site. Deeply annoying and completely non-negotiable. Stop when you are HAPPY, not when you are tired.

✅ Phase 8 complete when: you have walked every function on the live site and nothing on the core path is broken.

---

Phase 9 — Optimisation: do more with less

The difference between a product and an expensive hobby. This phase SAVES money.

9.1 — Cap the space:

Enforce these limits: maximum [5] photos per profile, maximum 5 MB per
upload, with a clear friendly error when exceeded. Enforce them on both
the client AND the server/storage policy, so nobody bypasses the UI.

9.2 — Serve WebP, not JPEG:

Convert all image handling to store and serve WebP: compress and convert
uploads on the way in, and serve appropriately sized versions (a small
thumbnail for feeds, larger only when opened). Do not serve billboard
resolutions to phone screens. Tell me the before/after storage size of
a typical upload.

9.3 — Stop hammering the database:

Audit every database call in this app. Identify everything currently
written or fetched in real time that does not truly need to be —
analytics, impressions, counters, activity tracking. Convert those to a
batched sweep (collect locally, write once every 60 seconds). Keep truly
live only what users must see instantly (messages, notifications). List
every change and the load you expect it to save.

9.4 — Paginate everything:

Cap every list and feed at 20 results with a "Load more" button. Nobody
scrolls past the first page of anything; make the default fast and light.

9.5 — Ask the open question:

You are a cost-conscious senior engineer. Look for anything ELSE this
specific app is wasting: storage, bandwidth, database load, or tokens.
There is no universal checklist — ask what THIS product is wasting, and
propose fixes ranked by impact.

✅ Phase 9 complete when: images are capped and WebP, non-urgent writes are batched, lists are paginated, and you know your biggest remaining waste.

---

Phase 10 — Safety & privacy: building for humans

Software is easy; humans are the work.

10.1 — Run the full RLS and privacy audit:

Run a complete Row Level Security and privacy audit. Ensure no personal
information is publicly readable unless explicitly permitted: names,
usernames and interests can show; emails, ages, and private data cannot.
Check the UI, the API responses, AND direct database access. Find
anywhere private data could leak — and fix it. List every issue found.

10.2 — Verify it yourself: open your site in an incognito window and confirm you cannot see anyone's private data. View page source on a profile — nothing private should be there.

10.3 — Add blocking:

Add a block button: a blocked user can no longer contact, see, or
appear to the person who blocked them, anywhere in the app. Blocks are
private — the blocked user is not notified.

10.4 — Add reporting with a shadow-ban rule:

Add reporting on profiles and content. Rule: [3] reports within 24 hours
triggers an automatic shadow ban (their content stops being shown, but
they don't know) pending my review. Also detect and flag coordinated or
false reporting so the rule can't be gamed to silence innocent people.
Build me a simple admin view to review reports and lift or confirm bans.

10.5 — Ask the people who have been hurt. Before launch, show the product to women and other at-risk users in your circle and ask one question: "What would make you feel safe here?" Build what they say. This is the single highest-value user research you will ever do.

✅ Phase 10 complete when: the incognito test shows nothing private, blocking works, reports accumulate correctly, and at least three at-risk users have told you what safety means — and you built it.

---

Phase 11 — Retention & polish: from used to loved

Accessibility gets them in the door. Distinctiveness makes them stay and brag.

11.1 — Be your own first twenty users. "I am user number one. Now what? What do I engage with when there is no content yet?" Every point where the honest answer is "nothing" is this phase's work order.

11.2 — Prime the pump:

My platform must not be empty on day one. Generate a list of the [venue
/ business / content] types I should preload for [YOUR CITY]. Then wire
up a places/maps API to pull their real locations, so a brand-new user
arrives to a platform already full. Cache the API results and start
with my core city only, to control API costs.

11.3 — Cut the core flow to ~two clicks:

Here is my current flow for [CORE ACTION]: [LIST THE STEPS]. Collapse it
to roughly two clicks: pre-fill everything possible, use smart defaults,
and remove or defer every optional field. Then time how fast a brand-new
user can complete it.

11.4 — Add the private lane:

Add direct person-to-person invitations: a user can privately invite one
specific person to [CORE ACTION] without posting publicly to a feed.
Notify the invitee (in-app + push). Rate-limit invites and respect
blocks so this can't be used to harass.

11.5 — Find your signature. Why would your product ever feel like its own thing, if by design it feels like something else?

I want a signature interactive element that makes this platform
unmistakably itself: [DESCRIBE THE FEELING/SHAPE YOU WANT]. Build it
for the discovery page where users land, make it touch-friendly, and
keep it fast on cheap phones.

✅ Phase 11 complete when: a brand-new user lands on a full room, can act in ~two clicks, can invite privately, and meets something no other platform has.

---

Phase 12 — Monetisation: the charity ends here

A beloved platform that earns nothing is an expensive hobby.

12.1 — Find the person who actually holds the money:

Here is my ecosystem: [DESCRIBE YOUR USERS AND EVERYONE AROUND THEM].
Answer honestly: who in this ecosystem is actually holding money, and
what do they want badly enough to part with it? The users themselves
may be the VALUE, not the customer. Propose 3 revenue lines ranked by
how naturally they fit the product, including at least one intangible
(status, visibility, verification).

12.2 — Check the Apple/Google tax before you build. The ~30% commission applies to DIGITAL goods consumed in-app. Real-world goods and services generally are NOT subject to it. Verify your specific case.

12.3 — Create a Paystack account (or your region's equivalent) and note the test/live key pairs. Test keys build; live keys only after everything passes.

12.4 — Integrate with the TEST key first — always:

Integrate Paystack for [YOUR FIRST REVENUE LINE] using the TEST keys
from environment variables (never hardcoded). Build: the payment flow,
a payments table recording every transaction, and clear success/failure
screens. We do NOT touch live keys until the full test checklist passes.

12.5 — Set up the webhook — and verify its signature. Payment confirmations must come from the webhook, not the browser (browsers can lie):

Add a Paystack webhook endpoint that: (1) VERIFIES the webhook signature
using the secret key so forged requests are rejected, (2) marks payments
as confirmed only on a verified successful event, (3) never trusts the
frontend alone for payment status. Explain to me in plain language why
this matters.

12.6 — Test with Paystack's test cards end to end: pay, fail, retry, webhook confirms, the paid feature unlocks.

12.7 — Go live: swap test keys for live keys in the environment variables — nowhere else should need to change. If it does, keys were hardcoded, and that's the real bug. Make one small real payment yourself and refund it.

12.8 — Subaccounts and splits — the marketplace unlock:

Set up Paystack subaccounts and split payments: vendors fill out a form,
a webhook automatically enrols each as a subaccount pending my approval;
once approved, every payment to that vendor splits automatically — their
share straight to them, my [X]% to me. I never hold anyone else's money.
Build the vendor form, the enrolment webhook, and my approval screen.

12.9 — Know your numbers cold. "My monthly costs are ~$[TOTAL]. At just [N] customers paying [PRICE], I am sustainable." If you cannot fill that in, you do not have a business model yet.

✅ Phase 12 complete when: a real (refunded) payment has flowed end to end through a signature-verified webhook, and you can state your sustainability number from memory.

---

Phase 13 — Serving paying customers (build as needed)

Pick what your product needs — each is one prompt in the library: contextual search, QR tickets with a door scanner, offline check-in (essential where venue wifi dies), lawful CSV attendee export, and gifting.

---

Phase 14 — Discoverability: SEO & AEO

Being legible to the machines that now answer people's questions.

14.1 — Google Search Console (search.google.com/search-console — the OTHER Google console): add your domain, verify via DNS.

14.2 — Sitemap + robots.txt:

Generate a sitemap.xml of all public pages, keep it auto-updated, and
create a robots.txt that allows crawling of public pages and blocks
private ones. Tell me the sitemap URL to submit in Search Console.

14.4 — Speak to the AI crawlers — llms.txt:

Create an llms.txt file at the site root describing [PLATFORM NAME] for
AI crawlers and answer engines: what it is, who it's for, what it does,
where it operates, and links to key pages. Write it so an AI answering
"what's a good way to [YOUR USE CASE] in [CITY]" would understand and
recommend us.

14.5 — Meta tags and structured data:

Add to every public page: proper title and description meta tags,
Open Graph tags (so links look good when shared on WhatsApp/social),
and structured data (schema.org) appropriate to the content. Give the
machine a map, not a maze.

14.6 — Final security & performance pass:

Run a final pre-launch audit: (1) SECURITY — exposed keys, missing RLS,
injection risks, anything in page source that shouldn't be there;
(2) PERFORMANCE — load time on a mid-range phone on 3G, image sizes,
bundle size. Rank findings by severity and fix the critical ones now.

✅ Phase 14 complete when: Search Console shows your sitemap accepted, llms.txt is live, shared links preview beautifully, and the audit shows nothing critical.

---

Phase 15 — Going native: into their pockets

App store presence is borrowed credibility. Cost: $99/yr (Apple) + $25 once (Google).

15.1 — The parity discipline. The AI will always drift — a feature lands on web and quietly never reaches native. Repeat after EVERY feature, forever:

Standing rule: keep web and native at parity. Every function accessible
on all platforms — web, iOS, Android. Confirm the feature we just built
exists and works on all three, and list anything currently out of sync.

15.2 — Test on your own phone with Expo Go. Install Expo Go, same wifi as your laptop, ask for the QR code. Tapping around your own creation is a genuinely magical moment.

15.3 — Mobile push via Expo's push service, for the same triggers as web push.

15.4 — Apple: enrol in the Developer Program, build to TestFlight, invite testers.

15.5 — Google: Play Console, upload for internal testing.

15.6 — Store assets: description (draft it from your llms.txt), screenshots, privacy questionnaires (answer honestly from your actual Privacy Policy).

15.7 — Submit for review. Rejections are common and normal: read the reason, paste it to your AI, fix, resubmit.

✅ Phase 15 complete when: a stranger can find and install your app in both stores.

---

Phase 16 — Launch readiness: the final sweep

• Backups: confirm they're active and know how to restore.
• Error visibility: find out when something breaks before users tell you.
• Analytics: visits, sign-ups, core-loop completion — the three numbers that tell you if it's working.
• Brand hygiene: favicon, app icons, social preview image.
• Rate limiting: one bad actor must not be able to flood the platform.
• The final walkthrough: the entire journey as a stranger — on your phone, on bad internet.
• The honest question: do I have a product, or an elaborate hobby? If every box above is checked, you know the answer.

---

The appendix that saves novices: which key goes WHERE

The single most confusing thing for beginners. The rules that never change:

• Anything named "secret", "private", or "service_role" never touches frontend code, never enters GitHub, never gets pasted into a chat.
• .gitignore must always exclude .env.local.
• Public keys (Supabase anon, VAPID public, Paystack public) may live in frontend env vars with the public prefix.
• When switching payment keys from test to live, ONLY the environment variables change — if code changes, keys were hardcoded, and that is the real bug.

---

Where to go from here

You did not get here alone, and you should not build alone.

Want this taught live, on your own product? This checklist is the spine of Product Development — From Idea to Product — the PxLabs cohort course where you arrive with an idea and leave with it live on the internet. Our other live courses cover AI foundations, AI image and AI film — all taught from zero, no experience assumed.

Want a room to build in? Join the PxLabs community — the builders' forum for your stuck-points, every prompt in this post in a copy-paste library, a project showcase for what you ship, Thursday Vibe Sessions, and in-person meet-ups across Nigeria. Membership is ₦30,000/year.

Share the hosting, share the tokens, share the hard-won numbers. Come build with us.