A test account is waiting. It is still in beta, so if an access message appears, a refresh clears it.
My Brand Partners were tracking their daily activity across notebooks, spreadsheets and memory, so everyone was working hard and nobody could see whether any of that work was pointed at the rank they said they wanted.
The gap was not effort, it was arithmetic. Rank advancement in this business runs on volume thresholds and qualification windows that live in a compensation plan document, and a partner logging reach-outs in a notebook has no way to connect one to the other. So the two halves stayed separate: activity in one place, the mechanics that make activity count in another.
The Success Planner is one place where both live. Daily inputs and the compensation mechanics are the same system, so the question "is what I did today moving me toward my goal" has an answer on the screen rather than in someone's head.
Every feature here exists because a partner asked the same question twice, so nothing in it is a capability looking for a use.
Targets derived from the real compensation plan rather than an approximation, including the 500 GQV monthly qualification that governs the Lifestyle Bonus and Bonus Pool. A partner sees the threshold, where they are against it, and how much of the month is left.
Reach-outs, conversations and per-category promotion logging, entered in the shape the work happens rather than as a generic task list. This is the input side that the goal maths reads from.
The leader hierarchy is in the data model, so reporting rolls up through the structure the business actually has rather than a flat list. Leaders message their teams from inside it, and partners earn badges as they hit the thresholds that matter. A leader sees team activity without ever seeing a partner's private contact list, and that boundary is enforced in the database rather than in the interface, which is the subject of the next section.
A progressive web app with a service worker set network-first for HTML, so a partner who installed it in March is not still running March's version in July. Data exports to a spreadsheet, and the version number shows in the header and at sign-in so a support question can be answered in one glance.
This is the part where not writing the code myself could have cost my team everything they had put into it.
In a security sweep before deploying to real users, we found that an earlier fix had set every table's row-level security policy to allow everything. It had been done months before to stop an "access denied" error, and it worked, in the sense that the error stopped.
Any signed-in partner could read and edit every other partner's contacts, notes, goals and daily data. Any signed-in partner could also make themselves an administrator by changing one field on their own record.
Nobody would have noticed by looking, because the application only ever displayed your own data and every screen was correct the entire time. The exposure was one layer down, at the API, where the interface could not reach and therefore could not reveal. I did not ship it.
The lockdown rewrote every policy on all eleven user-data tables to owner-only, matched against the signed-in user rather than left open. Reading another partner's record stopped being a question of what the interface offered and became a question the database refused. A helper function running with defined privileges resolved the recursive policy errors that come with checking an administrator flag from inside the policy that governs administrators. A trigger blocked anyone who is not an administrator from changing a role, closing the self-promotion path directly. Promotions became readable by everyone and writable only by an administrator. A later migration added the narrow read access the team report needed, deliberately scoped so a leader can see activity totals without seeing anyone's contact list.
A fix that makes an error message go away is not the same as a fix. What a screen shows you and what the API permits are two different questions, and only one of them is visible. Not writing the code myself does not reduce what I owe the people who depend on it. It raises what I have to check.
One related finding looks alarming and is not: the Supabase key sitting in the file is the anonymous key, which we decoded to confirm the role it carries. It is public by design, and every real protection lives in the policies described above. That is why those policies being open mattered so much.
I have never written code, so Claude built this and I described what the business needed, then reviewed what came back the way I review anything my team depends on, which is how the section above happened.
| Layer | What |
|---|---|
| Build partner | Claude Code. No application code written by hand. |
| Front end | A single index.html of roughly 5,700 lines on Tailwind, with no build step to go stale. |
| Backend | Supabase: Postgres, Auth, and row-level security carrying every access rule. |
| Business logic | The Purium compensation plan, including the 500 GQV monthly qualification. |
| Offline and export | A service worker set network-first for HTML, a web app manifest, and spreadsheet export. |
| Security | Owner-only policies on 11 tables, a privileged helper for the admin check, a role-change trigger, and a documented migration series through v6.3. |
| Hosting | Netlify, by dragging a clean folder that contains only the three files that ship. |
That last line is a discipline rather than a detail. The working folder holds dozens of migration scripts and notes accumulated over months, and none of them belong on a public server. Shipping from a separate clean folder means the question of what is deployed has an answer you can see rather than one you have to remember.
It is in beta testing with my team: real partners, real data, and a real cost if it breaks.
Thank you for spending time with this.