Companion to the book

The Workbook

The AI App Builder Workbook

Your Afia Labs action guide from idea to launch

Companion to From Idea to Income with AI Apps

by Bridgette Owusu · Afia Labs

Front Matter

Page 1 — Cover

The AI App Builder Workbook Your Afia Labs Action Guide from Idea to Launch

Build with AI. Stay in control. Own the outcome.

A companion to From Idea to Income with AI Apps

Page 2 — Copyright + Brand

Published by Afia Labs afialabs.net support@afialabs.net

Version 1.0

This workbook is a companion to From Idea to Income with AI Apps. You can read it standalone, but it works best alongside the book.

No part of this workbook may be reproduced or distributed without written permission, except for personal use by the buyer.

Page 3 — Welcome

I am Bridgette. I run Afia Labs, and I built a consumer iOS app called MemeScanr using AI tools as a solo builder. This workbook is where I put everything I wish someone had handed me on day one.

This workbook is for the builder who keeps almost starting. The one who has a notes app full of app ideas and has shipped zero of them. I was you for a long time. I finally shipped. And now I want to pay it forward.

Here is my one promise to you:

This is a space where messy answers are okay. You do not have to know the right thing before you write it down. You do not have to be fluent in anything yet. You do not have to feel ready. The whole point of a workbook is that it meets you where you are and takes you one step forward.

Write freely. Refine later. Come back to pages when your thinking changes.

This is your space. Build something real.

— Bridgette

Page 4 — How to Use This Workbook

A few rules, if you want them:

1. You do not have to do the pages in order. The sections build on each other, but you can jump around. If a page is not landing, skip it and come back later. Your answers will be better the second time.

2. Messy answers beat perfect answers. Write what you actually think, not what sounds smart. This is not a test. Nobody is grading you. The messy first draft is the most useful thing you will ever write about your own product.

3. Revisit. Revisit. Revisit. Your answers will change as you build. That is not a failure of your earlier answers — it is evidence that you are learning. Come back to the workbook every few weeks and update the pages that are no longer true.

4. Keep it with you. This workbook is supposed to be dog-eared. Write in the margins. Highlight. Cross things out. Fold corners. It should look used.

5. If you get stuck, read the companion book. Every section of this workbook maps to one or more chapters in From Idea to Income with AI Apps. If a prompt is not clicking, the book explains the thinking behind it in more depth.

That is it. Start writing.

Page 5 — Workbook Roadmap

Here is the path you will walk through this workbook. Eleven sections, roughly 80 pages, from “I have an itch” to “I shipped something real.”

Builder Identity — who are you as a builder, and what kind of builder do you want to become? (Companion to Book Chapters 1-5)
Idea Clarity — what is the itch you cannot stop noticing? (Companion to Book Chapter 6)
Idea Validation — does the world actually need this, or just you? (Companion to Book Chapter 7)
MVP Planning — what is the smallest thing you can ship? (Companion to Book Chapter 8)
AI Workflow & Prompts — how will you use AI without becoming a passenger? (Companion to Book Chapter 9)
Stack & Setup — which tools and why? (Companion to Book Chapters 10-11)
Build, Test, and Polish — how do you know when it is actually done? (Companion to Book Chapters 12-14)
Launch Prep — the App Store reality check (Companion to Book Chapters 15-16)
Business Setup — the boring stuff that keeps the business alive (Companion to Book Chapter 19)
Marketing & Monetization — how do you get users and how do you get paid? (Companion to Book Chapters 17-18)
Reflection & Next Steps — what did you learn, and what is next? (Companion to Book Chapter 19)

You can do this in a weekend (sprinting) or spread it across months (gradually). Either works. The point is that you do it.

Page 6 — Your Builder Promise

Before we start the real work, I want you to write a promise to yourself. This page is not decorative. It is how you set the intention that everything else in the workbook builds on.

Fill in each blank. Write what is true right now, even if it feels small.

I am building because _______________________________________

I am no longer waiting for _______________________________________

I will use AI to _______________________________________

I will stay in control by _______________________________________

When AI and I disagree, I will _______________________________________

My sample answers (just to show you the voice is not serious, it is honest):

I am building because I refuse to wait for someone else to fix the problem I keep noticing in my own life.

I am no longer waiting for permission, for a cofounder, for the perfect idea, or for the right moment.

I will use AI to go faster, not to avoid understanding my own product.

I will stay in control by reading every line of code the AI writes for me before I merge it.

When AI and I disagree, I will ask why, listen carefully, and change my mind only when the AI’s reasoning is better than mine.

Sign and date this page. It is the start line.

Section 1 — Builder Identity

Companion to Book Chapters 1-5 (The Restaurant and the Kitchen, The Master Driver, How Not to Let AI Take Control of You, What Ownership Really Means, The Landscape of AI App Building)

Page 7 — Section Divider

Section 1: Builder Identity Section 1 of 11 — Outcome: a clear sense of who you are as a builder and what you stand for. [ ] Done [ ] Revisit

Before we get into ideas and validation, we need to talk about you. Not your credentials. Not your resume. You — the person who is about to spend a significant chunk of her life making something from nothing. Who are you? What kind of builder do you want to become? What do you stand for?

The six pages in this section are not warm-up pages. They are the foundation. Everything else you do in this workbook will be shaped by the answers you write here.

Be honest. This is the only place in the workbook where lying to yourself has no upside.

Page 8 — Passenger, Fighter, or Master Driver?

In Chapter 2 of the book, I describe three kinds of builders: the passenger, the fighter, and the master driver. The passenger lets the AI drive. The fighter refuses to get in the car. The master driver is in control, using AI as a tool while keeping judgment firmly in her hands.

