跪拜 Guibai
← Back to the summary

A Solo Developer Built a Full-Stack AI Goal Coach Using Vibe Coding

Foreword

This is not a technical tutorial, but a complete record of a product creator—from a vague idea in mind to launching a real product that includes a user client, API, admin panel, and AI integration, all built collaboratively with Codex.

I. Prologue: The Birth of an Idea

I've always had a frustration.

The market lacks a tool that lets me "truly execute" my goals.

Notion is too free-form; you need to build your own templates, and after building them, you lose the motivation to execute. To-do lists are too simple; they only record "what to do today," but can't solve "why do this today" or "what to do tomorrow." OKRs are too enterprise-level, suitable for team management but not for personal daily life.

What I wanted was actually very simple:

A tool where I tell it my goal, it breaks it down into daily tasks, then reminds me every day, gives me feedback, and finally reviews with me.

This idea lingered in my mind for a long time. But every time I thought about implementing it—frontend pages to write, backend APIs to build, database tables to design, plus AI integration, an admin panel, and deployment—I felt I couldn't handle it alone.

Until I encountered vibe coding.

To be precise, I encountered tools that support vibe coding.

II. Discovering Needs: Pain Points Aren't Imagined, They're Uncovered Through Conversation

The needs for this product didn't come from brainstorming in front of a computer. They came from two places: my own failed experiences and conversations with friends.

Starting with Myself

I've had many experiences of "making a grand plan and giving up after three days."

Wanted to get fit, got a gym membership, went twice, stopped. Wanted to learn English, downloaded an app, checked in for three days, forgot about it. Wanted to save money, checked at the end of the month, still overspent.

The reasons for each failure were actually similar:

Talking with Friends

I found this wasn't just my problem.

When chatting about this topic over dinner with friends, almost everyone had similar experiences. One friend said:

"Every time I make a plan, I get super excited, feeling like my life is about to change. Then after three days of execution, it's gone. Next time, I make an even more exciting plan."

Another friend said:

"I know what I should do, but I just don't know where to start with the first step."

These conversations made me realize: The pain point isn't 'setting goals,' but 'the first mile from goal to execution.'

Five Core Problems

I organized these observations into five problems, which later directly determined the product's functional design:

# Problem Product Response
1 Unsure if the goal is realistic AI first assesses feasibility, gives a score and suggestions
2 Don't know what to do on the first day AI breaks the goal down into specific daily tasks
3 Don't know how to break down a long cycle Plan is divided into phases (Adaptation → Execution → Intensification → Wrap-up)
4 Check-in is just a record, no feedback AI coach gives targeted daily feedback
5 No review after failure, repeat mistakes next time Automatically generates a final review after plan completion

The product positioning emerged: a tool where AI helps you go from a 'vague goal' to 'what to do each day.'

image.png

image.png

III. Inspiration: From Fragments to Product

With the pain points identified, the next step was turning them into an interactive product. This process wasn't linear; it was more like a puzzle—piecing together fragments of inspiration one by one.

Initial Inspiration Fragments

Fragment 1: Let users 'speak' their goal, not 'fill in' a goal.

The first step in most goal management tools is filling out a form: goal name, deadline, priority, category... You feel tired before even starting to execute.

The experience I wanted was: the user just says one sentence—"I want to lose 10 pounds in three months" or "I want to score 6.5 on the IELTS in half a year"—and the rest is handled by AI.

Fragment 2: AI is a 'coach,' not a 'tool'

Most tools on the market position AI as a Q&A assistant: you ask, it answers. But in this scenario, AI should be a proactive role—it helps you evaluate goals, generate plans, give you daily feedback, and finally review with you.

Fragment 3: A closed loop is more important than features

This product doesn't need many features. It just needs to do one thing well: let users go from "I have a goal" to "I finished what I needed to do today," and then back to "I'm one step closer to my goal."

Core Experience Loop

Ultimately, the product's core experience was designed as a short closed loop:

State goal → AI evaluates feasibility → Generate structured plan → Daily check-in → AI coach feedback → Completion review

The most critical link in this loop isn't "generation," but "execution." So the database and backend aren't just for saving a piece of AI text, but for breaking down AI results into actionable structured data—plans, phases, days, tasks, check-ins, feedback, reviews.

image.png

The Origin of the Product Name "Bound to Succeed"

The name came from a very direct thought: Whether it's the product or the user, both need a confident voice.

