ACE AI Startup Bootcamp · Self-Study Textbook

Planning an AI-Ready
Project

Write a complete project specification (PROJECT.md) that AI can understand

🎯

Chapter 1

Four Elements of Problem Definition

💡

Chapter 2

Idea Validation

📋

Chapter 3

Writing PROJECT.md

✅

Chapter 4

Project Plan Completion Check

Training Provider

ODA AI SW · ACE Program

Course

AI Web Development for Aspiring Founders

ACE AI Startup Bootcamp · Day 2 Introduction and Four Elements of Problem Definition

ACE AI Startup Bootcamp · Day 2 Self-Study Textbook

Planning an AI-Ready Project

📚 Today, you will not write code. Your goal is to create a complete, high-quality project specification (PROJECT.md).
With this document, Antigravity can build a working service on Day 3.

1. Why Are We Not Writing Code Today?

The story of the two founding teams.

A team: "Let's just make one!" → Ask Antigravity directly, "Make an app that matches hostile animals".
→ Results: Only the login screen appears and there is no key feature. Repeat the modification request more than 10 times.

B team: "Let's finish the first document" → Codex in the PROJECT.md 14 section
→ Results: Antigravity creates an MVP that runs up to core flow once requested.

Difference: Team B invested Day 2 today in document writing.

Day 2 Key Principle: More than a lot of features. One complete user flowDesign first.
One PROJECT.md file created by Codex is all the criteria for Day 3 to Day 5.

2. Idea vs. Problem Definition — What Is the Difference?

Starting with technology or features can lead to a product that does not solve a real user problem.
A strong plan clearly defines who the user is, their situation, what is inconvenient, and how they want it resolved.

📌 Four Elements of Problem Definition

👤

user (who)

Specifically, not "people", but narrowly defined as "a 20-year-old single-family worker".

📍

When/Where

At what point do you have a problem? Specifically, like, "Lone at home after work".

😣

Pain Point (Problem)

How are we addressing it now, and what's uncomfortable about it?

🎯

The change you want.

What do you hope will happen when this problem is solved?

ACE AI Startup Bootcamp · Day 2 Comparing and Reframing Problem Definitions

📝 Comparing a Weak Example with a Strong Example

❌ Idea-Centered (Weak Example)

It's an AI-based travel planner app.

The restaurant recommendation app.

"Petsitter matching platform"

The problem is: There's only a feature name, no who, no why.

✅ Problem-Centered (Strong Example)

"The 2030 generation traveling alone spends more than two hours planning the Eastern Line".

"A worker who wants to decide where to have dinner on his own in 10 minutes after work".

"The only family that can't find someone to trust to take care of a pet when it's too late".

The reason: User: situation: error: goal is clear

💡 How to Turn Your Idea into a Problem Definition

I write my ideas in one line.

For example: "Mount Action App".

He asks three times, "Why do you need this?"

Why? → "Because it's hard for a kid to walk" → Why? → "Because the lonely worker is late for work" → Why? → "Because the kid can't go out because he's stressed out"

You can combine these four elements into one sentence.

The result: "The problem of a single-person household worker with a cough is that he doesn't take a dog walk every day, and he feels guilty".

ACE AI Startup Bootcamp · Day 2 Designing the Core User Flow

3. Designing the Core User Flow

The core flow is the path a user follows from entering the service to completing its most important task.
Design this flow first to identify exactly which screens and features are needed.

Formula: input → process → result
It's the user. What do you enter?If you do, the system How do you handle it?That's why I'm here. What is the result?Do you show them?

📋 Core Flow Example — Pet Walking Match Service

core user flow example


Enter: The guardian wishes to walk in date, time, location, pet information

Processing: To sort the list of walking helpers according to the respective conditions

Results: The guardian selects the helper and receives a confirmation message that the reservation is complete



Core flow screen: Home → Conditions enter → helper list → detail view → booking completed

Warning: The core flow must be One of them.So here it is. If you try to design multiple flows on Day 2, the range is too large.
The must feature limits only what you need to complete this one core flow.

ACE AI Startup Bootcamp · Day 2 Core PROJECT.md Structure (1–7)

4. Understanding All 14 Sections of PROJECT.md

PROJECT.md is the blueprintfor your entire service. Learn the purpose of each of the 14 sections below and how to write it.

Section 1

## Project Overview Project line summary

I'll explain what this service is in a couple of sentences, and the first person to see it should understand.

Yes: "A dating service where a busy worker can book a trusted pet walking helper in 10 minutes".

Section 2

## Problem ## Problems to be solved

Four-factor problem phrases defined above, to express the actual user's discomfort in terms of data or situations.

For example, "73% of rural workers do less than three dog walks a week".

Section 3

## Target user Core target user

One specific person who needs this service most: up to age, circumstances, habits.

