Choorai
14 days total · 30-120 min/day

2-Week Build-to-Deploy Mission

This beta track is designed so beginners move by "completable missions" instead of browsing topic lists. Single goal: ship one working service with a public deploy URL within 14 days.

How to use this page

  • Do one mission per day.
  • Each mission ends only when output and done criteria are met.
  • If blocked, jump to the linked Fix/Recipe pages immediately.

Daily mission starter prompt

Copy and use

"You are a senior engineer mentoring a beginner. My current goal is to complete one mission from Choorai's 2-week roadmap. Reply only in this structure: 1) Top 3 tasks for today 2) Copy-paste commands/code 3) Done criteria checklist 4) Max 3-step debugging order if it fails Do not give abstract theory. Give only executable steps."

Use the same starter prompt every day to keep output quality consistent.

2-week mission progress

0/14 done

Week 1: Reach first deploy

Day 1

Choose one idea and done criteria

(30 min)

Goal: Narrow the service to one sentence and define how you will know today is done.

Execution Steps

  1. Write one target user and one problem.
  2. Pick only one feature for the first version.
  3. Add five done criteria and one validation method to README.

Done Criteria

  • Feature scope is limited to one core action
  • 5 DoD lines are written
  • Validation command or URL rule is defined

Output: Write one feature scope, 5-line DoD, and one validation method in README

Validation: Open README and confirm that scope, done criteria, and validation are all visible.

AI Starter Prompt

I want to narrow my 14-day web service idea to one small version. Please define one target user, one core feature, five done criteria, and one validation method.
Day 2

Define screens and data shape

(45 min)

Goal: Decide two screens and three to five data fields before writing UI code.

Execution Steps

  1. Pick two screens from list, form, and detail.
  2. Write the visible text and buttons for each screen.
  3. Create three sample records in JSON shape.

Done Criteria

  • Two screen names are defined
  • 3-5 fields and sample data exist
  • Expected button behavior is written

Output: Two screen descriptions and three sample records

Validation: Check README or notes for screen names, field names, and sample data.

AI Starter Prompt

Please define two screens and three to five data fields for the first version of my service. Include screen names, field names, and sample data in a table.
Day 3

Build the first frontend screen

(90 min)

Goal: Render one list or form screen locally using sample data.

Execution Steps

  1. Create or open the frontend project.
  2. Add sample data in code and render one list or form screen.
  3. Run the local server and verify the page in the browser.

Done Criteria

  • `npm run dev` works
  • Sample data is visible on screen
  • One screenshot of the key UI is saved

Output: One visible frontend screen running locally

Validation: Run `npm run dev` and confirm the local URL shows sample data.

AI Starter Prompt

I want to build one list screen with sample data in a Vite frontend. Please give me component structure, run commands, and done criteria for a beginner.
Day 4

Connect form input to the list

(90 min)

Goal: Make the smallest interaction where user input changes the visible list.

Execution Steps

  1. Keep only one to three fields in the form.
  2. Add submitted values to the list.
  3. Handle one failure case such as empty input.

Done Criteria

  • The form is visible
  • A submitted item appears in the list
  • Empty input is blocked or explained

Output: A screen where input changes the list

Validation: Type a value in the browser and confirm it appears in the list immediately.

AI Starter Prompt

Please help me add a form to my frontend so submitting it shows a new item in the list. Focus on simple state management, code, and done criteria.
Day 5

Finish backend API skeleton

(90 min)

Goal: Create `/health` plus list/create APIs that the frontend can call.

Execution Steps

  1. Create the `/health` route first.
  2. Add list and create endpoints for the core resource.
  3. Use one simple error response shape.

Done Criteria

  • `GET /health` returns 200
  • At least list/create endpoints work
  • Error response format is consistent

Output: `/health` + one CRUD resource set

Validation: Run `curl http://localhost:8000/health` or the matching local port and confirm a successful response.

AI Starter Prompt

Please help me create a minimal backend API for my service. Include /health, list, create endpoints, and curl validation commands for FastAPI or Hono.
Day 6

Connect frontend and API

(120 min)

Goal: Replace sample data with the backend API response.

Execution Steps

  1. Move the API URL to an environment variable or constant.
  2. Change the list screen to load the API response.
  3. Add basic loading and failure messages.

Done Criteria

  • Real data is shown in browser
  • An API failure message is visible when it fails
  • CORS is solved or narrowed down with Fix docs

Output: Local app showing real API data in the browser

Validation: Open browser DevTools Network tab and confirm the API request succeeds.

AI Starter Prompt

I want to connect my frontend screen to my backend API. Please explain where to put fetch, how to check CORS, how to show success/failure UI, and how to validate it.
Day 7

Create the first deploy URL

(120 min)

Goal: Deploy the frontend and get a public URL someone else can open.

Execution Steps

  1. Run the frontend build locally first.
  2. Connect the project to a deploy platform.
  3. Open the deploy URL and verify the key screen.

Done Criteria

  • Local build succeeds
  • Deploy URL is reachable
  • Deploy URL is written in README

Output: One reachable frontend deploy URL

Validation: Open the deploy URL in a fresh browser tab and check the first screen plus API status.