Users need a tool that makes them believe "this time it will work." I needed it too—a project built from 0 to 1 with AI, unsure if it would succeed. So this name is both for the user and for myself.

IV. Tech Stack Selection: Why Codex

Before settling on Codex, I tried two other AI coding tools.

Tools Tried

Claude Code

Claude's conversational ability is strong, and its code generation quality is good. But at the time, its support for Chinese projects was unstable—table comments, API documentation, and prompts in Chinese were prone to encoding issues. Moreover, when continuously iterating on a project with an existing structure, the context wasn't maintained coherently enough—often encountering situations where "a design agreed upon earlier was forgotten when switching to a new conversation."

Trae Domestic Version

Trae is very friendly to the domestic ecosystem, with good Chinese support and understanding of commonly used domestic tech stacks. However, its experience leaned more towards "generating from scratch," and the workflow wasn't smooth enough for "making continuous modifications and iterations on an existing project."

Why Codex Ultimately Won

The three points that impressed me most about Codex:

1. Project-Level Context

It's not a single Q&A session. It works within the entire project repository—reads your code structure, understands your naming conventions, knows how your database tables are related. This means you can say "add an API to the user service that queries what day of check-in it is today," and it knows where to add it, how to name it, and how to interface with existing code.

2. Full-Stack Coverage

Going from an idea to a runnable full-stack project involves:

Codex, as a single tool, covered all these aspects. The switching cost was almost zero—no need to frequently switch contexts between frontend frameworks, backend frameworks, database tools, and AI SDKs.

3. Iterative Collaboration

This is what impressed me most. Codex's way of working isn't "you ask a question, it gives an answer," but rather:

You first state an idea, it generates a version; you run it to see what's wrong; you supplement experience requirements; it continues to modify APIs, pages, data; finally, it solidifies into documentation.

This process feels very much like having an engineering partner sitting beside you: I'm responsible for judging direction, proposing product feelings and acceptance criteria; it's responsible for breaking down ideas into code, files, APIs, and data structures.

image.png

Honest Boundaries

Of course, Codex isn't omnipotent. My judgment:

Suitable Scenarios:

Unsuitable Scenarios:

image.png

V. Solution Design: AI Generates, Humans Constrain

This is the most important part of the entire product design.

Overall Architecture

┌──────────────────┐       ┌──────────────────┐
│  User Client     │       │  Admin Panel     │
│  (uni-app/H5)    │       │  (Vue 3 + Element)│
└────────┬─────────┘       └────────┬──────────┘
         │                          │
         ▼                          ▼
┌──────────────────┐       ┌──────────────────┐
│  User API        │       │  Admin API       │
│  (Koa + JWT)     │       │  (Koa + JWT)     │
└────────┬─────────┘       └────────┬──────────┘
         │                          │
         └──────────┬──────────────┘
                    ▼
           ┌──────────────────┐
           │  MySQL           │
           │  (d_c_DB)        │
           └──────────────────┘

Four projects, sharing the same database.

Why split into four projects?

Separation of concerns. If the user API goes down, it doesn't affect the admin panel; high-traffic queries on the admin panel don't affect the user service. Plus, they can be deployed independently—after going live, the user API and admin API were actually deployed on different ports.

Why share a database?

Initially, I considered using different databases for the user and admin sides, syncing via APIs. I decisively abandoned that idea—for a one-person project, adding a data synchronization layer only introduces more bugs. A shared database + reasonable front-end and back-end validation is simple and reliable enough.

Core Business Flow

Login
  → Create Goal (fill form: goal name, cycle, expected outcome, daily available time...)
  → POST /api/v1/goals/evaluate → AI feasibility assessment (or local fallback)
  → Score >= 60 → POST /api/v1/plans/generate → Generate plan
  → Homepage shows active plan, today's tasks, AI coach feedback
  → Daily check-in → Tick off tasks → Update progress
  → Plan completed → AI generates final review
  → History page view all plan statuses

AI Boundary Design: The Core Design Decision

Initially, I easily fell into a misconception: since we're using AI, should we let it freely generate everything?

Later I realized—a truly reliable AI in a product isn't one that 'says whatever,' but one that 'outputs structured results after being constrained.'

So the backend was designed with several layers of protection:

1. AI output must be JSON, not Markdown text

Mandatory use of DeepSeek's response_format: { type: 'json_object' }. If the AI doesn't return valid JSON, it directly goes to fallback.

2. All output must go through normalization and validation