Honestly — which have you been up until now?

[ ] Passenger (I have accepted AI output without fully understanding it) [ ] Fighter (I have refused to use AI out of principle, purity, or pride) [ ] Master driver (I have used AI while keeping full ownership of my product) [ ] Some mix of all three (most builders, if they are honest)

Where have you been acting like a passenger? _______________________________________

Where have you been acting like a fighter? _______________________________________

What would it look like to act like a master driver tomorrow? (Be specific — one concrete behavior you would change)

Page 9 — My Current Starting Point

Tell the truth about where you are right now. Not where you want to be. Not where you pretend to be. Where you are.

What do I already know? (Technical skills, domain knowledge, tools you have used)

What feels intimidating right now? (Be specific — “coding” is not a real answer; “understanding iOS permission flows” is)

What tools have I used before? (Editors, languages, frameworks, AI tools)

What strengths do I already bring as a builder? (Taste, writing, design, persistence, empathy, specific domain knowledge — whatever is true)

The point of this page is to give you a baseline. Six months from now, you will read this page and see how far you have moved.

Page 10 — Why This Matters to Me

Why do I want to build apps? (If your answer is “to make money,” go deeper. What would the money buy you? What would it free you from?)

Why does ownership matter to me? (Be specific about what ownership means in your life)

What kind of freedom am I hoping this creates?

What would I regret not trying?

The last one is the most important. Regret is the most reliable motivator there is.

Page 11 — AI Boundaries

AI is a tool. Like every tool, it becomes a weakness if you lean on it too hard. Chapter 3 of the book goes deep on this. Here is your place to make it personal.

How do I want to use AI wisely?

What are the three red flags that would tell me I am becoming AI-dependent?

My red flags for reference:

I am copying code I have not read
I cannot explain my own code to a friend
I would be blocked if my AI tool disappeared for a week

What rules do I want for myself when working with AI? (At least 3, specific and testable)

Pin this page somewhere you will see it.

Page 12 — Builder Identity Declaration

You wrote a builder promise on page 6. This page is the next step — a fuller declaration that goes deeper. Write it in your own voice. Do not worry about how it sounds. The point is that you wrote it.

If you are stuck, start by listing three things you did this week that felt like building. That is your identity showing up.

I am becoming the kind of builder who _______________________________________

I am not the kind of builder who _______________________________________

My three non-negotiables are:

When things get hard, I will remember:

My sample answers:

I am becoming the kind of builder who ships imperfect things and improves them in public.

I am not the kind of builder who waits for permission or hides behind “not ready yet.”

My three non-negotiables are: I read every line before I merge. I test the denial path. I own the domain.

When things get hard, I will remember: the version of me who finishes this is already in here. She just needs me to keep showing up.

Sign and date. You are going to need to read this page again in three months.

Section 2 — Idea Clarity

Companion to Book Chapter 6 (Finding the Itch)

Page 13 — Section Divider

Section 2: Idea Clarity Section 2 of 11 — Outcome: one itch you cannot stop noticing, described in one sentence. [ ] Done [ ] Revisit

This section is not about generating 100 ideas. It is about finding your itch — the one specific thing you cannot stop noticing.

The book describes the difference between an idea (which you can forget) and an itch (which you cannot). If it is an itch, we build. If it is just an idea, we keep looking.

Seven pages of honest digging.

Page 14 — Brain Dump

Before we filter, we dump. Write down every app idea that has lived in your head in the last six months. Not just the “good” ones. Every single one. The dumb ones. The ones you have already dismissed. The ones that only make sense in your shower.

Do not edit. Do not judge. Just list.

(Add more lines if you need them. Use the margin.)

Now circle the three that tug at you the most. Not the “smartest” three. The three you cannot stop thinking about.

Page 15 — Problem Finder

For each of your top three circled ideas, answer these questions. The one where the answers are most emotional is probably your itch.

Idea 1: _______________________________________

What problem does it solve? _______________________________________
How long have I been noticing this problem? _______________________________________
Have I complained about it out loud more than once? [ ] Yes [ ] No
Do people I know have the same problem? _______________________________________

Idea 2: _______________________________________

What problem does it solve? _______________________________________
How long have I been noticing this problem? _______________________________________
Have I complained about it out loud more than once? [ ] Yes [ ] No
Do people I know have the same problem? _______________________________________

Idea 3: _______________________________________

What problem does it solve? _______________________________________
How long have I been noticing this problem? _______________________________________
Have I complained about it out loud more than once? [ ] Yes [ ] No
Do people I know have the same problem? _______________________________________

Which one is the itch?

Page 16 — User Clarity

Pick your itch from the previous page. Now we get specific about who you are solving it for.

The itch: _______________________________________

Who is this app for? (Not “everyone.” One specific person you can picture in your head)

Describe a day in their life. What are they doing right before they open your app?

What kind of mood are they in?

What do they want relief from?

What outcome do they want?

My MemeScanr user, for reference: she is 24, has 180GB of photos on her iPhone, takes 40 new photos a day, feels guilty about her camera roll like some people feel guilty about their closets, and wants to feel like her phone is hers again.

Page 17 — App Idea Snapshot

A single-page summary of your idea. If you can fill this in clearly, your idea is ready for the next step. If you cannot, go back a page and keep digging.

My app helps _______________________________________

do _______________________________________

so they can _______________________________________

The core problem is _______________________________________

The emotional outcome is _______________________________________

MemeScanr’s sample:

MemeScanr helps Gen Z iPhone users clean up forgotten photos so they can feel like their phone is theirs again.
The core problem is 15,000 photos nobody has time to review manually.
The emotional outcome is relief — the weight of the camera roll lifting.