Example: "25 to 35 years old, residing in Seoul, one-person household worker working more than five days a week, pet dog ownership".

Section 4

## Current Alternatives Current alternatives and limits

How is the user now solving this problem? Why is it inadequate?

Yes: "Please, please, please notice. General petsitter app → later reliability opacity"

Section 5

## Core Value and Hypothesis

My service is better than the existing alternative.

Example: "Solving trust issues by sharing authenticated helpers + real-time walking routes. 80% of employees are willing to pay ₩30,000 per month for this".

Section 6

## Core User Flow core user flow

Enter→process→conclusion One-line flow of form. Includes screen list.

Example: "Conditions entered → helper list → details → reservation completed"

Section 7

Features and Acceptance Criteria

List of features classified as Must/Should/Could. Each feature needs a criterion "If you run like this, complete".

Example: "Must: helper list screen → 'If you click on helper in the list, go to detailed screen'"

ACE AI Startup Bootcamp · Day 2 Detailed PROJECT.md Specification (8–14)

Section 8

## Screen List screen list

The screens that make up the service. MVP is limited to three to five.

Example: "Home, condition input, helper list, helper detail, reservation completed"

Section 9

## Data Model Data structure

The type of data that is handled by the service. What information is stored and displayed.

Example: "helper: name, photo, location, price, rating / reservation: date, time, protector ID, helperID"

Section 10

## Technical Requirements

The beginner is set to "HTML/CSS/JS single file".

Example: "Data management with HTML/CSS/JavaScript, localStorage, external API misuse"

Section 11

## MVP Scope MVP range

It's a must-have in this development. It's a must-have limit of three to five.

Example: "Must: show the list of helpers, helper detail view, booking application form"

Section 12

## Out of scope ## What we're not doing this time ##

Declare the feature to be created later. Specify that AI doesn't exceed the range.

For example: "Member input/login, payment system, live chat, map API activation"

Section 13

## Risks and Open Questions Risks and Uncertainties

List honestly what is still unconfirmed, what needs to be decided.

Example: "Q: How do we actually enter the helper data?

Section 14

## Demo Scenario and demo screenplay

"I'm going to start with OOO and I'm going to show OOO".

Example: "Choose a date from Home → Display a list of three helpers → click 'Park Sanchaek' → review details → click Apply for Booking → show completion message"

ACE AI Startup Bootcamp · Day 2 Complete PROJECT.md Example

5. Complete PROJECT.md Example

Here's a complete example of PROJECT.md, based on the "Pet Walking Match" service, and you can customize it for your service.

PROJECT.md Complete example


# PROJECT.md — Pet Walking Match Service



## 1. Project Overview

# Pet Walking Match Service

A service for booking a trusted pet-walking helper in under 10 minutes.



## 2. Problem

Seventy-three percent of those who work in the field do less than three dog walks a week.

Cause: Too late after work, or a notice to ask a friend.



## 3. Target User

25 to 35 years old, residing in Seoul, 5 days per week or more, single family, small dog ownership



## 4. Current Alternatives

- The burden of the relationship.

- Conventional petsitter app: late reliability, opacity, complex UI



## 5. Core Value

Certified helper + simple reservation 3 step trust problem solving



## 6. Core User Flow

Enter: date, time, location, breed

Processing: Conditionally matched helper list display (Streetwise)

Results: Select helper → Reservations completed

screen: Home → ConditionsEntrance → helperlist → detail view → Reservations completed



##7. Features (must have only three)

1. helper list screen 3 or more card shapes display

2. helper detailed screen name, introduction, price, later

Reservations Form Form Form Date/Time After entering the Apply button



## 12. Out of Scope

Subscribe, pay, live chat, map API



## 13. Open Questions

- Helper data: Temporary dummy data used by three people

- Reserved storage: localStorage use



## 14. Demo Scenario

Home → Conditions Enter → Helper Select the "Boot"

→ Check the detail view → Apply for reservations → Complete the message

ACE AI Startup Bootcamp · Day 2 Practice: Writing the Plan and Defining Scope

6. Today's Practice — Step by Step

📝 Practice 1 — Create a One-Page Service Definition

I develop my ideas with AI into a systematic problem definition.

The Codex prompt is: Write it down as one of the definitions of the services I create. My idea: [Write my idea down here specifically] The following entry is inserted: 1. Goal user age, situation, lifestyle patterns specifically The current situation, the inconvenience, how to solve it right now. Three, the core value proposition is that my service is better than what it used to be. One-line service phrase: "A service where OOO can OOO in an OOO situation". Warning: Don't add facts at will. Leave the uncertain part as a question.

What if you don't have a good idea? Choose one of the following:
• "Local tasting service" • "Book recording & summary service"
• "Traffic routine recommendation service" • "heavy freight exchange service"

📝 Practice 2 — Structure the Core Flow, Screens, and Data