AI might return missing fields, incorrect formats, or non-consecutive phase days. So the backend has a normalize layer specifically for cleaning:

3. Local fallback when no Key or call fails

When AI_API_KEY is empty, or the AI call times out/returns an exception, the system automatically uses a local algorithm to generate evaluations and plans. Although the quality isn't as good as AI, the product won't become unusable because of it.

4. Log every call

Every AI call (success or failure) is written to the ai_model_logs table, containing the complete request, response, duration, and status. This provides foundational data for future troubleshooting and rate limiting.

5. Independent daily call limits per scenario

Configured via the system_configs table, each scenario has a daily call limit. This prevents a single user from exhausting the quota by spamming an API.

The core philosophy in one sentence: AI is the 'generation engine,' product boundaries are controlled by code.

image.png

image.png

d7a65ab139759556d52b8e5ed742b60b.jpg

VI. Database Design: Modeling Around the 'Execution Loop'

The database design principle was simple: Everything is to enable users to execute their goals.

Core Relationship Chain

users
  → goal_evaluations (Goal Evaluation)
    → plans (Plan Master Table)
      → plan_phases (Phases)
        → plan_days (Days)
          → tasks (Tasks)
            → checkins (Check-ins)
              → coach_feedbacks (Coach Feedback)
                → plan_final_evaluations (Final Review)

[Screenshot Placeholder: Screenshot of the core table list in the MySQL database — showing all table names under the ding_cheng library]

[Screenshot Placeholder: Screenshot of the plans table field structure — showing key fields and types]

[Screenshot Placeholder: Screenshot of several sample data rows in the tasks table — showing the data structure of AI-generated tasks]

Why Break Down into 4 Layers (Plan - Phase - Day - Task)

This was a decision made very early on: What AI generates is not a piece of text, but a tree structure.

The benefits of this design are:

Design Background of the Three Day-Counting Modes

Different users have different needs for "check-in frequency." So three modes were designed:

Mode Description Applicable Scenarios
calendar Natural days, check in every day Short-term sprints, habit formation
workday Workday check-ins, skip weekends and statutory holidays Study plans, work projects
rest_day Rest day check-ins (only 2 days every 7 days) Fitness, sports (need recovery days)

The workday mode brings an additional problem: China's compensatory leave system. Weekends might be makeup workdays, and workdays might be holidays. So a holiday_calendars table is needed, configured by the admin in the backend, also supporting annual synchronization.

Why Check-in Status Has Three Levels

It's not a simple true/false, but a three-level status:

This allows for a more realistic view of execution quality during reviews—"Completed 2 out of 3 tasks today" carries more information than "Check-in failed today."

Design Intent of the AI Log Table

ai_model_logs is one of the most valuable tables after going live. Each record contains:

Without this table, troubleshooting AI issues would rely on guesswork. With it, the backend can investigate problems by scenario, user, and time period, and also do usage statistics and cost estimation.

Operational Support Tables

Besides the core business tables, there's a set of operational tables designed from the start:

Table Purpose
system_configs System configuration (AI call limits, site name, feature toggles)
announcements Announcements (configurable display time, whether to show only once)
user_feedbacks User feedback (and processing status flow)
avatars + association tables System avatar management (supports categorization by tags, sorting)
preference_assessment_* User preference assessment questions and results

These tables transform the project from "runnable" to "operable."

image.png

image.png

VI.5: An Interlude—Why the Admin Panel Was Built Early

Not a full chapter, but worth mentioning separately.

Many personal projects only build the user client first, leaving the admin panel for "later." This time, I built the admin panel from the very beginning.

The reason is simple: AI products need observation.

I needed to know:

Without an admin panel, these questions could only be guessed at. With one—even just a simple list page + log viewer—problems become visible.

So the admin panel isn't the icing on the cake; it's the debugging entry point and operational entry point.

image.png

image.png

image.png

image.png

VII. The Real Workflow of Vibe Coding

Many people are curious about what it feels like to "build a product with AI." I'll illustrate with a real case.

A Typical Development Cycle

Take the "check-in feature" as an example to see how it went from idea to code:

Step 1: Propose the Requirement (Colloquial Description)

"I want users, after entering the check-in page, to see today's task list, tick off completed ones, click submit, and then have the AI give a piece of feedback based on completion status."

Step 2: Codex Understands the Requirement + Reads Existing Code

It doesn't start writing immediately. It first reads the existing project structure—what fields the plans table has, how the tasks table is related, whether there are any existing check-in related APIs, and what component library the frontend pages use.