If your fill-ins feel vague, narrow. If they feel specific, you are ready for page 18.

Page 18 — Narrow the Idea

Every first-draft idea is too big. Part of your job is cutting it down until it fits in a single breath.

What is the main promise of the app? (One sentence. If it has “and” in it, you have not cut enough.)

What is NOT the main promise? (Features you are tempted to include that do not serve the main promise)

What can be saved for later? (Features that are worth building eventually but not in v1.0)

The Personality Test: in three words, what feeling does your app give a user that they could not get anywhere else?

MemeScanr’s three words: seen, playful, relieved.

If your three words feel like categories (“productive”, “organized”, “clean”), you have not gotten to a feeling yet. Try again.

Page 19 — Why This Idea, Why Now?

If you are stuck, start with the simplest version: “Because this problem did not exist five years ago” or “Because nobody is solving it the way I would.”

Why is this worth building now? (What has changed recently that makes this possible or necessary?)

What makes this problem timely or relevant?

Why do I care enough to keep going when it gets hard?

My sample answers:

Why now: AI tools make it possible for one person to build what used to require a team. The window is open.

Why I care: I use my own phone 90 times a day and the camera roll problem has not gone away. It is personal.

The last question is the one that actually matters. When you are in month 5, exhausted, wondering if this was all a mistake, the answer to this question is what keeps you in the chair. Write it well.

Section 3 — Idea Validation

Companion to Book Chapter 7 (The Four-Question Filter)

Page 20 — Section Divider

Section 3: Idea Validation Section 3 of 11 — Outcome: a go, refine, or drop decision backed by real research. [ ] Done [ ] Revisit

The book has a one-week validation sprint (Chapter 7). This section is the workbook version of that sprint. If you do the work in these pages honestly, you will know by the end of the week whether to build, refine, or walk away.

The hardest part of validation is not the research. It is being willing to walk away from an idea you are already attached to, if the research tells you to. Keep that possibility open as you fill these in.

Page 21 — The Four-Question Filter

Fill in honest answers for each of the four filter questions.

Q1: Are people already paying for something in this space?

Competitor 1: _______________________________________ (what do they charge?) __________
Competitor 2: _______________________________________ (what do they charge?) __________
Competitor 3: _______________________________________ (what do they charge?) __________

Is there real money changing hands in this category? [ ] Yes [ ] No

Q2: Can I reach the people who would pay?

Where does my target user already spend time online?
- Place 1: _______________________________________
- Place 2: _______________________________________
- Place 3: _______________________________________
Can I show up in at least one of those places without paying for ads? [ ] Yes [ ] No

Q3: Is the problem painful enough to pay to solve?

What is my target user currently doing to solve this problem? _______________________________________
Is that painful, expensive, or embarrassing? [ ] Yes [ ] No

Q4: Can I maintain this for two years without giving up?

Is the problem interesting enough that I can think about it for 2 years? [ ] Yes [ ] No
Does the product require me to become someone I am not? [ ] Yes [ ] No
Would my version of “success” actually satisfy me? [ ] Yes [ ] No

Count your no’s. Zero is ideal. One is workable. Two or more is a warning. Three or more means this idea is not ready.

Page 22 — Competitor Scan

Pick the top 5 competitors in your category. Fill in this table.

#	Name	Price	Strengths	Weaknesses	Reviews (stars)
1
2
3
4
5

What do they all do well? (This is table stakes — things you will need to match)

What do they all do poorly? (This is your wedge — things you can do better)

Where is the gap nobody is serving?

Page 23 — Market Signal Tracker (The Bad Review Mine)

This is the single highest-value page in this section. Take it seriously.

Bridgette’s note: This is the page that changed MemeScanr. I almost skipped it because reading bad reviews felt depressing. Do not skip it. The complaints are the roadmap.

Go to the App Store and read at least 25 one-star and two-star reviews for each of your top 5 competitors. That is 125+ reviews total. This will take you 1-2 hours.

As you read, write down every complaint that appears more than once. The patterns are your roadmap.

Recurring complaints I found (aim for 10-20):

Which of these complaints, if I solved it, would be my wedge? (Circle the one that matches your strengths and your itch)

MemeScanr’s wedge came from this exact exercise: reviews kept saying “this feels like homework” and “the app is judgmental.” Nobody was building a cleanup app that made users feel good while cleaning up. That gap became MemeScanr’s entire positioning.

Page 24 — Validation Notes

What feedback have I heard so far from real humans? (Not imagined reactions — real conversations)

What repeated needs are showing up in those conversations?

What assumptions about my idea do I still need to test?

Show one person today. Describe your idea in two sentences to one human who fits your target user. Write what their face did (not what they said — what their face did).

Page 25 — Go / Refine / Drop

This is the decision page. Do not skip it. Do not half-answer it. Pick one.

Based on everything in this section, the honest answer is:

[ ] Go — all four questions are solid yes, the validation data looks clean, my itch matches a real market gap. I am building.

[ ] Refine — three questions are yes, one is weak. I know what needs to be sharpened. I will fix that weakness before starting, then build.

[ ] Drop — two or more questions are weak, the validation data does not support the idea, or my itch does not match what the market wants. This is a gift — I am saving myself months of wrong work. I will go back to Section 2 and find a different idea.

If refine: what specifically needs to change?

If drop: what did this idea teach me that I will use on the next one?

Write the date. Move on.

Milestone — Idea Validated

If you made it here with a “Go” on page 25, you have done what most aspiring builders never do: you tested your idea against reality before building it.

What you should know now:

