
The AI-built product was already selling. What was missing was knowing what would break
Sistema Forja is a gamified personal development platform — tasks, habits, goals, finances and well-being in one place, with XP, leaderboard, shop and community on top. It wasn’t born in a software house: the founders built it by talking to an AI, shipped fast, and had 1,312 active users by the time Epicora came in. The audit found what vibe coding doesn’t solve on its own: all eight server endpoints accepted unauthenticated requests — including the payment ones — and any user’s habits, goals and daily sleep and mood logs were visible to everyone else. In about three weeks we closed the flaws, moved the infrastructure from ~R$2,000 to ~US$20 a month, and handed the product back running on the client’s own accounts.
- Client
- Sistema Forja — gamified personal development platform
- What we did
- Technical audit of a product built with AI (vibe coding) — security, architecture, cost and technical debt — with the fixes applied, the infrastructure migrated and the product handed back on the client’s accounts
- Platform
- React 18 + TypeScript + Vite · Supabase (PostgreSQL with RLS, Auth, Deno Edge Functions) · PWA · payment webhooks · Vercel · GitHub
The starting point
Forja did what every new product should do: it reached the market before it looked good. The founders built the platform by talking to an AI — no engineering team, no designed architecture, no repository with an owner. When Epicora came in, in February 2026, there were 1,312 active users, monthly, quarterly, half-yearly and lifetime plans being sold, and the whole gamification roadmap running: XP, streaks, achievements, leaderboard, coin shop, weekly challenges, user duels. More than 40 tables, 14 pages, eight server functions. It worked, and it sold.
That’s when the bill arrived. Not as a broken screen, but in the three things vibe coding doesn’t solve on its own: who is allowed to call what, who pays for the infrastructure, and what happens the day something goes wrong. The audit covered the code, the database and the configuration of the live platform, and came back with nine findings — two of them requiring immediate action.
- All eight server endpoints accepted unauthenticated requests. Payment endpoints included: with no signature verification, anyone who found the URL could fake an approved purchase and grant themselves a lifetime subscription, credit unlimited coins or cancel someone else’s subscription. One of them allowed deleting the system’s historical records.
- Strictly private data was visible to the entire user base. Any user’s tasks, habits, goals and daily sleep, mood and productivity logs could be read by any other — and some of it without even being logged in. One table had a rule letting anyone create, edit and delete anyone else’s records.
- Database credentials were committed to the repository — the environment file wasn’t in `.gitignore`, which exposes the infrastructure and survives in Git history even after the file is removed.
- Business rules lived in the user’s browser. With no server layer, that included the rule deciding how much XP someone earns — the team was already manually watching, from the admin panel, who was gaming their own game.
- The infrastructure bill grew with no visibility. The environment ran on the AI tool’s own managed cloud, with daily charges that went unnoticed for days, and credit purchased beyond actual consumption: around R$2,000 a month.
- No automated tests, no monitoring, no staging environment and no documentation. Changes went straight to production, on top of paying users, and if a payment failed nobody was notified. The knowledge of how the platform worked lived in the conversation with the AI.
The turning point
The first decision is the one that matters most in an audit: separate risk from preference. A product with paying subscribers can’t stop to become elegant, and most of what an engineer complains about in AI-generated code is aesthetics, not risk. So every finding came in the same shape — severity, urgency, what was configured, the evidence in the code and the attack it enabled — and the queue was ordered by consequence, not by taste: first what causes direct loss and leaks personal data, then what blocks growth, and technical debt last.
The two critical fixes went in first, and both were about money and user accounts: signature verification on the payment webhooks, with any request lacking the correct secret rejected before any processing, and a valid token required on administrative functions, which stopped accepting anonymous calls. Then the rest: database access policies rewritten so each person reaches strictly their own record, credentials out of the code, request origins restricted, rate limits on login and email verification, and file storage locked per user.
The second front was cost. The infrastructure moved off the AI tool’s managed cloud — the most expensive and least visible option — to a proper managed database plus dedicated front-end hosting, with automatic backups and its own domain. The bill went from around R$2,000 a month to around US$20 a month. Users and the founders themselves reported a faster platform after the migration. The third front was writing what didn’t exist: Terms of Use and a Privacy Policy compliant with Brazil’s LGPD, with a legal basis per purpose, retention, account deletion, and what one user can see of another in the leaderboard and duels.
The decision that unlocked it
Stabilize first, evolve later — and rewrite nothing. The product had 1,312 active users, mature gamification and a finance module the founders had already refined with their own base. Rewriting from scratch would throw away the most expensive asset: the product understanding the client had and we didn’t. The audit was explicit about what it did not recommend — the architecture without a dedicated server was adequate for that scale, and replacing it before closing security and process would be spending money in the wrong place.
What we delivered
01 · The audit of what the AI built
A 24-page technical report portraying the live platform: nine findings, two requiring immediate action, each with severity, urgency, the evidence in the code and the attack it enabled. Plus the full database mapping, the quality and maintainability analysis, the access inventory and a four-phase action plan. Not a list of complaints: a decision queue.
02 · Fixes applied, not just pointed out
Payment and coin webhooks with signature verification; administrative functions requiring authentication; database access policies rewritten per user and per role, making tasks, habits, goals and well-being logs private; credentials out of the code; restricted request origins; rate limits on login and email verification; file storage isolated per user. An audit that only points is a quote — this one came with the repair.
03 · Infrastructure migrated, with the bill under control
Off the AI tool’s managed cloud and onto a proper managed database with dedicated front-end hosting, automatic backups — which the previous setup didn’t guarantee — and its own domain. From around R$2,000 a month to around US$20 a month, without taking the product offline and without losing a single record.
04 · The new foundation and the missing documentation
Four stages of a proper foundation built and demonstrated in staging: infrastructure, CI/CD and design system; user account and base management panel; tasks and habits rebuilt on a dedicated backend, with kanban, list, calendar and three habit types; and notifications by web push and email with per-channel preferences. Plus five complete visual themes and the Terms of Use and Privacy Policy the platform never had.
How we made it hold
Findings with evidence and attack — not opinions about code
Every item in the report carried the configuration or code that backs it, what an attacker could do with it, and how it would look after the fix. That’s what separates a report that produces decisions from one that produces anxiety — and it’s what allowed us to hit the two critical flaws in week one, instead of starting with the most visible technical debt.
Fixing without taking the product offline
The fixes came in through branches and review, on top of a product with subscribers using it every day. Nothing was treated as "let’s stop to fix things": the system kept selling and kept receiving interface tweaks and bug fixes during the same period security was being closed and the new foundation was being built.
Handing back a product a non-engineer can operate
The handover wasn’t about delivering a repository, it was about delivering autonomy: code on the client’s account, his own deploy, direct database access, and a defined path between the working branch and production. The client kept editing the product with the same AI tool he already knew. Along with it went whatever remained a risk in his hands, in writing — including the single database with no staging, where a schema change takes effect immediately.
The outcome
The best outcome of this project is the most counter-intuitive one: Epicora left, and the product stayed up and kept evolving. In a market where competitors clone features in days using the same AI tools, speed of reaction was the client’s priority — and he wanted to work on the app with his own hands. Instead of treating that as a loss, we treated it as the correct ending: critical flaws closed, cost cut, risks documented, keys handed over.
And that’s the honest answer to the question everyone asks before hiring an audit of AI-generated code — "will I have to throw away what’s already built?". No. What the AI built stayed live, serving the whole user base, and kept receiving new features. What changed was what sat underneath.
Related solutions
Related cases
Built it with AI and don’t know what will break as it grows?
Epicora audits AI-built software and returns an honest picture: what is risk, what is merely technical debt, and what can be kept. No blind rewrite — and no downtime.