AI Starter Prompt

I am deploying my frontend app for the first time. Please give me build commands, env var checks, and post-deploy validation steps for Cloudflare Pages or Vercel.

Week 2: Stabilize and demo

Day 8

Decide the auth scope

(45 min)

Goal: Choose only the auth behavior required for the first version.

Execution Steps

  1. Pick only one screen that must require login.
  2. Choose cookie or token storage.
  3. Define where users go after login success or failure.

Done Criteria

  • One protected screen is chosen
  • Cookie or token strategy is selected
  • Success/failure auth flow is written

Output: Auth method and one protected screen

Validation: Check README for auth method, protected screen, and success/failure flow.

AI Starter Prompt

Please help me define the minimum auth scope for my service. Compare no-login, cookie, and token options, then pick one protected screen for the first version.
Day 9

Build the smallest login flow

(120 min)

Goal: Separate login success/failure and apply it to one protected screen.

Execution Steps

  1. Create a login API or temporary login function.
  2. Show different UI for success and failure.
  3. Protect one screen that requires login.

Done Criteria

  • Success/failure auth paths are separated
  • Cookie or token storage strategy is applied
  • One protected route is applied

Output: Implement login/logout or cookie-based session once

Validation: Confirm the protected screen is blocked before login and accessible after login.

AI Starter Prompt

I want to add the smallest login flow to my app. Please guide success/failure responses, cookie or token storage, and one protected route step by step.
Day 10

Run one quality gate

(60 min)

Goal: Add minimum testing and self-review so the core user flow does not regress silently.

Execution Steps

  1. Pick one core success scenario.
  2. Test one success case and one failure case.
  3. Write a PR self-review checklist.

Done Criteria

  • Success/failure test case exists
  • At least one regression risk is recorded
  • PR checklist is passed

Output: At least one core test scenario and one PR self-review

Validation: Confirm the test command or manual validation note is recorded in README or PR notes.

AI Starter Prompt

Please create a minimum test and PR self-review checklist for my app’s core flow. Include one success case, one failure case, and one regression risk.
Day 11

Separate environment variables

(90 min)

Goal: Move values that differ by environment out of code.

Execution Steps

  1. Separate API URLs, public keys, and secret keys.
  2. Create `.env.example` without real secrets.
  3. Register matching env vars in the deploy platform.

Done Criteria

  • Environment-specific values are listed
  • `.env.example` is written
  • Real secrets are not committed

Output: Environment variable list and `.env.example`

Validation: Check `git status` and `.gitignore` to confirm real `.env` files are not tracked.

AI Starter Prompt

Please help me organize my app environment variables. List what differs between local, staging, and production, show a .env.example, and flag values that must not be committed.
Day 12

Define incident check and rollback

(90 min)

Goal: Write the first response checklist before production problems happen.

Execution Steps

  1. Write a 3-step order for checking incidents.
  2. Find how to restore a previous deploy in the platform.
  3. Choose one cost guardrail or shutoff action.

Done Criteria

  • 3-step incident check order is written
  • At least one rollback method is documented
  • One cost guardrail is defined

Output: 3-step incident check order and one rollback method

Validation: Confirm the doc is enough to find the rollback button or command without extra searching.

AI Starter Prompt

Please create an incident check and rollback checklist for my deployed service. Cover logs, env vars, deploy history, previous version restore, and cost guardrails.
Day 13

Package the demo page

(60 min)

Goal: Make the service shareable with URLs, usage steps, and known issues on one page.

Execution Steps

  1. Put web URL and API URL at the top.
  2. Write the usage scenario in three lines.
  3. List known issues and validation method.

Done Criteria

  • Two URLs (web/API) are shareable
  • Usage scenario is written in 3 lines
  • Known issues and validation method are written

Output: One-page summary with web URL, API URL, usage, known issues

Validation: Open the demo note URLs in another browser or private window.

AI Starter Prompt

Please help me write a one-page demo note for my service. Include web URL, API URL, usage scenario, known issues, and validation method.
Day 14

Retrospective and next three improvements

(60 min)

Goal: Close the 2-week cycle by choosing only three next improvements.

Execution Steps

  1. Write three lines each for what worked and what blocked you.
  2. Choose only three next improvements.
  3. Pick one core feature to keep in the next version.

Done Criteria

  • Wins and blockers are written
  • Three next improvements are selected
  • Deploy URL and retrospective are stored together

Output: One retrospective page and three next improvements

Validation: Confirm README or the retrospective note includes the deploy URL and three next improvements.

AI Starter Prompt

Please help me write a retrospective for my 2-week build. Summarize what worked, what blocked me, three next improvements, and one feature I should keep.

How this differs from Map

  • Order is fixed by deliverables, not by topic exploration.
  • Each step has explicit stop criteria, so momentum is retained.
  • Recovery links are embedded for fast unblock.

Next step after Day 14

Once you have a deploy URL and retrospective note, the next step is adding AI features to the service. Start with a harness, add a small RAG feature and Skill, then compare Local LLM options last.

Last updated: June 22, 2026 · Version: v0.0.1

Send Feedback

Opens a new issue page with your message.

Open GitHub Issue