Whether your idea is an itch or just an idea
Who your specific user is
Whether real people are already paying in this space
Whether you can reach your target user without ads

The decision you should have made: Go, Refine, or Drop.

What happens next: You scope the MVP. Section 4 will feel faster because of the clarity you built here.

Section 4 — MVP Planning

Companion to Book Chapter 8 (The Smallest Useful Version)

Page 26 — Section Divider

Section 4: MVP Planning Section 4 of 11 — Outcome: a scoped v1 you can build in weeks, not months. [ ] Done [ ] Revisit

Your MVP will be smaller than you want it to be. That is not a failure — that is the point.

These pages are designed to force you to cut. Be ruthless. Every feature you cut now is a future launch you get to have later.

Page 27 — My Minimum Viable Product

What is the smallest useful version of this app? (One sentence. If it has more than one main feature, you have not cut enough.)

What must be true for version 1 to feel useful to a first-time user?

MemeScanr’s v1.0 was just duplicate detection + swipe review + delete. That is it. No Memory Lane. No Backroom. No Gallery Wrapped. One feature. And it was enough to launch.

If I am scared to ship this small version, what am I actually scared of? (Is it that the product is not good enough, or that you are afraid of judgment?)

Page 28 — Core Feature List

The top 3 must-have features for v1.0:

Nice-to-have features I am tempted to include but will cut:

Which of the nice-to-haves is hardest to cut? (This is the one you are most attached to — which is exactly why it needs to be cut first)

Page 29 — Version 1 vs Version 2

Draw a line down the middle. On the left, everything that ships in v1.0. On the right, everything that ships later.

v1.0 (building now)	v2+ (saving for later)

Rule: your v2 column should feel bigger than your v1 column. If v2 feels thin, you are cramming too much into v1.

Page 30 — User Journey Map

Draw or describe the user journey in exactly 5 steps.

Step 1 — Trigger: What brings the user to your app in the first place?

Step 2 — Arrival: What is the very first thing they see when they open the app?

Step 3 — First action: What is the first thing they tap or do?

Step 4 — Payoff: What do they see or feel when the first action completes?

Step 5 — Return hook: Why would they open the app a second time?

If any step is unclear, your MVP is not ready to build.

Page 31 — Screen Planning

List every screen in v1.0. For each, write the purpose in one sentence.

Screen name	Purpose (one sentence)

If you have more than 8 screens in v1.0, you are overbuilding. Cut.

Page 32 — Core Loop

What is the one most important action the user must be able to complete for this product to have a point?

Walk through the core loop out loud: user opens the app, then _______________________________________, then _______________________________________, then _______________________________________, then _______________________________________.

MemeScanr’s core loop: user opens app → taps scan → sees duplicates → swipes through them → deletes the ones they do not want.

If the core loop has more than 5 steps, it is too complex. Simplify.

Page 33 — MVP Clarity Check + Cut One More Thing

Bridgette’s note: I wish someone had made me do this exercise before I spent four months building features that should have been v2. Cut one more thing. You will thank yourself later.

Is my MVP still too big? Look at pages 28 and 29 again.

[ ] Yes, it is too big [ ] No, it feels right [ ] I cannot tell

If yes or cannot tell, do the Cut-One-More-Thing ritual right now:

Pick the feature you are most attached to that is NOT strictly required for the core loop.
Write its name here: _______________________________________
Cross it out. Move it to v2.
Sit with the feeling for a minute. Notice how attached you were.
Celebrate the launch you just saved for later.

Scope lock date: _______________________________________ (The date after which no new features can be added to v1.0, no matter what)

Write the date down. Honor it.

Page 33b — Feature Complexity Filter

Before adding any new feature, score it on both dimensions. This matches Worksheet 4 from Appendix C of the book.

Feature name: _______________________________________

User value (1-5):

1 = nobody asked for this
3 = a few users have asked, or I think it matters
5 = users are actively frustrated without it

Score: _______

Complexity cost (1-5):

1 = one file, no dependencies, easy to maintain
3 = touches 2-3 files, adds moderate surface area
5 = touches many files, adds significant maintenance burden

Score: _______

Dependency depth: How many existing features does this interact with? _______

Test burden: How many new test cases will this require? _______

Reversibility: If this ships and users hate it, can you remove it cleanly? [ ] Yes [ ] No

Score: user value minus complexity cost = _______

Decision rule:

Score 2 or higher: ship
Score 0 or 1: park it in the feature temptation log
Negative score: kill it before it eats your time

Not every good idea deserves to become a feature. Some good ideas are just expensive distractions with good branding.

Section 5 — AI Workflow & Prompts

Companion to Book Chapter 9 (The Real AI Workflow)

Page 34 — Section Divider

Section 5: AI Workflow & Prompts Section 5 of 11 — Outcome: reusable prompts and a weekly reflection habit. [ ] Done [ ] Revisit

This section is where you build the habits that will determine whether you are a master driver or a passenger. Chapters 3 and 9 of the book are the philosophical and tactical foundations. These pages are for making the habits personal.

Eight pages of practice. Do them badly the first time. Do them better the second time.

Page 35 — Messy Thought Dump

Pour your heart out. Write what you want to build as if you were explaining it to a friend who has never heard about it. Do not worry about structure. Do not worry about prompts. Just write.

Now underline the three most important sentences. Those are the seeds of your real prompts.

Page 36 — Convert My Thoughts Into a Prompt

Take the underlined sentences from the previous page. Use them to fill in a real prompt.

Context: I am building _______________________________________ in _______________________________________.

Current behavior: _______________________________________

Desired behavior: _______________________________________

Constraints: _______________________________________

Files involved: _______________________________________

