Mindvalley Stories
AI Mastery

Built a 7,460-line business planner tracking real partners and real consequences

Quick summary

A network marketing professional built a comprehensive success planner and assessment platform—7,460 lines across real business operations—using AI-assisted development. Through rigorous self-imposed security reviews, he discovered and fixed critical data exposure gaps that traditional interfaces had hidden, proving vibe coding can deliver production-grade applications when paired with disciplined testing.

Entry hosted at: https://portfolio.businessreimagined.ai/success-planner

ACHIEVEMENTS

My Brand Partners were tracking daily activity across notebooks, spreadsheets and memory, with no way to connect any of it to the compensation plan that decides whether the work counts. The Success Planner holds both, so the question "did what I did today move me toward my goal" has an answer on the screen. It is live at version 6.11.3, 7,460 lines in a single file, with real partners and real consequences. I am entering two applications rather than one, because a second one built the same way is the difference between a result and a method.

Goals and compensation

- The full fifteen-rank Purium ladder with real volume minimums, from Consultant at 1,000 to Royal Crown II at 1,000,000

- Pace per day, end-of-month projection, and a recast of what is needed per day for the days left

- Lifestyle Bonus qualification, tracked through promo points, shown only for the ranks it applies to

- A promo catalog with per-promo caps, deadline countdowns and back-logging

- A volume inspector, so a partner can find and clear a wrong entry without calling me

Contacts and follow-up

- Six relationship types, with search that spans every interaction note, not just names

- A pipeline board with drag-and-drop across five stages

- Contact temperature: hot inside a week, warm inside three, cold beyond

- A live list of contacts with no follow-up scheduled

- A prompt that appears seconds after any call: book your next touch, tomorrow, in three days, or next week

Behavior design, meant to support the work rather than decorate it

- Three rows of icons fill in as the day is logged: a pencil for each reach out, a phone for each conversation, a star for each connect call

- Tapping an empty icon opens a real contact and a real note rather than adding an anonymous point; tapping a filled one takes it back

- Nine experience levels, seventeen badges against real thresholds, and confetti that is suppressed entirely for anyone who prefers reduced motion

- A streak that breaks does not reset to zero, it halves, because discouragement is not a feature

- A weekly challenge derived from the partner's own rank goal

- Eight coaching rules that surface the two most relevant, including one that notices when a partner has called the same person three times while four others went untouched

Team and platform

- The leader hierarchy is in the data model, so reporting rolls up through the structure the business actually has

- A leader sees their own group's counts and never anyone's private contacts, and that boundary is enforced in the database rather than in the interface

- Announcements reach the whole team, editable in place so a typo does not resurface as news

- Installs like an app, updates like a site, and logs its own errors to a dashboard I can read

The second application, built the same way

- A 45-question Hartman Color Code assessment platform, the tool behind my certified facilitation practice. A sample report is on the project page; the platform itself holds real people's results, so it is not open for browsing

- Any word in a question can be tapped for its definition, so nobody answers on a guess at what a word means

- Sessions resume where they were left, and completed assessments generate a full report to print or save

- An admin side handling organizations, coaches, access-code distribution, results and export

- It went through the same pre-launch review the planner did, and what that review found is fixed

- One application that survives review could be luck. The discipline is the part I would want judged

TOOLS

- Claude Code in VS Code for the build

- Supabase for the database and row-level security

- Netlify for deployment

- A single-file progressive web app with a service worker set network-first for HTML, so a partner who installed it in March is not running March's version in July

- Every ship runs a gate: runtime test, type check, write-safety scan, secret scan, and an independent agent verdict in a fresh session

METHODOLOGY

The interesting question about vibe coding is not whether you can get an application out of it. It is whether you can get one a working team will run their day inside, holding the contacts, the follow-ups and the daily activity a business actually turns on.

How a feature actually gets built

It started with a PRD, then:

1. Requirements arrive as complaints. A partner writes to me about what broke and I paste their words in whole rather than translating them into a specification first.

2. I am user number one, so a fair share of the bugs are mine. I report them against a version number, because assuming I am on the current build wastes an afternoon.

3. I describe what it needs to be, direct Claude to build it, use it myself, and send it back when it is wrong. That last step is most of the work.

4. Every feature exists because a partner asked the same question twice.

The security review, which I started myself

1. Before sending a batch of migrations to the database, I stopped and asked whether there were any security gaps or exposed keys before deploying.

2. That question found something I had done myself. Six months earlier, unblocking a recursion error, I had set every table's policy to allow everything.

3. Any signed-in partner could read and edit any other partner's contacts, notes and goals, and could make themselves an administrator by changing one field. Nothing looked wrong, because the interface only ever showed you your own data. The exposure sat at the API, one layer below anything a screen could reveal.

4. Eleven tables went to owner-only in a single migration, with a trigger blocking role self-promotion. The script ends by asking the database for any policy still set to allow everything, and requires zero rows back.

5. Two weeks later I asked again, this time whether it was really ready and what it would take to protect the data well enough to monetize. That pass found leaders could still read members' private notes through the raw API, because the privacy promise lived in the interface rather than in the database.

6. That fix was deliberately split across two migrations so there was never a window where the app was broken: add the count-only views and repoint the app first, remove the broad access second.

7. Twenty-one scripts that could turn protection back off were quarantined rather than deleted.

Two things I did not expect to have to do

- Make the checker better instead of fixing the bug. When a defect still reached real users, I did not ask for a patch. I asked why the checking agent had not caught it. The answer became a permanent runtime test inside a gate that now runs before every ship, in a fresh session rather than the one that wrote the code.

- Defend the app against its own users. Undoing an entry pays back negative points, the perfect-day bonus is guarded so two quick logs cannot claim it twice, and the weekly challenge floor is enforced in the code rather than the input field, because a determined person can edit what the browser shows them. Rewarding activity means someone can farm the reward, and a number my partners could inflate is a number none of us could trust.

It is not the only application I have shipped this way. The Color Code platform I built for my facilitation practice runs the same pattern and got the same scrutiny. Testing it myself, I found its access-code restriction firing after account creation instead of before it, and found its error message naming the exact email domain a code required, which told anyone holding a code something a rejection had no business telling them. Both are fixed, and it now keeps an audit trail of administrative actions including who exported data.

LEARNINGS

- Not writing the code myself is exactly why that had to be caught by review rather than instinct. Building this way makes you fast, and it moves the whole burden onto what you check.

- Keep pushing when the answer is that nothing is wrong. Twice I was told a gap in the rank progress was not a bug, only an empty value displaying confusingly. I went back a third time with how the compensation plan actually calculates group volume, and the answer changed to having had the model wrong.

- Deciding what belongs in an application and what does not is the work that took thirteen years to learn. Anyone can generate a feature. Knowing which ones will still be used a month later is different.

RELEVANT URLS

The write-up: https://portfolio.businessreimagined.ai/success-planner

Live application: https://planner.nlgj.vip

Judge test account: tracief808@me.com , Test PW: welcome123 , deliberately not published on the page

Note: still in beta. If an access message appears, a refresh clears it.


Tracie Fujikane

Written 11 August 2026 Submitted by the storyteller

Every story is written by a Mindvalley student or by someone our teachers have worked with. How we collect and check stories

Related Stories