I asked AI to audit my entire codebase for features that looked built but weren't. Found 12 dead ends.
I'm Bryan, 19, building Trakly, a budgeting PWA for people who just started earning. No CS degree, building with Cursor.
This week I ran a full codebase audit with one specific question: find every UI feature that looks implemented but has no actual backend logic wired up.
The results were embarrassing.
Here's what I found:
Critical (UI promised something the product couldn't deliver):
Paycheck Planner — full UI, Pro modal, looked great. Saved exactly nothing to the database. Ephemeral calculator only.
Recurring transactions — the toggle saved a flag. No logic ever generated the next occurrence. A "weekly" transaction just sat there forever.
Push notifications — labeled "Push Notifications" in Settings. Actually just browser alerts while the tab is open. No background push, no Web Push API, nothing.
High (partially built or enforcement missing):
Free tier 3-transaction limit — enforced in the UI only. CSV import could push free users way past 3 with no server check stopping it. Fixed with a database trigger that blocks at the DB level regardless of how the insert happens.
Pro feature gates — client-side only. No RLS or API enforcement on Pro fields.
Money Personality quiz — had a Pro gate in one place, completely bypassed in another.
Medium (UX gaps):
Deleted budgets saved to localStorage with no way to restore them. Flag was set to false, section never rendered.
No Spend Challenges had no cancel button even though the schema supported a 'cancelled' status.
Recurring bill badge showed after 6 months with no actionable follow-up.
Fixed all of it in one session.
The lesson: vibe coding gets you to a working demo fast. But there's a second pass that almost nobody talks about, auditing what actually works vs what just looks like it works. These aren't bugs that crash the app. They're silent failures that erode trust the moment a real user tries to use the feature seriously.
Trakly is at 5 organic users now. Small number, but every one of them deserves a product that actually does what it says.
If you're building solo with AI, run an audit. You'll find something
Underrated audit. UI shells survive longest in vibe-coded projects because they look done. The fix is partly process: every PR has to answer whether the database knows what just happened.
"The database has to know what just happened" is the exact mental model I'm taking forward. Every feature PR from here should answer that question before it ships. Would've caught all 12 of these before they ever made it to prod
This is a useful lesson because the issue is not just “AI made mistakes.” It is that a product can look complete while silently breaking user trust underneath.
For a budgeting app, that matters more than most categories. If someone just started earning and they trust the app with paychecks, recurring bills, limits, and Pro features, the product has to feel reliable before it feels clever. The audit angle is strong because it shows you are taking that responsibility seriously instead of just shipping a shiny demo.
One thing I’d also pressure-test early is the brand frame. Trakly is clear and friendly, but it also sounds very close to a lightweight tracker. If the product becomes more than transaction tracking — paycheck planning, money habits, challenges, budgeting logic, and financial confidence for first-time earners — the name may start feeling narrower than the trust layer you are building.
Auryxa .com would fit better if you want it to feel like a more polished consumer finance product, not just a tracker. The product is asking users to trust it with real money behavior, so the name has to carry credibility before the UI does all the explaining.
The trust layer point hits harder than expected for a budgeting app specifically, you're right that reliability has to come before cleverness when someone's handing you their paycheck data.
On the name, genuinely interesting take. Trakly was intentionally simple and approachable for the 18-25 audience who's intimidated by 'serious' finance apps. But you're right that as the product grows beyond tracking into habits, planning, and financial confidence, the name might start underselling it.
Not ready to rebrand over it, but it's something I'm keeping in mind. Auryxa is interesting, definitely carries more weight.
That makes sense. I would not force a rebrand before the product proves the bigger direction.
But I would separate the rebrand decision from the name-control decision.
Trakly can stay for the first wedge because it is simple and approachable. But if you already see the product moving beyond tracking into paycheck planning, money habits, budgeting logic, challenges, Pro features, and financial confidence, then the brand layer becomes more important than it looks right now.
The risk is not just “maybe rename later.”
The risk is that users, app assets, Pro features, financial trust signals, and early customer memory build around Trakly while the name you may actually want for the serious consumer-finance version remains uncontrolled.
That is why I would treat Auryxa.com as a real controlled option, not just an interesting direction.
It gives the product a more polished, trust-led consumer finance feel without sounding cold, bank-like, or intimidating for 18–25 users.
You do not need to rename today. But if Auryxa is genuinely the name that carries more weight for where this is going, securing it now is cleaner than revisiting the brand after more users and money-behavior trust build around Trakly.
I control Auryxa.com. If the fit is real, it is worth discussing privately now and keeping the acquisition side simple and founder-friendly before the brand gets harder to move.
Appreciate the thought and I can see the logic, but I'm not in a position to think about rebranding or domain acquisitions right now. Trakly is the brand I'm building around and the focus is on getting to first revenue before anything else. Thanks for the perspective though.