Step 3: Generate a Plan

It will give a plan, including:

Step 4: I Review, Adjust Direction

I check if the plan is reasonable. For example, the trigger timing for AI feedback—should AI be called on every check-in, or only under certain conditions? Is the call frequency too high? Should throttling be added?

Step 5: Codex Implements the Code

Involves multiple files:

Step 6: Start Service for Verification

Start the backend and frontend, actually walk through the process. Find issues—like a field's return format being wrong, or the page displaying abnormally on mobile—and continue iterating.

image.png

Role Shift

In this process, my role underwent an interesting shift.

In the traditional development model, I was the "executor"—every API, every page, every field had to be written by myself. The rhythm was: think clearly → write code → test → discover what's missing → go back and change.

In the vibe coding model, I'm more like a "product manager + verifier"—I'm responsible for clearly stating what I want, judging if what's produced is correct, and deciding which direction to go next. Codex is responsible for turning ideas into code.

This doesn't mean I don't need to understand technology. Quite the opposite—to judge whether AI's plan is good, whether the code is stable, and whether the data structure is reasonable requires stronger technical judgment.

85740cdec4a4aeae5e09771d06fbb8f7.jpg

VIII. A Record of Pitfalls

I stepped into quite a few pitfalls making this project. I'll pick a few of the most memorable ones to discuss.

Pitfall 1: Database Couldn't Run on ECS

During the development phase, I used a local MySQL, and everything was normal. After deploying to Alibaba Cloud ECS, a problem arose—database queries were very slow, a simple list page took several seconds to load.

Initially, I thought it was a code issue, so I added various indexes, optimized SQL, and added caching, with limited effect. Later, I discovered the ECS disk IOPS was insufficient—MySQL running on a cloud server, especially burstable instances (t5/t6), would lag as soon as database operations increased.

Solution: Migrate the database from the self-built MySQL on ECS to Alibaba Cloud RDS. After migration, query latency dropped from seconds to milliseconds, with immediate effect.

Lesson: For database-intensive applications, don't cram the database and application onto the same low-spec ECS. RDS costs a bit more, but the troubleshooting time saved far exceeds the cost.

Pitfall 2: Static Image Bundling Caused Bundle Size Explosion

The user client H5 used some asset images—navigation icons, AI coach avatar, goal category images, empty state placeholders. During development, I thought "local referencing is convenient" and put them all in the static/ directory for direct bundling.

As a result, the first build produced an absurdly large JS bundle, with the first screen taking seven or eight seconds to load. Inspection revealed all images had been base64-encoded and packed into the JS.

Solution: Upload all static images to Alibaba Cloud OSS and reference them via URL on the frontend. Also managed them by type (avatars, icons, background images...), allowing the backend to replace and add new ones anytime.

Incidental Gain: OSS also incidentally solved the user avatar problem—user-uploaded avatars are also stored on OSS, and the backend can manage all assets.

image.png

Pitfall 3: Unstable AI Output

This was an expected pitfall, but when actually encountered, it was more frequent than imagined.

Typical problems:

Solution: Added a normalize layer on the backend specifically for cleaning and validation. This layer doesn't trust the AI's output—it checks if fields exist, if formats are correct, if data is consecutive, and if quantities are within a reasonable range. If it fails, it goes to fallback or retries.

[Screenshot Placeholder: Screenshot of illegal JSON log returned by AI — showing a real case of non-standard AI output]

[Screenshot Placeholder: Screenshot of normalize layer code — showing the core logic for cleaning and validation]

Pitfall 4: Frontend-Backend API Alignment

When one person does a frontend-backend separation project, the most common problem is "the API was agreed upon, but it doesn't match during implementation."

For example, date formats—backend returns 2026-06-19, frontend expects 2026/06/19. Or status enums—backend uses active/completed/abandoned, frontend code writes ACTIVE/DONE/ABANDONED.

There's no communication cost between two people, but when switching between frontend and backend contexts, you forget things yourself.

Solution: Unified API documentation (docs/api.md in the project), synchronously updated every time an API is changed. Later, I developed a habit—after changing an API, run through the frontend pages first to ensure all fields render normally.

Pitfall 5: Documentation Lag

The project's README and actual code were often out of sync. Early on, there were several instances of "the README had the old API path, but the code had already switched to the new path."

Lesson: Documentation needs to be verified just like code. Later, I set a rule—if AI changes code involving API or table structure changes, the corresponding documentation must be updated synchronously. This rule was written into the checklist for every change.

