Kandr training playbook
How we build apps, from idea to launch
The exact framework, stack, and prompts we use to take a product from a rough idea to a launched app — written for first-time builders, useful for anyone.
Ask me clarif▍
0
copy-paste prompts
0
phases in the example plan
0
accounts to sign up for
0
launch at the end
How to use the prompts on this page
Every dark card on this page is a real prompt you can steal. The workflow is always the same three steps:
- 1Hit Copy on any prompt card
- 2Paste it into Cursor or Claude
- 3Replace anything in [brackets] with your specifics, then send
New to the jargon? Any word with a dotted underlineA saved snapshot of your code — you can roll back to it anytime. has a plain-English definition — hover or tap it.
Part 01
The philosophy
Two ideas drive everything else on this page.
Don’t reinvent the wheel
Every project doesn’t need to reinvent the wheel. If you build the same core infrastructure the same way every time — same authHow a user proves who they are — in practice, logging in., same database patterns, same design systemA shared set of colors, fonts, and spacing rules so everything looks consistent. — you stop spending energy on setup and start spending it on the actual product.
Broad, then narrow
Get a rough version of the whole thing working first — ugly, incomplete, but end-to-end. Then come back and refine, polish, and tighten. Don’t try to perfect one piece before the rest of the picture exists. This applies to the whole app and to individual pieces like the marketing site.
Part 02
The idea-to-launch framework
Four steps, in order. Each one has a prompt that does the heavy lifting.
Talk it through with an AI agent
Don't wait until you have all the answers. Talk out loud (or type long-form) about the problem you're solving, who it's for, and what you think it needs to do. Use the AI's follow-up questions to find the gaps in your own thinking.
I have an idea for an app. Let me talk through it with you for a few minutes, and I want you to ask me clarifying questions as I go — about the problem I'm solving, who it's for, what features it needs, and anything that sounds unclear or unresolved. Here's the idea: [describe your idea in your own words, problem first, features second].
Turn that into a requirements doc
This doesn't need to be formal or complete. It can be a simple problem statement plus a rough feature list plus open questions you're still not sure about. Treat it as a living document, not a locked spec.
Based on everything we just discussed, put together a simple requirements document. Include the core problem, the target user, a rough feature list, and a section called 'Open Questions' for anything we're still unsure about. Keep it informal — this will evolve as we build.
Build a phased plan for the whole project
Before writing any real feature, work with your AI agent to break the requirements doc into a full plan, broken into phases. Each phase builds on the one before it — starting with foundation, moving through core features, then expansion, then polish, then production-readiness. This plan becomes the governing document for the whole project; you'll work through it phase by phase.
Using this requirements doc, help me build a phased plan for building this whole project — broken into clear phases that each build on the previous one. Start with foundation, move through core features, then expansion, then polish, then production-readiness. Write it out as a markdown plan I can follow phase by phase.
Quality gate between every phase
Before moving to the next phase, do a code review and a quality review. Don't build new work on top of a shaky foundation.
Before I move to the next phase, do a full code review and quality review of everything we just built in this phase. Point out bugs, inconsistent patterns, performance concerns, or anything that would cause problems if I build on top of it as-is.
What a phased plan looks like
One real example — yours will vary by project. The principle stays the same: each phase builds on solid ground from the one before it, moving from foundation to core experience to expansion to polish to production-ready.
What it accomplishes
The invisible foundation: how your data is structured and how the app talks to it. Nothing visible yet, and that's normal.
Why it matters
Every later phase assumes this is solid. Restructuring your data model late in a project is ten times the work of getting it roughly right now.
The standard tech stack
Same tools every time — that’s the point. Sign up for the tools below once; the frameworks come with the project.
The toolbox — sign up for these
Three accounts/downloads and you’re ready to build. Click any card to open it.
The code you build with
You don’t sign up for these — they come with the project once it’s set up.
TypeScript
The language your app is written in
React
The UI library your web app is built with
Tailwind CSS
The utility-class styling from Part 05
Next.js
The framework we use for marketing websites
SwiftUI
Apple’s framework for when you reach the iOS phase
Part 03
Set up your toolbox
The one-time setup every project starts with. Do it once — every project after it gets faster.
The toolbox checklist
Four steps and your workspace is ready to build.
- 1Install Cursor — the editor where you build with AI. The download link lives in the toolbox cards above, in Part 02’s stack section.
- 2Create a FirebaseGoogle's all-in-one backend service: login, database, file storage, and hosting. project — go to the Firebase console, click “Add project,” follow the prompts.
- 3Connect Git + GitHub — initialize a repoShort for repository: the folder where your project and its full history live., connect it to GitHubA website that stores your Git repositories online and backs them up., make your first commitA saved snapshot of your code — you can roll back to it anytime..
- 4Connect your AI coding tool to the project — this lets your AI agent read and interact with your actual backend, so it can help you build faster.
Once you’ve done this once, it becomes fast and automatic on the next project.
If your app needs login: turn on Authentication
AuthenticationHow a user proves who they are — in practice, logging in. = how a user proves who they are. For your app, that simply means logging in.
Not every project needs this — a marketing site never will; an app with user accounts does. When you need it: Firebase console → Build → Authentication → Get Started, then enable the sign-in method you want (email/password, Google, etc.).
Help me set up the toolbox for this project. Walk me through, step by step: creating a Firebase project in the console, initializing Git, pushing my first commit to GitHub, and connecting you to the Firebase project so you can help me build.
My app needs user accounts. Help me enable Firebase Authentication with [email/password or Google] sign-in and wire it into the app, step by step.
Part 04
Two habits that will save you
Not optional — these two habits are the difference between a fun build and a lost weekend.
Commit before every big AI change
AI agents make big changes fast — that’s the whole point. But it means one bad change can break working code. The habit: before you ask the agent for anything big, commitA saved snapshot of your code — you can roll back to it anytime. everything you have so far. If the change wrecks something, you roll back to the snapshot and lose nothing. It’s your undo button.
Before we make this change, help me commit everything we have so far with a clear, descriptive commit message.
When something breaks
You will hit errors — everyone does, every day. Don’t panic and don’t guess. Copy the full error message, say what you expected to happen versus what actually happened, and hand it to the agent. Nine times out of ten it can find the cause from that alone.
I’m getting this error: [paste the full error message]. I expected [what should happen], but instead [what actually happened]. Find the cause and fix it.
Part 05
Advanced: deeper details
Come back to these once the basics feel comfortable.
Why Firebase most of the time?
It bundles authHow a user proves who they are — in practice, logging in., database, storage, and hostingThe service that puts your website on the internet so other people can visit it. in one place, which means less setup and fewer moving parts to manage. Google Cloud comes in when a project needs something more specific that Firebase doesn’t cover well.
Cost note: Firebase’s free Spark plan covers everything while you’re learning — no credit card required. You won’t hit paid tiers on a learning project.
Avoid service sprawl
It’s tempting (especially with an AI agent helping you) to spin up a brand new service every time you need something new. Resist that. First ask: can an existing service be extended or tweaked instead? Too many overlapping services makes a codebase confusing and hard to expand later.
Before we build a new service for this feature, review what services already exist in this project. Tell me whether an existing one could be extended or tweaked to handle this instead of creating something new.
Performance is not optional
Never load more data than the user needs to see right away. If you have a list of 1,000 records, don’t pull all 1,000 on page load — use paginationLoading a long list in small pages (like 25 at a time) instead of all at once., lazy loadingLoading content only when it's needed — for example, as the user scrolls., or “load more” patterns. A slow app loses users no matter how good the features are.
Review this feature for performance. Specifically, check whether we’re loading more data than the user needs on initial page load, and suggest pagination, lazy loading, or similar patterns anywhere we’re not already using them.
Class-based design system
Before building UI, set up a small design systemA shared set of colors, fonts, and spacing rules so everything looks consistent. file — colors, spacing, typography — as reusable utility classesA tiny reusable CSS class that does one job — like "make this text red"., not one-off custom CSS. Every component then looks consistent automatically, and changing one class cascades everywhere it’s used, instead of hunting down every instance.
Before we build any UI, set up a class-based design system for this project — colors, typography, spacing, common component classes. Use utility classes rather than custom one-off CSS, so changes to one class cascade everywhere it’s used.
Automating project setup
Once you’ve manually set up a Firebase project + GitHub repo + auth once, you can script that process with a CLICommand-line interface — a tool you use by typing commands into the terminal. or API so future projects spin up in minutes instead of hours.
Now that I’ve set this up manually once, help me write a script using the Firebase CLI and GitHub CLI that automates creating a new Firebase project, enabling authentication, and setting up a new GitHub repo, so I can spin up future projects in minutes.
Keep your secrets secret
Two rules, no exceptions: never paste an API keyA secret password your code uses to talk to a service — never share it publicly. into a chat or a public place, and never commit your .envA private file on your computer where secret keys live — never commit it to Git. file to Git. If a key ever does end up somewhere public, treat it as stolen — generate a new one right away.
Part 06
The marketing website playbook
Every project gets one — and not just to sell the product.
Building it forces clarity
If you can’t explain your product compellingly on a single page, that’s a signal something about the feature set — or your understanding of it — isn’t sharp enough yet. The standard approach: a single page, built with Next.js, hosted on Firebase HostingThe service that puts your website on the internet so other people can visit it.. First pass broad — get a rough version live so you can see it and react to it. Second pass narrow — refine messaging, layout, and details.
What it needs, at minimum
- A clear explanation of the problem you solve and who it’s for
- Key features, explained simply
- Pricing (if applicable)
- A way to contact you or sign up — contact form, login button, etc.
Part 07
See the playbook applied
A real first app, reviewed — what Caleb got right, and what he's tackling next.
Case study
Caleb's Healthy Hub
Caleb built The Healthy Hub — an app that helps parents find evidence-rated natural remedies for their kids. See the full review: the wins, the two big moves, and the short list of what I'd do next.
Your first session, start to finish
The whole playbook condensed into one sitting. Check things off as you go — your progress is saved in this browser.
The checklist
0 of 6 doneQuestions about the playbook?
This is the exact process we use on our own products. If you want help applying it to yours, we’re happy to talk.