Capture the spark
Capture the spark
- Turn a vague "wouldn't it be cool if…" into a sharp, testable concept
- Start from a problem, not a feature, so the idea can survive contact with reality
- Write a one-sentence concept using the "job to be done" frame
- Recognize when your "idea" is actually just a technology looking for a use
// Ideas are cheap. Sharp concepts are rare.
Everyone has ideas. What separates a project that ships from one that dies in a notes app is sharpness: a concept specific enough that you could explain it to a stranger in one breath and they'd immediately get who it's for and why it matters. "An app with AI" is not a concept. "A tool that turns a plumber's voice memo into a formatted, priced invoice before they leave the driveway" is.
Most great products start from a problem someone already feels, not from a cool technology. When you start from the tech ("I want to use AI!") you tend to bolt intelligence onto something nobody asked for. When you start from a problem, the technology becomes a tool in service of a real need — which is exactly where AI earns its place (Phase 03).
What "job to be done" means
People don't buy products; they "hire" them to get a job done. Someone doesn't want a drill — they want a hole. Ask: what job is my user trying to get done, and what are they hiring today to do it? Your product has to do that job better than whatever they use now (a spreadsheet, a group chat, a person, nothing at all).
Problem-first vs. solution-first
Solution-first ideas ("let's build an AI X") are faster to get excited about and far more likely to fail, because you fall in love with the build before knowing if anyone needs it. Problem-first is slower and less glamorous but lets you change the solution while keeping the mission. Rule of thumb: you can pivot the solution cheaply; you can't pivot away from a problem nobody has.
Where sharp ideas actually come from
Not brainstorms. They come from (1) problems you personally live — you're the expert user; (2) watching people work and noticing the ugly workaround (the spreadsheet held together with copy-paste, the "we just do it manually"); (3) expensive or slow things that intelligence could compress; (4) things that were impossible last year and just became possible because models got cheaper/better. That fourth category is where AI-native ideas hide.
Treat the concept as a falsifiable bet
Write your concept as a claim you could be wrong about: "We believe [user] will [take a specific action] because [problem] is painful enough that they'll switch from [alternative]." A concept you can't imagine being wrong isn't sharp — it's a wish. The rest of the course is a machine for testing that bet cheaply before you spend months building.
// Walkthrough — write your concept statement
- Name the person, not "users." Write one specific human: "Maria, a shift lead at a 40-person restaurant." Vague audiences produce vague products.
- Name the job. What is Maria trying to get done? ("Cover a shift when someone calls out sick, fast, without texting 15 people.")
- Name today's tool + why it's bad. ("A group text — slow, messy, no one commits, she ends up covering it herself.")
- Write the one-sentence concept: "[Product] helps [specific person] [do the job] without [the pain of the current way]."
- Say it out loud to someone. If they don't instantly get it, cut words until they do. Drop it into the Idea Forge above.
image generator prompt + alt text
- Starting from the tech. "I want to build something with AI" is a hobby, not a concept. Start from a problem.
- "Everyone" is the user. If it's for everyone, it's for no one. Narrow until it's uncomfortable.
- Feature-listing. "It has X, Y, Z" hides the fact that you can't say what job it does.
- Falling in love with the solution. You'll defend a bad idea you're attached to. Stay attached to the problem instead.
- Confusing "cool" with "needed." Cool demos die. Needed tools get used on a boring Tuesday.
Q1Which is a genuine concept, not just an idea?
Q2"Job to be done" thinking asks you to focus on…
Q3Why is "problem-first" usually safer than "solution-first"?
Q4Your target user is "small business owners." What's the fix?
Q5An "idea" that's really a red flag looks like…
Write your concept and pressure-test it on a real person.
Build the first version
Build the first version
- Build effectively with AI tools using spec-first, small-step prompting
- Design AI features users trust: streaming, latency, "show your work"
- Handle wrong answers gracefully instead of pretending the AI is perfect
- Know when to give the model more context (and how, at a basic level)
// Building with AI is a conversation, not a wish
Whether you're in Lovable or Cursor, the skill is the same: describe clearly, build in small steps, and check each step. Don't ask for the whole app in one giant prompt — you'll get a tangle you can't debug. Give the tool a short spec (what the screen does, what data it uses, what "done" looks like), let it build one piece, verify it works, then move to the next. Treat the AI like a fast junior developer who needs clear instructions and review.
The second half of this phase is AI UX — how the intelligence feels to the user. This is where most AI products win or lose. A technically-fine model wrapped in a confusing, untrustworthy interface fails; a modest model wrapped in honest, well-designed UX succeeds.
image generator prompt + alt text
How to describe what you want
Be concrete. Instead of "make it nice," say what the screen contains, in order: "A page with a text box labeled 'Paste your notes', a button 'Summarize', and below it a card that shows the summary. When I click Summarize, send the text to the AI and show the result in the card." Build that. Then add the next thing. When something's wrong, describe the symptom ("the button does nothing when clicked") — the tool can usually fix it.
Four habits of AI features people trust
(1) Stream the output so users see progress instead of a frozen spinner. (2) Set expectations — a first-person-plural "Drafting…" beats silence, and a note that output may need review sets an honest frame. (3) Show your work — cite sources, show what the AI used, or let users see/edit the input. (4) Make output easy to correct — editable results, a thumbs-down, a regenerate. Users forgive an AI that's honest and correctable; they abandon one that's confidently wrong with no recourse.
Giving the model what it needs — safely
When the model needs facts it wasn't trained on (your docs, the user's data), the basic move is retrieval: fetch the relevant snippets and include them in the prompt, rather than fine-tuning or hoping the model "knows." Keep the retrieved context tight and relevant. On guardrails: constrain what the model can output (a fixed set of choices, a required format), validate its output with code before acting on it, and never let raw model text trigger a dangerous action without a check. The model proposes; your code disposes.
Structured outputs and tool-calling
For anything programmatic, have the model return structured output (e.g., strict JSON) you can parse, rather than prose you regex. Modern SDKs (like the Vercel AI SDK) make streaming, structured outputs, and tool-calling — where the model can call your functions to fetch data or take actions within guardrails — straightforward. Design the tool surface deliberately: each tool does one clear thing, with validation on inputs and outputs. This is the backbone of moving from "chatbot" to genuinely useful, agentic behavior.
// Walkthrough — build the core loop
- Write a one-paragraph spec of just the MVP's core screen and the AI action it performs.
- Prompt the build tool for that screen only. Verify the layout and buttons work before adding logic.
- Wire the AI call. Connect the input → model → visible result. Test with 5 real inputs.
- Add trust UX: streaming/loading state, an "output may need review" note, and an editable/regeneratable result.
- Feed real context if needed (the user's text, your reference docs) rather than hoping the model knows.
- Validate outputs in code before doing anything consequential with them. Then move to the next feature.
- One giant prompt for the whole app. You get an unmaintainable tangle. Build in small, verified steps.
- Frozen spinner, no feedback. Stream output and show what's happening.
- Pretending the AI is always right. No edit, no correction, no "show your work" = broken trust.
- Trusting raw model text to trigger actions. Validate with code first; the model proposes, code disposes.
- Parsing prose with regex. Ask for structured output you can safely parse.
Q1The best way to build with an AI tool is to…
Q2Streaming the AI's output matters because…
Q3"The model proposes; your code disposes" means…
Q4When the model needs facts it wasn't trained on, the basic move is…
Q5Users forgive an AI feature most when it is…
Build and pressure-test your core loop.
Ship & grow
Ship & grow
- Deploy your MVP and get it in front of real users
- Instrument the product so you can see what's actually happening
- Run a tight learn-and-iterate loop against your success metric
- Build toward a data flywheel — the moat AI-native products earn over time
// Shipping is the start of learning, not the end of building
Perfect is the enemy of shipped. Once your MVP does its one core job and won't embarrass you (or endanger anyone), get it in front of real users. Launch small and specific: the community where your target person already lives beats a giant, unfocused blast. Ten engaged users who use it weekly teach you more than a thousand who signed up and vanished.
The goal now is a loop: ship → measure against your one metric → learn → improve → ship again. AI-native products have a special advantage here — every use can generate signal that makes the product smarter in ways competitors can't easily copy. That compounding is the moat.
image generator prompt + alt text
From "on my screen" to "on the internet"
If you built in an app builder, it usually has a one-click publish — use it. If you built in code, deploy on a host like Vercel or Netlify (both have generous free tiers and connect to your code repository). Get a simple link you can share. Then tell exactly the right people: not "everyone," but the specific community where your target user already hangs out. A short, honest post ("I made this to solve X — would love your feedback") outperforms hype.
Instrument your funnel
You can't improve what you can't see. Track the core funnel: visited → started the core action → completed it → came back. Watch where people drop off — that's your next fix. Also log (privately and respectfully) which AI outputs users edit, reject, or regenerate; those are gold for improving quality. One honest activation number plus a drop-off map beats a dashboard of vanity metrics.
Charging, and keeping users
You don't need pricing figured out to launch, but charge something sooner than feels comfortable — willingness to pay is the ultimate validation, and free users give unreliable signal. Price on the value delivered, not your costs, and never promise specific outcomes or returns. Retention beats acquisition: a product users open every week compounds; one they try once and forget doesn't, no matter how many sign up. Fix the "come back" step before pouring effort into the "sign up" step.
Turn usage into a compounding advantage
The durable moat for an AI-native product isn't the model (everyone can rent the same one) — it's the proprietary, high-fidelity data your product accumulates through real use, wired into a feedback loop that makes each interaction improve the next. Design that loop deliberately: capture the right signal (with consent), feed it back into quality, and integrate so deeply into the user's workflow that leaving is costly. When better base models arrive, this is what makes you happy instead of replaceable. (Sources 2, 12.)
// Walkthrough — launch and start the loop
- Publish/deploy your MVP and get a shareable link. Keep keys server-side.
- Add basic analytics on the core funnel: visit → start → complete → return.
- Launch small and specific: post where your exact users are, honestly, asking for feedback.
- Measure against your one metric. Did you hit the threshold you set in Phase 04?
- Pick the biggest drop-off and fix that one thing. Ship the improvement.
- Decide the moat move: what signal will you capture so the product compounds? When do you bring in a developer to harden what works?
If you complete this phase, you've gone from a spark to a real, working, hardened AI web product that people can use — and a loop to keep making it better. That is further than ~80% of AI projects get. Now the work is learning in public and compounding. Bring in a developer to harden the parts that are working and worth scaling.
- Polishing forever. Waiting for "perfect" means never learning from real users.
- Launching to "everyone." Unfocused blasts fizzle; go where your specific user already is.
- No analytics. You can't fix drop-off you can't see.
- Chasing signups over retention. A leaky bucket doesn't fill faster with more water.
- Never charging. Free-only signal is weak; willingness to pay is real validation.
Q1The best first launch audience is…
Q2Instrumenting your funnel means…
Q3The durable moat for an AI-native product is usually…
Q4Which matters more for long-term success?
Q5On pricing, a sound principle is…
Launch and open the learning loop.