The Codex prompt is: Based on the service definition, structure the bottom three. 1. core flow a line in the form of "input → processing → result" 2. screen list 3 to 5 screens required for MVP, a list of elements to be included in each screen Data Model 3. Data types and fields to be handled in this service Conditions: Don't add anything that's not in the document, just leave it as a question. - I suggest you keep the screen to a maximum of five.

📝 Practice 3 — Write the 14 Sections of PROJECT.md

The Codex prompt is: I need you to create an PROJECT.md file in 14 sections. Reference documents: defined services and structured content Conditions: - Don't arbitrarily confirm the fact that you haven't provided. - Must feature is limited to three to five. - Includes acceptance criteria for each feature, "If you run like this, complete". - ##12. Explain that you're not going to make it out of scope this time. - Technical requirements: HTML/CSS/JS single file, use of localStorage

ACE AI Startup Bootcamp · Day 2 Practice: Scenario Validation and Development Instructions

📝 Practice 4 — Finalize the MVP Scope

The Codex prompt is: Check out the features of PROJECT.md. Let's classify each feature according to the following criteria and explain the basis: - Must: It's necessary to complete the core flow. - Should: It's good to have it, but it's not. - Could: Add feature later - Out of Scope: Except for this MVP. Must be limited to three to five. Don't edit the file yourself until I've reviewed it and confirmed it.

📝 Practice 5 — Validate User Scenarios

The Codex prompt is: Let's use PROJECT.md to create the following three user scenarios: Scenario 1: Happy Path: When all is well Two, empty-value scenario: when the user did not enter anything 3. Failure scenario: when there's no result or when there's an error. Tag format: step by step. Screen user behavior. If there's an operation that's not defined in the document, add it to Open Questions.

📝 Practice 6 — Create Development Instructions for Antigravity

On Day 3, Antigravity creates a final instruction file to read.

The Codex prompt is: I need you to create an HANDOFF_PROMPT.md file. This file is an instruction for Antigravity to read and implement a service. Content structure: [Standard document] Read PROJECT.md first and use it as an implementation standard. Implement the MVP Must feature and core flow. [Priority] Must feature from implementation, excluding Should/Could/Out of Scope [Technical stack] HTML/CSS/JS single file index.html, localStorage Requirements not in PROJECT.md Any additional prohibition [acceptance criteria] When you open the local, you'll see the core flow start screen. When you're done, you'll have a list of files you've created and how to run them.

✅ Day 2 acceptance criteria:
If you have the following files in the project folder, you're successful:
• PROJECT.md (Section 14 completed)
• HANDOFF_PROMPT.md (development instructions)
• README.md (Updated project description)

ACE AI Startup Bootcamp · Day 2 Independent Practice & Common Mistakes

7. Challenge: Two Independent Practice Projects

🏆 [Independent Project A] Plan an AI-Powered Travel Itinerary Service

Codex start prompt: Write out the PROJECT.md of the AI-based travel schedule planner service. Must feature: destination/date input form, schedule creation result screen, schedule storage Out of Scope: membership, real map API, payments, accommodation reservations

🚀 [Independent Project B] Complete PROJECT.md for Your Own Idea

Based on my initial idea, I want you to finish PROJECT.md from scratch.
Key: user problem definition → Must feature 3 to 5 → acceptance criteria → Out of Scope

8. Top Five Common Mistakes

Mistake one: Put too much in the must.
"Membership, payments, reviews, chats, maps"... → Must only need three to five for core flow!

Mistake two: just leave a feature that AI added at will.
You have to put "Don't add to the task" in the prompt, and you have to review the AI results.

Mistake 3: Set the target user to "Everybody".
The wider the target, the less suitable the product is for anyone.

Error 4: List only features without acceptance criteria.
Validation is enabled such as "Forecast feature" → "A confirmation message will appear when the user clicks on the reservation button".

Mistake 5: Emptying out of scope
AI will arbitrarily fill in empty spaces, and you have to clearly write "will not".

ACE AI Startup Bootcamp · Day 2 Checklist and Wrap-Up

9. Day 2 Completion Checklist

I've organized my service idea into four issues.
The core user flow is expressed as a line in the form of input→processing→conclusion.
I limited the screen list to three to five.
I've written all of the PROJECT.md 14 sections.
Must feature is limited to three to five.
Each Must feature has its own acceptance criteria.
There's an out of scope list.
I've sorted out the uncertainties in Open Questions.
I generated the HANDOFF_PROMPT.md development manual.
The A.I. personally checked to see if there was any additional content.

Next time prediction is Day 3: PROJECT.md to create an MVP running on PROJECT.md.
Today, we've finished PROJECT.md and HANDOFF_PROMPT.md, and we're building a web service that actually works with Antigravity!

Planning an AI-ReadyProject