Environment
Something happens around the person.
Day 2 presentation1 / 41
Zero to MVP AI Bootcamp
From human thinking to AI experience
Understand modern AI through clear diagrams, then apply it to a clickable marketplace journey.
Today you ship
A practical AI mental model and responsive marketplace prototype with discovery, provider comparison, availability, and sample booking.
Scroll to move through the presentation.
Learning objectives2 / 41
By the end of today
- 1Compare human perception, memory, judgment, and action with an LLM request without treating them as equivalent.
- 2Build a clear prompt with a goal, context, inputs, constraints, output format, and verification criteria.
- 3Trace the path from early AI to machine learning, transformers, and LLMs.
- 4Distinguish an LLM, RAG system, tool workflow, and agent using MCP-connected actions.
- 5Choose a model category using quality, cost, speed, privacy, modality, and control.
- 6Translate the marketplace journey into the minimum screens and states.
- 7Create clear matching questions with useful validation.
- 8Use realistic provider, service, availability, and price data before connecting live systems.
- 9Review AI-generated interface changes in small steps.
- 10Publish the prototype and fix its biggest usability problem.
Run of show3 / 41
Today’s learning path
- Module 120 min
Your brain and an AI model
- Module 225 min
How to build a good prompt
- Module 325 min
From early AI to LLMs
- Module 430 min
LLMs, RAG, tools, and agents
- Module 525 min
Choose the right AI model
- Module 630 min
Map the booking journey
- Module 745 min
Build discovery and booking inputs
- Module 830 min
Make provider choices believable
- Module 930 min
Observe and improve
- Guided build
AI Service Booking Marketplace · Stage 2
Build, test, checkpoint, and ship.
Module 1 · Learn · 20 min4 / 41
Your brain and an AI model
The brain is a useful starting analogy, not a literal blueprint for AI. Both receive input, detect patterns, use recent context, and produce a response. A human also has a body, lived experience, goals, emotions, values, and genuine understanding that a language model does not possess.
A real example
A child learns the idea of a dog through experiences in the world. A language model learns statistical relationships among tokens from large datasets, then predicts a likely next token when prompted.
Technical terms
- Training
- Adjusting a model's internal numerical weights by learning patterns from many examples.
- Inference
- Using a trained model to produce an answer for a new input.
Module 1 · Reference5 / 41
Useful analogy, important differences
| Concept | Human | AI model | Important limit |
|---|---|---|---|
| Input | Senses and lived experience | Tokens, images, audio, or other data | The model receives only encoded data |
| Learning | Experience, teaching, reflection | Training adjusts numerical weights | Training is not human understanding |
| Current focus | Attention and working memory | Prompt and context window | Context is limited and temporary |
| Memory | Personal and semantic memory | Weights plus external storage | A model does not remember a life |
| Response | Intentional thought and action | Predicted output tokens or actions | Plausible output may be wrong |
| Responsibility | Can hold values and accountability | Follows patterns and instructions | Humans remain accountable |
Module 1 · Diagram6 / 41
Human: from perception to physical action
A simplified learning analogy, not a literal neuroscience model.
1 2 Senses
Eyes, ears, touch, and other senses receive signals.
3 Perception
The brain interprets signals using attention and context.
4 Memory
Experience and learned knowledge influence meaning.
5 Judgment
Goals, values, emotion, and reasoning shape a decision.
6 Body action
Motor signals produce speech, movement, or another action.
7 Feedback
The result changes the environment and informs later learning.
Humans have lived experience, agency, values, embodiment, and accountability. An LLM does not.
Module 1 · Diagram7 / 41
LLM: from prompt to generated response
A language model processes encoded input and repeatedly predicts likely output tokens.
1 Prompt
Instructions and supplied context enter the model request.
2 Tokens
Text is converted into model-readable pieces.
3 Context window
The model considers the tokens available in this request.
4 Trained weights
Learned statistical patterns shape token probabilities.
5 Token prediction
One likely next token is selected, then the cycle repeats.
6 Response
Tokens become text or structured output for the application.
Without tools, the model generates output but does not independently verify facts or act in external systems.
Module 1 · Apply it8 / 41
Apply the concept
Trace both diagrams and identify where the brain analogy stops being accurate.
- 1Match senses to model input, attention to relevant context, long-term learning to trained weights, and an action to model output.
- 2Write where each comparison is useful.
- 3Mark the limits: consciousness, lived experience, emotion, values, intent, and accountability.
- 4Explain why a fluent answer can still be false and must be verified.
Success looks like
You can use the analogy to explain AI while clearly stating where it breaks down.
Watch for
- Do not describe model parameters as tiny facts or neurons as exact copies of biological neurons.
- Fluency is evidence that a model predicts language well, not proof of truth or understanding.
Module 2 · Learn · 25 min9 / 41
How to build a good prompt
A good prompt is a clear working brief, not a magic phrase. It tells the model what outcome is needed, why it matters, which information it may use, what boundaries it must respect, and how the result should be presented and checked. Prompt quality improves through testing and revision, not through length alone.
A real example
Vague: “Find the best plumber.” Better: “Using only the supplied provider records, rank up to three plumbers for a leaking pipe in Cairo this week within a stated budget. Explain each fit using record evidence, show price and verified availability, and ask one clarifying question if essential information is missing. Do not invent providers or time slots.”
Technical terms
- Prompt
- The instructions, context, inputs, and requested output sent to a model for one task.
- Constraint
- A boundary the response must respect, such as approved sources, budget, length, privacy, or actions it may not take.
Module 2 · Reference10 / 41
Prompting: what to do and what not to do
| Concept | Do | Do not |
|---|---|---|
| Goal | Request one specific outcome and explain its purpose | Use a vague instruction such as “make this better” |
| Context | Provide the relevant situation, audience, and approved inputs | Dump every document into the prompt or assume hidden company knowledge |
| Boundaries | State source limits, privacy rules, exclusions, and forbidden actions | Include secrets or let the model invent missing facts |
| Output | Specify the structure, level of detail, tone, and required fields | Leave “good” undefined and hope for the right format |
| Uncertainty | Tell the model to ask, abstain, or state uncertainty when evidence is missing | Force an answer when the available information is insufficient |
| Review | Test realistic cases, verify claims, and improve one weakness at a time | Treat the first fluent response as final or factual |
Use roles only when a perspective or domain lens is genuinely useful. A role is not a substitute for evidence or clear instructions.
Module 2 · Diagram11 / 41
Anatomy of a good prompt
Build the request in layers so both the model and the reviewer know what success means.
1 Task
State the specific action and outcome in a clear verb-led sentence.
2 Purpose
Name the audience, business context, and decision the output supports.
3 Inputs
Supply relevant facts, records, examples, and approved sources.
4 Constraints
Set boundaries for privacy, scope, sources, length, tone, and actions.
5 Output
Define the required structure, fields, order, and level of detail.
6 Success test
Describe the criteria a reviewer will use to accept the result.
7 Clarify + verify
Handle missing information, check claims, and revise weak instructions.
Specificity helps only when it is relevant. The best prompt is clear enough to produce and evaluate the intended result, not the longest prompt.
Module 2 · Apply it12 / 41
Apply the concept
Rewrite one vague marketplace request, compare the two outputs, and identify which prompt details improved the result.
- 1Choose one vague business request and state the real task, audience, purpose, and decision it should support.
- 2Add only the relevant context and clearly separate supplied records from your instructions.
- 3Define constraints, source boundaries, output format, success criteria, and what to do when information is missing.
- 4Run the vague and improved prompts with the same model, then compare relevance, completeness, evidence, and usability.
- 5Verify important claims and revise one unclear instruction rather than adding unrelated requirements.
Use this prompt
Task: [State the specific action and outcome.] Audience and purpose: [Who will use the result, why, and what decision it supports.] Context and approved inputs: [Provide only relevant information and identify the sources the model may use.] Constraints: [State boundaries, exclusions, privacy rules, length, tone, and actions that are not allowed.] Output format: [Specify sections, fields, table, JSON, checklist, or other structure.] Success criteria: [Describe what a correct, useful answer must contain.] If information is missing: [Ask focused clarifying questions, state uncertainty, or return “insufficient information.”] Before finalizing: [Check the output against the sources, constraints, and success criteria.]
Success looks like
Another person can run the prompt, understand the requested outcome, inspect the evidence, and judge the result against explicit criteria.
Watch for
- Never paste passwords, private customer data, confidential documents, or API keys into an unapproved AI service.
- A dramatic persona such as “you are the world’s greatest expert” cannot replace task context, evidence, or acceptance criteria.
- Do not trust confident wording. Verify consequential facts, calculations, citations, and recommendations.
Module 3 · Learn · 25 min13 / 41
From early AI to LLMs
AI did not begin with chatbots. The field moved from hand-written rules, through systems that learned statistical patterns, to deep neural networks and transformers trained on enormous datasets. Each wave expanded what machines could do, but none removed the need for clear goals and verification.
A real example
An early spam filter might use rules such as 'if the subject contains FREE, flag it.' A machine-learning filter learns patterns from labeled email. A modern language model can explain why a message looks suspicious, but may still make a confident mistake.
Technical terms
- Transformer
- A neural-network architecture that learns relationships across sequences using attention.
- Foundation model
- A large pretrained model that can be adapted to many downstream tasks.
Module 3 · Timeline14 / 41
How we arrived here
From rules to generative AI
1950s–1960s
The field takes shape
Researchers ask whether machines can reason and create early symbolic programs.
1970s–1980s
Expert systems
Humans encode specialist knowledge as rules such as IF condition THEN action.
1990s–2000s
Statistical machine learning
Systems learn patterns from labeled data for search, spam, speech, and recommendations.
2010s
Deep learning
Larger neural networks, datasets, and compute improve vision, speech, and language.
2017
Transformer architecture
Attention mechanisms enable models to learn relationships across long token sequences efficiently.
2018–2021
Foundation models
Large pretrained models adapt to many tasks through prompts or additional training.
2022–today
Generative and agentic products
Chat, multimodal input, retrieval, tools, and controlled action loops become product building blocks.
Module 3 · Reference15 / 41
The AI family tree
| Concept | Plain-English meaning | Familiar example |
|---|---|---|
| Artificial intelligence | The broad field of machines performing tasks associated with intelligence | Planning, vision, speech, recommendations, and language |
| Machine learning | Systems learn patterns from examples instead of receiving every rule | Spam detection and product recommendations |
| Deep learning | Machine learning using multi-layer neural networks | Speech recognition and image understanding |
| Transformer | A neural-network architecture especially effective at relationships across sequences | Modern language and multimodal models |
| Foundation model | A large pretrained model adaptable to many downstream tasks | A base model used for writing, coding, search, or vision |
| Large language model | A foundation model focused on processing and generating language as token sequences | Drafting, extraction, classification, and conversation |
| Generative AI | Systems that create new text, images, audio, video, or code | Chat assistants, image generators, and coding assistants |
Module 3 · Apply it16 / 41
Apply the concept
Place the AI milestones on a timeline and explain what changed at each step.
- 1Place rule-based AI, machine learning, deep learning, transformers, foundation models, and assistant systems in order.
- 2For each milestone, state what the developer supplied and what the machine learned.
- 3Separate training from inference and pretraining from task-specific prompting.
- 4Explain why more capability can also create new cost, safety, and reliability risks.
Success looks like
You can place LLMs inside the larger AI family and explain the difference between a model being trained and a product using it.
Watch for
- AI is the umbrella. Machine learning is one approach, deep learning is a machine-learning approach, and LLMs are one deep-learning model family.
- ChatGPT, Claude, and Gemini are products or model families, not synonyms for all AI.
Module 4 · Learn · 30 min17 / 41
LLMs, RAG, tools, and agents
An LLM is one component, not the entire AI product. Give it retrieved knowledge and you have a RAG pattern. Give it controlled functions and it can use tools. Let it choose and repeat actions toward a goal, with limits and checks, and you have an agentic system.
A real example
Asked about a refund, a plain LLM drafts a general answer. RAG first finds the company's policy. A tool-using workflow checks the order. An agent may gather evidence, select an allowed action, request approval, execute it, and verify the result.
Technical terms
- RAG
- Retrieval-Augmented Generation: find relevant trusted information and place it in the model's context before it answers.
- Agent
- A goal-directed system in which a model can choose among controlled actions, inspect results, and continue until a stopping rule.
Module 4 · Reference18 / 41
Choose the smallest useful pattern
| Concept | What it adds | Use it when | Main risk |
|---|---|---|---|
| Normal software | Deterministic rules | The outcome is known and repeatable | Rules become hard to maintain |
| LLM | Flexible language generation | The task needs interpretation or generation | Confident unsupported output |
| RAG | Retrieved trusted context | Answers depend on private or changing knowledge | Wrong retrieval produces wrong context |
| Tool workflow | Live data or controlled actions | Steps are known in advance | Permissions and integration failures |
| Agent | Chooses and repeats actions | The path varies and needs planning | Runaway cost, unsafe action, hard evaluation |
Complexity should be earned by a requirement, not added because a term is popular.
Module 4 · Diagram19 / 41
RAG: retrieve before generating
Retrieval-Augmented Generation adds relevant trusted knowledge to the request without retraining the model.
1 User question
The application receives a request needing trusted knowledge.
2 Search query
The request is converted into keywords or an embedding.
3 Knowledge search
Relevant provider, policy, or document records are retrieved.
4 Context assembly
Instructions, question, and selected sources form one prompt.
5 LLM generation
The model answers using the supplied evidence.
6 Answer + sources
The application validates and displays grounded output.
RAG quality depends on both retrieval quality and generation quality. Missing or irrelevant sources weaken the answer.
Module 4 · Diagram20 / 41
Agent actions through MCP
MCP provides a standard connection between an AI application and approved tools or data sources.
1 Goal
The user asks for an outcome, not only a text answer.
2 Agent loop
The model plans the next controlled action.
3 MCP client
The AI application discovers and calls approved capabilities.
4 MCP server
A server exposes named tools, resources, or prompts.
5 External system
Calendar, database, files, browser, or business API performs work.
6 Tool result
The result returns to the agent for inspection.
7 Check or continue
The agent stops, asks approval, retries, or chooses another tool.
MCP is the connection layer, not the intelligence. Permissions, human approval, budgets, logs, and stopping rules still control the agent.
Module 4 · Apply it21 / 41
Apply the concept
Classify everyday AI products and trace one agent action through MCP.
- 1Begin with the smallest solution: normal software rules or one model request.
- 2Add RAG only when the answer requires private, current, or source-backed knowledge.
- 3Add a tool when the system must obtain live data, calculate, or change another service.
- 4Use an agent loop only when the path cannot be fixed in advance; add permissions, budgets, logs, approval, and stopping rules.
Success looks like
You can choose the least complex pattern that meets the need and explain why an agent is not automatically better.
Watch for
- RAG does not retrain the model; it supplies relevant information at request time.
- Calling one API in a fixed sequence is tool use or automation, not necessarily an agent.
Module 5 · Learn · 25 min22 / 41
Choose the right AI model
There is no single best model. A useful choice satisfies the product's quality threshold while meeting limits for speed, cost, privacy, language, context length, modality, tool use, deployment, and licensing. Model catalogs change quickly, so test current candidates with your own cases.
A real example
A high-volume category label may need a fast inexpensive model. A difficult coding migration may justify a frontier reasoning model. Sensitive offline summarization may require a smaller open-weight model running inside the organization.
Technical terms
- Commercial API
- A provider hosts the model and charges for access, reducing infrastructure work.
- Open-weight model
- Downloadable model parameters available under a license; this does not always mean open-source training data or unrestricted use.
Module 5 · Reference23 / 41
Core language-model types
| Concept | Best for | Trade-off |
|---|---|---|
| Base or pretrained | Further training, research, or specialized adaptation | Usually not the right direct interface for an end-user product |
| General instruct | Writing, extraction, classification, support | Balanced rather than strongest at one specialty |
| Reasoning | Complex planning, analysis, math, difficult decisions | Usually slower and more expensive |
| Coding | Code understanding, generation, debugging, repository work | Must still be tested in the real codebase |
Module 5 · Reference24 / 41
Specialized model types
| Concept | Best for | Trade-off |
|---|---|---|
| Multimodal | Text plus images, documents, audio, or video | Input support and quality vary by modality |
| Realtime voice | Low-latency spoken interaction | Conversation quality, latency, and interruption handling matter |
| Embedding | Search, similarity, clustering, and RAG retrieval | Produces vectors, not a user-facing answer |
| Small or local | Privacy, offline use, edge devices, high volume | Lower capability or more deployment work |
Module 5 · Reference25 / 41
Representative current commercial families
| Concept | Provider | Good starting point | Consider when |
|---|---|---|---|
| GPT-5.6 family | OpenAI | General, reasoning, coding, tools, and multimodal products | You want a broad hosted platform and frontier models |
| Claude Opus 5 / Sonnet 5 | Anthropic | Long work, coding, professional tasks, and agents | You value strong instruction following and agentic workflows |
| Gemini 3.1 Pro / 3.6 Flash | Multimodal, long context, Google ecosystem, or high-throughput work | You need a Pro-versus-Flash quality, speed, and cost choice | |
| Grok 4.5 | xAI | Reasoning, coding, tools, and realtime information products | Its capabilities, ecosystem, and policies fit the product |
This is a dated snapshot. Availability and names can change, so verify the live provider catalog.
Module 5 · Reference26 / 41
Representative open-weight families
| Concept | Organization | Consider when | Verify first |
|---|---|---|---|
| Llama 4 | Meta | You need a broad ecosystem and deployment choices | License, hardware, and task quality |
| Qwen 3.6 / Qwen Coder | Alibaba Qwen | You need multilingual, coding, or varied model sizes | License and language-specific evaluation |
| DeepSeek V4 family | DeepSeek | You want cost-conscious reasoning or coding options | Current release status, hosting, data policy, and license |
| Mistral Small 4 and specialists | Mistral AI | You value efficient models, deployment control, or European hosting | License and whether a specialist or general model fits |
| Gemma / Phi families | Google / Microsoft | You need smaller local, research, or edge-friendly options | Device performance and task capability |
Open-weight is not automatically open source, free, private, or permitted for every commercial use.
Module 5 · Apply it27 / 41
Apply the concept
Select a model category for the marketplace and defend it with measurable constraints.
- 1Define the task and create ten representative evaluation cases.
- 2Set required modalities, privacy boundary, latency target, and maximum cost.
- 3Shortlist one frontier model, one balanced model, and one low-cost or self-hosted option.
- 4Run the same cases, compare quality and operational fit, then pin the selected model version and monitor changes.
Success looks like
Your selection can be defended with test results and product constraints, not brand preference.
Watch for
- Provider names and model versions age quickly; verify the live catalog, pricing, availability, and deprecation policy before implementation.
- Open weights give control, not free operations. Include hardware, hosting, security, updates, and licensing in the cost.
Module 5 · Live references28 / 41
Model catalogs change
Verify the live provider source
This deck is a dated snapshot. Before choosing or deploying a model, confirm its current name, status, pricing, availability, context, modalities, and deprecation policy.
OpenAI model catalog
Current GPT and specialist models
Anthropic model overview
Current Claude tiers and selection guidance
Google Gemini models
Current Pro, Flash, multimodal, and specialist models
xAI models
Current Grok catalog and capabilities
Meta Llama
Official Llama family information
Qwen model catalog
Official Qwen organization and open-weight releases
DeepSeek models
Current hosted models and pricing
Mistral model overview
Commercial and open-weight model families
Model-family snapshot last reviewed: 31 July 2026.
Module 6 · Learn · 30 min29 / 41
Map the booking journey
A good marketplace journey gives the customer one clear decision at a time. Before coding, decide what they see while discovering services, describing a need, comparing providers, selecting a time, reviewing, and confirming.
A real example
A customer selects home cleaning, describes the apartment and preferred date, compares three providers, chooses an available slot, reviews the total, and confirms.
Technical terms
- User journey
- The sequence of steps a person takes to reach an outcome.
- State
- What the interface shows at a particular moment.
Module 6 · Apply it30 / 41
Apply the concept
Sketch the entire journey in no more than five frames.
- 1Draw discovery, matching questions, provider options, availability, review, and confirmation.
- 2Write the one main action available on each screen.
- 3Add error and retry paths without creating dead ends.
- 4Remove any screen that does not help the customer complete a confident booking.
Use this prompt
Turn this service-booking journey into the minimum number of screens. For each screen, list its purpose, visible information, primary action, and possible error state. Keep the interaction familiar to users of modern booking apps.
Success looks like
A partner can follow the screen map from discovery to booking confirmation without asking where to click next.
Watch for
- If a screen has several equally important buttons, choose one primary action.
- If the map becomes larger than five screens, combine steps or move optional information after the result.
Module 7 · Learn · 45 min31 / 41
Build discovery and booking inputs
Matching and booking inputs are a conversation. Each question should be easy to understand and collect only what is needed to recommend a provider or reserve a time.
A real example
Instead of asking 'Budget?', ask 'What price range works for this booking?' and show ranges that match actual marketplace services.
Technical terms
- Validation
- A check that required information is present and usable.
- Component
- A reusable part of an interface, such as a question field or button.
Module 7 · Apply it32 / 41
Apply the concept
Build one form section, review it in the browser, and request one targeted correction.
- 1Build the service-needs form with a title and progress indicator.
- 2Add one question and verify its label and keyboard behavior.
- 3Repeat the approved pattern for the remaining questions.
- 4Add clear validation and preserve needs, preferences, date, and location when navigating back.
Use this prompt
Build one accessible service-needs question using the existing project styles. It needs a visible label, helpful example, required-field message, keyboard support, and no database connection. Show me the changed files when done.
Success looks like
All six questions are readable, usable with keyboard or touch, and clearly explain missing information.
Watch for
- If the AI redesigns unrelated pages, revert and restrict the request to one component.
- If validation appears before the visitor interacts, ask for messages only after submit or leaving the field.
Module 8 · Learn · 30 min33 / 41
Make provider choices believable
Before using real AI or live availability, prove that provider results communicate enough value for a customer to choose confidently.
A real example
Best match: Lina Home Services. Why: serves your location, fits the budget, and has a highly rated two-hour deep-clean service available Friday at 10:00.
Technical terms
- Sample data
- Realistic example information used before live services are connected.
- Empty state
- The helpful screen shown when no result or records exist yet.
Module 8 · Apply it34 / 41
Apply the concept
Create three customer requests and matching provider cards with sample time slots.
- 1Write three customer requests with different needs, budgets, locations, and dates.
- 2Create three realistic provider profiles, services, prices, ratings, and time slots.
- 3Design each result around provider fit, reason, price, availability, and booking action.
- 4Check long names, no matches, unavailable slots, and incomplete profiles.
Use this prompt
Create responsive provider-match cards using sample data. Show provider, service, fit reason, price, rating, next available slots, and booking action. Include loading, no-match, unavailable-slot, and retry states. Do not connect AI or a database yet.
Success looks like
A customer can compare options and explain why they would choose one provider after viewing the results briefly.
Watch for
- If the result reads like generic marketing, connect every fit reason to a customer need or provider fact.
- If long text breaks the layout, test with a result twice as long as the ideal example.
Module 9 · Learn · 30 min35 / 41
Observe and improve
Usability testing is watching what people do, not asking whether they like the design. Silence reveals where the product fails to explain itself.
A real example
Ask a partner to find and book a suitable service for a realistic need. Do not tell them where to start. Record every pause, wrong click, and question.
Technical terms
- Usability test
- Observing someone attempt a realistic task with the product.
- Task success
- Whether a user completes the intended journey correctly without assistance.
Module 9 · Apply it36 / 41
Apply the concept
Run a five-minute peer test and fix one high-impact issue.
- 1Give the tester one realistic goal.
- 2Observe without teaching, defending, or taking control.
- 3Write down hesitation, wrong actions, questions, and failures.
- 4Fix the first blocker and run the same task again.
Use this prompt
Here are my usability-test notes. Group them into blockers, confusion, and polish. Recommend only the single highest-impact fix and define how I should verify it.
Success looks like
The second tester completes the core journey with less hesitation and no help at the corrected point.
Watch for
- If the tester asks what to do, answer with 'What would you try?' and keep observing.
- Do not fix five things at once; one verified improvement is more valuable than several guesses.
Guided project37 / 41
Build brief
AI Service Booking Marketplace · Stage 2
Build and publish the complete customer-facing journey using realistic providers, services, availability, and sample booking data.
User story
As a customer, I can describe what I need, compare suitable providers, and reserve a time.
Guided build · Part 138 / 41
Build it step by step
Create the journey shell
Build discovery, matching, provider, availability, review, and confirmation screens.
Add matching questions
Capture service need, location, budget, preferred date, and important preferences.
Show provider options
Display provider fit, service, price, rating, and realistic sample availability.
Guided build · Part 239 / 41
Build it step by step
Select a time
Allow the customer to choose an available slot and review the booking.
Complete every state
Add loading, empty, validation, error, retry, and reset experiences.
Publish and peer test
Open the public link on another device and fix the first observed blocker.
Ship checkpoint40 / 41
Do not ship until
- A visitor understands the product purpose within five seconds.
- The full discovery-to-booking journey works without dead ends or instructor explanation.
- Matching and booking inputs work at mobile and desktop widths.
- Provider options make fit, price, availability, and next action clear.
- The public link loads and the top peer-test issue is fixed.
Wrap and prepare41 / 41
Ship it. Show it. Prepare the next move.
Before the next day
- Write the exact job the AI performs for each customer request.
- Prepare provider profiles, service facts, matching rules, and booking policies.
- List five requests the marketplace should refuse, clarify, or send to human support.