IX. A Re-understanding of Vibe Coding

After completing this project, I gained a deeper understanding of vibe coding.

Vibe Coding Isn't "AI Replacing Humans"

There are many posts online discussing vibe coding, and a common anxiety is "AI will replace programmers."

My feeling is exactly the opposite.

In this project, AI took on the work of the execution layer—writing code, creating tables, modifying files, supplementing documentation. But all the work of the decision layer—defining product boundaries, checking field semantics, smoothing page interactions, controlling AI output—was done by humans.

So the division of labor is actually:

Human Responsible For AI Responsible For
Product direction judgment Code generation
Feature boundary definition Data structure implementation
Experience verification File modification
Decision-making and trade-offs Documentation writing
Quality assurance Testing assistance

AI is not a replacer; it's a high-intensity collaborator.

What Vibe Coding Changed

It didn't change "how code is written," but "the distance between thinking and doing."

Before, an idea going from mind to launch involved setting up frameworks, writing APIs, making pages, tuning databases, deploying online—everything took time, and context switching itself was energy-consuming.

Now this process is compressed. You can quickly produce a version, run it to see what's wrong, and then continue iterating. The rhythm shifted from 'think clearly first, then do' to 'do it first, see what's wrong, then keep pushing forward.'

Who It Suits, Who It Doesn't

Suits people like this:

Doesn't suit people like this:

67a11bbe58c598e792b4acfaa70376a7.jpg

29af3e117a0c329aac6779d60d265de9.png

54e245b03e79f90de579979d2282a00d.png

492d2172a00f7c71b80232797652d678.png

X. Conclusion

"Bound to Succeed" is my first complete attempt at vibe coding a product.

It's not a demo. It has a user client (uni-app/H5), business APIs (Koa + MySQL), an admin panel (Vue 3 + Element Plus), AI integration (DeepSeek), complete test cases (XMind), and deployment configurations.

Going from an idea to all of this being implemented, if done alone using traditional methods, might have taken me two months, and it would have been easy to give up midway due to getting stuck on some part.

Vibe coding paved this path.

The biggest gain isn't 'how much code AI wrote for me,' but the first-time feeling that when ideas can be quickly implemented, verified, and modified, the rhythm of making a product is completely different.

Before, many ideas would stop in my mind—because thinking about setting up architecture, writing APIs, making pages, tuning databases made me hesitate. Now it's more like: make it first, see where it's wrong, then keep pushing forward.

It's not that code has become unimportant, but the resistance between idea and code has decreased.

And when the resistance decreases, one person can also get closer, faster, to what they truly want to make.

"Bound to Succeed"—this phrase is for the users, and also for myself.

Appendix A: Common Prompt Examples

Below are the prompt styles actually used in this project, for reference:

Scenario 1: Proposing a New Feature

"I want to add a feature: after users enter the 'My' page, they can see their check-in statistics—consecutive check-in days, total check-in count, total completion rate. Data is calculated from the checkins table. Help me design the API and frontend display."

Scenario 2: Modifying an Existing Feature

"Currently, the task list on the check-in page scrolls up and down, but I want completed tasks to automatically sink to the bottom, uncompleted ones to stay on top, and completed ones sorted in reverse chronological order of completion time. Only change the frontend, don't change the backend API."

Scenario 3: Fixing a Bug

"When creating a plan, if the user fills in daily_time as 0 (meaning no fixed time), the time_label field of the task in the AI-generated plan is null, causing the frontend display to crash. Help me fix this—make the frontend display 'Flexible Arrangement' when time_label is null."

Scenario 4: Adding a Database Field

"The plans table doesn't have a field to record the total number of days in the plan. Now I need to add a total_days field. Note that the migration script must be idempotent, and existing plans need to have this value backfilled."

Appendix B: Data Table Quick Reference

Table Row Count (Reference) Core Field Count Purpose
users Low 15+ User Info
goal_evaluations Low 20+ Goal AI Evaluation
plans Low 20+ Plan Master Table
plan_phases Low 10+ Plan Phases
plan_days Low 10+ Plan Days
tasks Medium 15+ Daily Tasks
checkins Medium 12+ Check-in Records
coach_feedbacks Medium 10+ AI Coach Feedback
ai_model_logs High 15+ AI Call Logs
system_configs Low 6 System Config
holiday_calendars Medium 8 Holiday Config

End.