Customer app
The frontend sends basket, address, and payment choice.
Day 1 presentation1 / 18
Zero to MVP AI Bootcamp
From real life to software
Start with familiar workflows, then see how software components turn them into connected, scalable systems.
Today you ship
A practical software mental model and a working project shell for the AI Service Booking Marketplace.
Scroll to move through the presentation.
Learning objectives2 / 18
By the end of today
- 1Translate a familiar business workflow into software components.
- 2Explain frontend, backend, API, database, authentication, and cloud using everyday analogies.
- 3Trace how customer, restaurant, courier, payment, and notification systems coordinate one food order.
- 4Apply the complete mental model to the shared AI Service Booking Marketplace and start its project shell safely.
Run of show3 / 18
Today’s learning path
- Module 120 min
From business workflow to software
- Module 230 min
How software works
- Guided build
AI Service Booking Marketplace · Stage 1
Build, test, checkpoint, and ship.
Module 1 · Learn · 20 min4 / 18
From business workflow to software
Software starts with an operating model people already understand. Someone receives information, applies business rules, makes a decision, records the outcome, and communicates the next action. Software makes that workflow consistent and scalable by assigning each responsibility to a digital component.
A real example
Without a marketplace, a customer searches for providers, calls to compare services, asks about availability, confirms a time by message, and arranges payment separately. Our product connects that familiar journey.
Technical terms
- Business rule
- An explicit condition that tells software what decision or action should follow.
- Human-in-the-loop
- A design where software handles routine work while a person reviews sensitive, uncertain, or exceptional cases.
Module 1 · Reference5 / 18
The same job in two worlds
| Concept | People-led workflow | Digital capability |
|---|---|---|
| Receive information | Meeting, email, or document | A digital form or conversation |
| Pass the request | Email or internal handoff | A secure system connection |
| Apply rules | Coordinator or specialist | Automated decision rules |
| Keep a record | Spreadsheet or CRM entry | Searchable shared storage |
| Recognize patterns | Human experience | Pattern-based assistance |
| Follow up | Manual email or call | Triggered messages and tasks |
| Handle exceptions | Manager judgment | Escalation to a person |
Module 1 · Apply it6 / 18
Apply the concept
Map a familiar business workflow before translating it into software.
- 1Choose a workflow you know well, such as customer qualification, procurement approval, or employee onboarding.
- 2Mark its trigger, intended outcome, and the people involved.
- 3Identify the information, decision, record, handoff, and exception at each stage.
- 4Mark where human judgment and accountability must remain.
Success looks like
A one-page business workflow map that Module 2 can relabel with the correct software components.
Watch for
- Describe the current workflow, not an ideal future solution.
- Keep technology names out of the map until Module 2 introduces them.
Module 2 · Learn · 30 min7 / 18
How software works
A software product is a conversation between specialized parts. The frontend collects an action, an API carries a structured request to the backend, the backend applies protected rules, and the database stores or returns information before a response travels back.
A real example
Think of a restaurant. The menu and dining room are the frontend, the waiter carries a precise request like an API, the kitchen is the backend, the order book is the database, the manager verifies staff identity, and the building is the cloud.
Technical terms
- Frontend
- The visible interface running on the visitor's device.
- Backend
- Protected code that applies business rules and connects data or services.
- API
- An agreed way for software systems to request information or actions from each other.
- Database
- Structured, durable storage that software can create, search, update, and protect.
Module 2 · Reference8 / 18
Software parts in plain English
| Concept | Job | Restaurant analogy | Booking Marketplace example |
|---|---|---|---|
| Frontend | Serve the visible experience | Menu and dining room | Discovery, provider, and booking screens |
| API | Carry an agreed request/response | Waiter's order ticket | Request available slots or create a booking |
| Backend | Apply protected rules | Kitchen | Match providers and reserve a slot |
| Database | Store durable records | Order book | Providers, services, slots, and bookings |
| Authentication | Verify identity | Staff badge | Customer and provider sign-in |
| Cloud | Run the system online | Restaurant building and utilities | Public marketplace and protected server |
Module 2 · Diagram9 / 18
Food order: customer to restaurant
A conceptual Uber Eats-style journey showing how software components cooperate after the customer taps Place order.
1 2 API gateway
Receives the request, checks identity, and routes protected work.
3 Order service
Validates items, prices, location, fees, and restaurant status.
4 Payment service
Authorizes payment and returns success or failure.
5 Database
Creates the order and records its current status.
6 Restaurant app
Receives the order and accepts or rejects preparation.
The customer sees one action, but several services exchange requests, responses, and status changes.
Module 2 · Diagram10 / 18
Food order: restaurant to doorstep
The order becomes an event-driven workflow shared by restaurant, courier, customer, and support systems.
1 Order accepted
The backend records preparation and estimates readiness.
2 Dispatch service
Finds nearby eligible couriers and offers the delivery.
3 Courier app
A courier accepts; location and progress events begin.
4 Tracking service
Combines order, map, restaurant, and courier updates.
5 Notifications
Customer and restaurant receive useful status changes.
6 Delivery
Completion updates the database, receipt, support, and settlement records.
Frontend screens differ by role, while APIs, backend services, databases, and events keep everyone synchronized.
Module 2 · Apply it11 / 18
Apply the concept
Trace a submitted form through frontend, API, backend, database, and back to the result screen.
- 1Start with the visitor pressing Submit on the frontend.
- 2Write the API request as an envelope containing an address, action, and data.
- 3Let the backend validate identity and input before reading or writing the database.
- 4Return a response and update the frontend for success, validation failure, or server failure.
Success looks like
You can trace one click in both directions and explain why private keys and protected rules belong in the backend.
Watch for
- An API is not the backend itself; it is the agreed doorway used to request backend work.
- A database stores information, while a backend decides what may be done with it.
Guided project12 / 18
Build brief
AI Service Booking Marketplace · Stage 1
Translate a familiar service-booking process into a software-and-AI blueprint, choose a marketplace theme, and confirm the starter application works.
User story
As a customer, I immediately understand how the marketplace will help me find and book the right service.
Discuss the product before building
Discuss before codingGive the AI the starter project and references, clarify the product, and agree on scope.
I want to build an AI Service Booking Marketplace over this five-day onsite bootcamp. I am providing: 1. The instructor starter project in this workspace. 2. Reference app URL: [PASTE URL]. 3. Design link or screenshots: [PASTE LINK OR ATTACH FILES]. Do not write code yet. Inspect the starter project and every accessible reference. Treat the references as the source of truth for the intended visual direction and business journey, but do not copy branding, proprietary text, or unavailable source code. Summarize the target users, discovery-to-booking journey, business rules, visual system, reusable starter assets, and any ambiguity. Ask me up to 10 prioritized questions about marketplace category, customer, provider, services, location, availability, payment, policies, and AI role. Then propose a small Day 1 scope, out-of-scope list, and measurable acceptance criteria. Wait for my answers and approval.
MVP prompt 2 of 313 / 18
Continue the same AI conversation
From product decision to working checkpoint
Compare and choose the stack
Discuss before codingUnderstand the architecture choices and why each technology belongs in the product.
Continue from our approved product brief. Do not write code yet. Start with the technology already present in the starter project. Compare it with no more than two realistic alternatives. Evaluate compatibility with the starter, beginner learning curve, delivery speed, cost, security, maintenance, and Azure deployment. Recommend one stack and explain why each layer is needed: frontend, backend and APIs, database and authentication, AI and RAG, workflow automation, test payments, and cloud hosting. Map the customer journey to those layers. Identify what styling, components, and business behavior should be adapted from the starter project and reference URL/design. Return a simple architecture map, core data entities, routes or screens, reusable components, and a five-day phased plan. State trade-offs and assumptions in plain English. Wait for my approval before implementation.
MVP prompt 3 of 314 / 18
Continue the same AI conversation
From product decision to working checkpoint
Build only the Day 1 shell
Discuss before codingCreate a recoverable starting point without prematurely adding later-day systems.
Use the approved product brief, stack, and architecture. Implement only the Day 1 project shell. Before editing, restate the visual rules and business rules taken from the starter project and reference URL/design, then list the files you expect to change. Preserve the starter's existing stack, dependencies, design tokens, and component patterns. Adapt the reference direction without copying its branding or protected content. Set the marketplace category, product name, target customer, and promise. Build the static shell needed to communicate the discovery-to-booking journey. Do not add live AI, RAG, database, authentication, payments, workflows, or real availability yet. Make one small reviewable change at a time. Run the repository's lint, typecheck, and build checks. Report changed files, validation results, assumptions, and how to save this working Day 1 checkpoint. Stop after the shell is verified.
Guided build · Part 115 / 18
Build it step by step
Run it manually
Role-play how a customer discovers, compares, contacts, books, and pays a service provider today.
Map the software
Assign discovery, matching, availability, booking, payment, and follow-up to the correct system parts.
Choose the marketplace
Choose one category such as wellness, tutoring, consulting, home services, or events.
Guided build · Part 216 / 18
Build it step by step
Write the promise
Complete: Tell us what you need, find the right provider, and book a suitable time.
Customize and run
Update the marketplace name, category, and promise, then confirm it opens locally.
Save checkpoint one
Record the working version before adding the interactive journey tomorrow.
Ship checkpoint17 / 18
Do not ship until
- The manual service-booking process and its software equivalent can be explained without technical vocabulary.
- Frontend, backend, API, database, authentication, and cloud are correctly placed on the product map.
- The food-ordering diagram can be traced from customer action through delivery and status updates.
- The marketplace category, customer, and product promise are specific.
- The starter app runs locally and reflects the chosen marketplace.
- No secret is stored in source code or GitHub.
Wrap and prepare18 / 18
Ship it. Show it. Prepare the next move.
Before the next day
- Prepare six realistic questions needed to match a customer with a service.
- Write three sample provider matches with different prices and availability.
- Collect a logo or two visual references for the chosen marketplace theme.