Specific question: _______________________________________

This is your starting prompt. Save it. Reuse it. Modify it for every real task.

Page 37 — My VS Code Build Prompt

A complete template you can keep next to your editor. Fill in the blanks now, then copy it to your snippets file.

Context: I am building [feature] in [stack].
Target user: [who]
Problem solved: [what]
Core features: [list]
Stack: [framework, language, packages]
Desired feel: [voice, polish level, references]
Output request: [specific ask]

Write out your own version:

Page 38 — Debug Prompt Builder

When something breaks, do not panic-prompt. Walk through these fields first.

What is happening?

What should happen instead?

What files or flows are affected?

What edge cases should be checked?

What have I already tried?

Only after you have filled these in, prompt the AI. You will get a better answer every time.

Page 39 — UI Polish Prompt Builder

When the product works but does not feel right, the problem is usually polish, not logic.

What feels weak visually? _______________________________________

What emotional tone should the UI have? _______________________________________

What should remain simple? _______________________________________

What microinteraction is missing? (Haptic, animation, sound, transition)

What brand voice word (from page 18) does this screen fail to land in?

Now prompt the AI with these fields. Watch the quality of the suggestions improve.

Page 40 — Cross-Platform Prompt Builder

(Skip this page if you are building for one platform only)

What must work on both iOS and Android?

What platform-specific concerns should AI consider?

Where is the shared logic vs the platform-specific code?

What native features am I willing to lose in exchange for cross-platform speed?

Page 41 — Weekly Reflection

Come back to this page every Sunday. It is the habit that separates master drivers from passengers.

Week of: _______________________________________

What did I ship this week?

What is blocking me?

Did AI help me think this week, or replace my thinking?

Where do I still need understanding? (Code I accepted but do not fully grasp)

One thing the AI got wrong this week:

One thing I would have missed without AI:

Ten minutes. Every Sunday. It keeps you calibrated and moving.

Section 6 — Stack & Setup

Companion to Book Chapters 10-11 (Your Kitchen: Stack and Setup; Building for iPhone and Android)

Page 42 — Section Divider

Section 6: Stack & Setup Section 6 of 11 — Outcome: a committed stack and a working project folder. [ ] Done [ ] Revisit

The stack you pick is a 2-year commitment. The six pages in this section are for making that commitment consciously, not by default.

Chapter 10 of the book goes deep on the trade-offs. Chapter 11 covers cross-platform concerns. Use these pages to land on your own answer.

Page 43 — My Tool Stack

Layer	My choice	Why
Editor
Frontend framework
Backend (if any)
Database
Payments
Deployment
AI coding assistant
State management
Analytics (if any)
Crash reporting

Every row should have a specific answer and a reason. “Because it is popular” is not a reason. “Because I can be fluent in it in 6 months and it supports the native features I need” is a reason.

Page 44 — Why I Chose This Stack

In one paragraph, why does this stack fit me right now? (Not “why is it popular.” Why is it a good fit for you, with your skills, your product, your goals?)

What trade-offs am I accepting? (Every stack has them — name yours)

The 2-year test: if this app fails, am I glad I became fluent in this stack for the next 2 years? [ ] Yes [ ] No [ ] Not sure

If you said no or not sure, go back and reconsider your stack choice.

Page 45 — Project Setup Checklist

Page 46 — GitHub Setup Tracker

Repo name: _______________________________________
README created
First commit made
Branch strategy noted (main only? main + dev? feature branches?)
Backup habit set (push to origin at least daily)
Secrets stored in a .env file, NOT committed
License file added (MIT, Apache 2.0, or proprietary — pick one)

My branch strategy:

My secret-management approach:

Page 47 — Android + iOS Support Notes

(Skip if you are only building for one platform. See Book Chapter 11 for the cross-platform deep dive.)

Will this app be iOS only, Android only, or cross-platform? [ ] iOS only [ ] Android only [ ] Cross-platform (both)

If both, how will I test both? (Simulator? Real devices? TestFlight + Google Play internal test?)

What platform-specific tools do I need ready?

If cross-platform, what native bridges will I need? (Widgets, Siri Shortcuts, Live Activities, sharing, etc.)

Section 7 — Build, Test, and Polish

Companion to Book Chapters 12-14 (Testing on Simulators/Real Devices/TestFlight, GitHub and Version Control, Building Messy Is Building Right)

Page 48 — Section Divider

Section 7: Build, Test, and Polish Section 7 of 11 — Outcome: a tested, trustworthy build ready for submission. [ ] Done [ ] Revisit

This is the longest section because it is the longest part of the real work. These are the pages you will come back to most often.

Chapters 12, 13, and 14 of the book are your companions here. Re-read Chapter 14 (Building Messy Is Building Right) when you feel like quitting.

Page 49 — Build Progress Tracker

Update this page weekly. It is your morale tool.

What is already built and working?

What is in progress?

What is still blocked? (And why)

What did I ship this week?

What did I learn this week?

Page 50 — Testing Checklist

Run this before every significant release.

Page 51 — Simulator Notes

What worked in the simulator?

What still needs real-device testing?

Remember: the simulator lies about performance, about haptics, about permission flows, about notifications. You cannot ship without testing on real devices.

Page 52 — Real Device Testing Notes

What changed when I tested on a real phone?

What felt slower, clunkier, or less trustworthy than the simulator suggested?

What needs to be fixed before launch?

Page 53 — TestFlight / Beta Testing Tracker

Build uploaded to TestFlight (or equivalent)
Tested on at least 2 different device sizes
Tested by at least 1 real user who is not me
Bug notes written up (below)
Tester feedback captured (below)
Next fixes prioritized

Bug notes:

Tester feedback:

Next fixes:

Page 54 — Trust & Safety Review

Bridgette’s note: The Silent Vault bug from Chapter 14 happened because I skipped this checklist. Free users could put photos into a vault they could not open. I caught it in TestFlight, not production. Run this checklist. Every time.

For every feature that touches user data, money, or privacy, run this checklist. It matches the Trustworthiness Checklist from Book Chapter 14.

Feature name: _______________________________________

1. Does the user understand what just happened? If you moved a photo, deleted a file, or changed a setting, did the user clearly see the result? [ ] Yes [ ] No

2. Can the user undo it, or at least reverse it without contacting support? If not, that is a red flag. Destructive actions without undo need extra consent and extra clarity. [ ] Yes [ ] No [ ] Not applicable

3. Does the user see the cost before they pay it? If a feature requires a subscription, does the paywall appear before the action or after? After is almost always a bug, even if it technically works. [ ] Yes [ ] No [ ] Not applicable

4. If this feature fails silently, would the user even know? If the answer is no, that is a trust surface. Errors need to be visible. [ ] Yes, they would know [ ] No, it fails silently

5. If the user had to explain what just happened to a friend, could they? If the user’s mental model is different from what the code actually did, you do not just have a code bug. You have a design bug. [ ] Yes [ ] No [ ] Not sure

Are permissions requested contextually (not at launch)? [ ] Yes [ ] No

Does the user have a way to see and delete their data? [ ] Yes [ ] No

If any answer is “no” or “not sure,” fix it before shipping. The user’s trust is not a debt you get to repay later.

Page 55 — Performance & Polish

What still feels laggy? _______________________________________

What still feels unfinished? _______________________________________

What already feels strong? _______________________________________

The 5-second test: open your app on a real device. Count to 5. What would you change in those first 5 seconds to make the app feel more polished?

Milestone — Build Complete

If you made it here, you have a tested, trustworthy product. Not perfect. Trustworthy. That is the standard that matters.

What you should know now:

Your core loop works end to end
You have tested on a real device, not just the simulator
Your trust and safety checklist has no open “no” answers
Your code is in Git with a clean recent commit

The decision you should have made: Is this build ready to submit, or does it need one more pass?

What happens next: You prepare for the store. Section 8 is the final audit before you press submit.

Section 8 — Launch Prep

Companion to Book Chapters 15-16 (The Pre-Submission Audit, Pricing Like You Mean It)

Page 56 — Section Divider

Section 8: Launch Prep Section 8 of 11 — Outcome: a store-ready submission with pricing, screenshots, and metadata. [ ] Done [ ] Revisit

Chapters 15 and 16 of the book are the full playbook. These pages are the action items. Run them before you press submit.

Chapter 15 covers the Pre-Submission Audit and the 25-item checklist. Chapter 16 covers pricing, the anchoring staircase, and the two-trial strategy. You will use both for this section.

Page 57 — Store Readiness Checklist

Page 58 — App Positioning

What is the strongest angle for this app? (The one-sentence version you could tweet)

Why should users care? (Not features — feelings)

What makes it different from the top 3 competitors?

My 3 voice words applied to positioning: (From page 18)

Page 59 — Screenshot Planning

For each of your 10 slots, plan the intent. Do not design yet — plan.

Slot	Headline	Subline	Visual	Feeling
1 (hero)
2
3
4
5
6
7
8
9
10 (close)

Screenshot 1 is your billboard. It should make someone laugh, feel something, or ask a question — not explain a feature. MemeScanr’s is “your phone needs therapy” with a Phone Therapist card.

Page 60 — Final Launch Audit Notes

Do the red-team exercise (Book Chapter 15). Pretend you are an Apple reviewer trying to reject your submission. Then run the full 13-step Launch Audit Prompt from Appendix A of the book. Write down everything you find.

Biggest strengths:

Biggest risks:

Must fix before submission:

Nice to improve later:

Page 61 — Launch Confidence Checklist

Bridgette’s note: I almost did not launch MemeScanr because I did not feel ready. Ready is a mirage. If the build works, the trust checklist is clean, and the store listing is honest, you are ready. Press the button.

What am I proud of? _______________________________________
What still needs work? _______________________________________
Am I ready to launch? [ ] Yes [ ] Not yet

If not yet, what is the one specific thing blocking launch?

If that one thing is “I do not feel ready,” the answer is still yes. Ready is a mirage. Ship the imperfect version.

Section 9 — Business Setup

Companion to Book Chapters 4 and 19 (What Ownership Really Means; Brand Is a Container)

Page 62 — Section Divider

Section 9: Business Setup Section 9 of 11 — Outcome: domain, accounts, and ownership layers in your name. [ ] Done [ ] Revisit

The boring stuff that keeps the business alive. Chapter 4 of the book covers the five ownership layers. Chapter 19 covers the brand side and the Individual vs Organization decision that will save you years of regret. These pages are for making the actual decisions.

Page 63 — Naming & Domain

Business name ideas:

Product name ideas:

Domain availability check (do this today):

_______________________________________.com [ ] Available [ ] Taken
_______________________________________.com [ ] Available [ ] Taken
_______________________________________.com [ ] Available [ ] Taken

Business name registered as a domain: [ ] Yes (date: __________) [ ] No Product name registered as a domain: [ ] Yes (date: __________) [ ] No

Register the domains today. This is the smallest irreversible commitment you can make.

The future-regret test: Imagine your product succeeds. A journalist asks who owns the domain. A lawyer asks who controls the developer account. A partner asks where the money goes. If any of those answers make you uncomfortable, fix it today. These decisions are cheap now and expensive later.

Page 64 — Trademark / Conflict Check

Search the USPTO (or your country’s equivalent) and Google for your top business and product name choices.

Names that appear risky or too close to existing brands:

Names that appear clear:

My final choice:

Business name: _______________________________________
Product name: _______________________________________

Page 65 — LLC Setup Tracker

Business name chosen
State search done (is the name available in my state of formation?)
LLC filed
EIN obtained (free from the IRS)
Business bank account opened
Business credit card (or dedicated personal card) set aside
Bookkeeping system started (even a spreadsheet)
Apple Developer account registered as ORGANIZATION (not Individual — see Book Chapter 19, the developer-name-that-will-not-change case study)
DUNS number obtained (if registering as Organization)

Page 66 — Website Planning

Parent brand vs product brand:

If you are building one product and do not plan to build more, a product website is enough (e.g., memescanr.com).

If you think you might build more than one product under the same name, start with a parent brand website (e.g., afialabs.net) and link the product from it.

If you are not sure, register both domains now and decide later. The cost is trivial. The regret of not owning the name is not.

My decision: [ ] Product site only [ ] Parent brand site only [ ] Both

What pages are required for v1?

Home
Privacy policy
Terms of service
Support / contact

What should the homepage communicate in 5 seconds?

Page 67 — Business Email / Support Setup

Domain email created (e.g., hello@yourdomain.com)
Support email created (e.g., support@yourdomain.com)
Contact workflow decided (inbox → triage → respond within 48h)
Auto-reply drafted for new support tickets
Email signature with brand link

Page 68 — Ownership Checklist

Domain in my account (not a contractor’s)
Code in my GitHub org
Payments going to my business account
Support path exists and is monitored
Website is live or planned
Apple Developer account in my name (or my LLC)
All third-party SDK credentials documented

The rule: if you got hit by a bus tomorrow, a competent person could take over your business with the documentation you have. If not, you do not own the business — you just operate it.

Section 10 — Marketing & Monetization

Companion to Book Chapters 17-18 (Launch Day and the Emotional Map; Marketing, Social Media, and Getting People to Care)

Page 69 — Section Divider

Section 10: Marketing & Monetization Section 10 of 11 — Outcome: a launch plan, a pricing staircase, and a posting rhythm. [ ] Done [ ] Revisit

Chapters 16, 17, and 18 of the book cover this territory. Chapter 16 is pricing. Chapter 17 is launch day and the post-launch emotional arc. Chapter 18 is marketing, social media, and distribution as a portfolio. These pages are for making the actual plans.

Page 70 — Audience

Who is the real audience? (One specific persona, as detailed as possible)

Where do they spend time online? (Name 3 specific places)

What language resonates with them? (The words they use, the tone they respond to)

My sample answers:

Who: she is 24, has 180GB of photos, takes 40 new ones a day, follows cleanup accounts on TikTok, and says “ugh, my phone is so full” at least twice a day.

Where: TikTok (phone/aesthetic), specific subreddits about iPhone storage, and Google searches for “best photo cleaner app.”

Language: casual, slightly self-deprecating, meme-literate, allergic to corporate tone.

What can I post before launch? (Build-in-public content)

What can I post after launch?

What founder stories or lessons can I share?

Page 72 — Launch Week Content Calendar

Using the book’s 7-day template (Chapter 17), draft your launch week.

Day 1 (launch announcement): _______________________________________
Day 2 (origin story): _______________________________________
Day 3 (feature demo): _______________________________________
Day 4 (behind the scenes): _______________________________________
Day 5 (user quote): _______________________________________
Day 6 (comparison / teardown): _______________________________________
Day 7 (week 1 reflection): _______________________________________

Page 73 — Pricing Decision

(See Book Chapter 16 for the anchoring staircase and two-trial strategy.)

What revenue model fits best? [ ] Free + paid one-time upgrade [ ] Subscription (monthly / yearly / lifetime staircase) [ ] Freemium with paid features [ ] Pay-to-download [ ] Ad-supported (not recommended for solo consumer apps)

My pricing staircase:

Monthly: $_______
Yearly: $_______
Lifetime: $_______

Trial length: _______ days

Trial type: [ ] StoreKit-managed (Premium trial) [ ] App-managed (feature trial, like MemeScanr’s Backroom)

What is the value of this app in the user’s life? (The answer should be much larger than the price)

My sample answers:

Model: subscription staircase (monthly / yearly / lifetime).

Staircase: $6.99 / $24.99 / $59.99.

Trial: 3-day Premium trial (StoreKit) + 7-day Backroom trial (app-managed, emotional attachment).

Value: the app saves 2-3 hours of manual cleanup per month and removes the guilt of a chaotic camera roll. That is worth more than $6.99.

Page 74 — Monetization Clarity

Why would someone pay? (One sentence. If you cannot answer this in one sentence, your Premium tier is not ready yet.)

What free value exists? (What can a non-paying user do that still feels complete?)

What premium value exists? (What does paying unlock that genuinely matters?)

The emotional premium feature: which of your premium features would a user pay for because of how it makes them feel, not because of what it saves them?

Premium feature audit:

Feature	Emotional value (what does it feel like?)	Rational value (what does it save or enable?)	Worth paying for?
			Y/N
			Y/N
			Y/N
			Y/N

Trial design:

Length: _______ days
Trigger: [ ] StoreKit-managed [ ] App-managed (feature-level)
What emotional state does the trial end in? (urgency? attachment? satisfaction? relief? fear of losing value?)

The enforcement audit: list every pricing rule you advertise. For each, confirm: is there a specific line of code that enforces it? If not, the pricing rule is not a rule. It is a suggestion. (See the Free Tier That Was Not Gated case study in Book Chapter 16.)

Advertised rule	Code file:line that enforces it	Verified?

Page 75 — Post-Launch Metrics

Pick your 5 metrics. Update weekly.

The 5 I will track:

The 5 I will ignore:

Section 11 — Reflection & Next Steps

Companion to Book Chapter 19 (Brand Is a Container) and A Letter to the Builder You Are Becoming

Page 76 — Section Divider

Section 11: Reflection & Next Steps Section 11 of 11 — Outcome: lessons captured and a plan for what comes next. [ ] Done [ ] Revisit

You have shipped (or you are about to). Now what? These final pages are for looking back honestly and looking forward deliberately. Do not rush through them — this section is what turns a shipped product into a foundation for the next one.

Read the closing Letter to the Builder You Are Becoming before you start this section. It follows Chapter 19 in the book.

Page 77 — What I Learned Building This

What surprised me? _______________________________________

What did I learn about building with AI?

What did I learn about myself?

What will I never do again? _______________________________________

What will I always do again? _______________________________________

Page 78 — What I Would Improve Next

What belongs in version 2?

What did users reveal that I did not know before launch?

What still feels weak about the product?

Page 79 — Bigger Brand Thinking

If you are stuck, imagine your product succeeded wildly. What would you build next that could borrow trust from the first thing?

How could this app fit into a larger brand?

What else could this become?

What content, products, or tools could connect to it?

Page 80 — My Next Build Plan

What will I do next? [ ] Improve this app (stay loyal for at least 6 more months) [ ] Launch marketing for this app (shift from building to growing) [ ] Start another product [ ] Take a break before deciding [ ] Other: _______________________________________

If another product, what is the itch? (See Section 2)

Page 81 — Final Reflection Letter to Myself

Write a short letter to the version of you who started this workbook. What do you want her to know? What would you have told her if you could go back?

Sign and date. You will read this again someday. It will matter.

Page 82 — Closing

You do not need to wait for permission to become a builder. You are already becoming one.

Every page you filled in is evidence. Every decision you made is muscle. Every night you showed up instead of quitting is compound interest on a skill you did not have when you started.

I am proud of you. Keep going.

— Bridgette Afia Labs

Milestone — Builder

You shipped. Or you are about to. Either way, you are no longer someone who almost started.

What you should know now:

What you built and why it matters
What you learned that you did not know before
What you would do differently next time

The decision you should have made: What comes next — improve, market, or build again.

You are a builder now. The workbook is evidence. The product is proof.

Optional Bonus Pages

Page 83 — The Afia Labs Test (Personal Version)

From Book Chapter 4. Use this page when you are stuck on a decision.

The decision I am facing:

If my brand were already the company I want it to become, would this decision be on-brand? [ ] Yes [ ] No [ ] Not sure

Would future-me be proud of this decision? [ ] Yes [ ] No [ ] Not sure

What would the version of me who has already shipped say about this?

What am I avoiding by not deciding?

Copy this page. Use it every time a decision feels heavy. The answer usually becomes obvious once you write it down.

Page 84 — AI-Free Brainstorm

Once a month, brainstorm without AI. Just you, a blank page, and your own thoughts. This is how you stay sharp.

What is bothering me about my product right now?

What would I build if AI did not exist? (This question reveals your core taste)

What do I think, that AI would never suggest?

Page 85 — Launch Week Checklist (Detailed)

Final build uploaded to App Store Connect
Release method set (manual or automatic)
First in-app event scheduled
Launch day content drafted and ready to post
10 personal DMs drafted to send to friends
Support inbox ready to respond
Crash reporting configured and tested
Analytics baseline captured
I have a plan for the first 24 hours that is NOT “refresh analytics”

Page 86 — Post-Launch Reflection

Fill in 30 days after launch.

Downloads so far: _______________________________________

Paying users so far: _______________________________________

Biggest surprise:

Best piece of feedback I have received:

Worst piece of feedback I have received:

What am I doing differently in month 2 based on month 1?

Page 87 — Prompt Library Quick Reference

Keep this page for quick reference. All 15 prompts are in Appendix B of the book — here are the 5 I use most.

Feature planning: context + goal + anti-goal + files + “walk me through the questions, smallest version, and edge cases”
Bug fixing: symptom + expected + tried + code + “walk me through 3 root causes before suggesting fixes”
Refactor planning: current code + complaints + “minimum vs ambitious refactor, which for a solo builder on a schedule”
Code review: paste code + “act like a senior engineer reviewing a solo builder’s PR”
“Explain this back to me”: after any suggestion, “let me explain it back to you: the code does X because Y. Did I miss anything?”

The pattern is always the same: context before question, not question before context.

Page 88 — Notes

Space for anything that does not fit elsewhere. Use it however you want.

Back Matter

What to Do Next

If you filled in every page of this workbook, you have already done the work most people never do. The next step is not reading another book. The next step is building.

If you want deeper context on any section, the companion book From Idea to Income with AI Apps goes deeper on every chapter that maps to a section in this workbook. The book is the belief-builder. This workbook is the clarity-builder. Together they get you from “I have an itch” to “I shipped something.”

The course, when it arrives, will be the execution-builder. It will walk you through the whole thing with video, live Q&A, and a community of other builders going through the same process. Watch afialabs.net for updates.

Stay in Touch

support@afialabs.net — I read every message.

afialabs.net memescanr.com

If you ship something after using this workbook, I want to hear about it. That is the whole point.

— Bridgette Owusu Afia Labs Built with AI. Stayed in control. Owned the outcome.