Chris Raroque
Chris RaroqueFeb 23
Startups

How My App Is Doing (Not Good)

14 min video5 key momentsWatch original
TL;DR

Chris Raroque's calorie-tracking app Amy had its worst week since launch with two outages and a security vulnerability, but he fixed all three issues and actually improved the product.

Key Insights

1

status page self-sabotageChris discovered his status page retrieval was tied to the same infrastructure that went down, a mistake he'd seen big companies make. He moved it to a separate system so it won't happen again.

2

rate limit vulnerabilityA user found a vulnerability where they could modify their own subscription status and rate limits directly in the database. Chris wasn't mad, just moved those fields to read-only and kept the lesson cheap at 166 paying users instead of 1000.

3

voice-first development workflowChris uses Claude Cursor with voice dictation via Whisperflow to code Amy. Dictating prompts gets more detailed instructions than typing, and Whisperflow nails developer terminology like Supabase and useEffect.

4

retention improving slowlyAmy's week 1 retention climbed from 10% to 12.9% in two weeks. For every 100 new users, only about 13 stick around, but the trend is moving right.

5

manual ai provider fallbackWhen Perplexity Sonar went down for 15 minutes, Chris had a fallback: Gemini 2.5 Flash Light with Exa. It costs more but works well enough to keep the app running when the primary provider fails.

6

budget cap as safety netChris set a hard budget cap at the provider level to catch abuse or bugs early. He knows usage should be 300 to 400 a month, so he capped it at 1000 as a kill switch.

Deep Dive

Two Outages In One Week

Supabase, Chris's backend provider, went down for 5 hours. The problem wasn't just that the service died, but that Amy's authentication broke completely, leaving users staring at a blank white screen with no way to contact support. Users had to dig up his email and Twitter to complain. Chris got dozens of messages across multiple platforms, but everyone was surprisingly patient. The real kicker: his in-app support button was also inaccessible when the app was down. Two days later, right as he thought he'd solved everything, Perplexity Sonar (his AI calorie-calculation provider) went down for 15 minutes. More frustrated users. More emails.

How He Fixed The Outage Problem

Chris implemented a status indicator that shows when Perplexity Sonar or his own backend is down. He added a custom message field he can update remotely to tell users what's happening. But here's where he almost made the same mistake big companies make: he was pulling that custom message from Supabase, the same system that had just gone offline. He caught himself and moved it elsewhere. Now when Supabase dies, Amy shows a local status page and rechecks every 30 seconds so users don't need to restart the app obsessively. For AI providers, he built a manual fallback: if Sonar fails, the app switches to Gemini 2.5 Flash Light with Exa, which costs more but keeps the service alive.

The Security Vulnerability That Could Have Bankrupted Him

Chris was storing user subscription status and rate limits directly in the user table with row-level security that let users modify their own rows. A user could just change their rate limit from say 100 requests to a million and spam Chris's AI endpoints, racking up thousands in API costs. Someone actually found this vulnerability and disclosed it responsibly. Chris wasn't even upset about the premium status hack—he was 15 when he jailbroke phones—but the rate limit exploit was dangerous. The fix was simple: move those fields to read-only at the database level or use a separate admin table. He also added IP-based rate limiting and a kill switch so he can cut off any user instantly. Most importantly, he set a hard budget cap at Open Router at 1000 a month when his actual usage is 300 to 400. If that gets hit, all AI services shut down.

The Numbers (And Why They Matter Less This Week)

Amy hit 1,700 in monthly recurring revenue and 2,200 total revenue in the last 30 days, up 200 from two weeks ago. Week 1 retention climbed from 10% to 12.9%, meaning roughly 13 of every 100 new users come back after seven days. The trend is right, but Chris isn't reading too much into it yet. What mattered more this week was what went wrong and how he responded. He's at 166 paying users, which he admits is lucky. If he had a thousand, this week would have been genuinely catastrophic.

Dark Mode And A Breather

After the brutal week, Chris shipped dark mode to Amy. It was straightforward color work, but redoing all the app's illustrations for dark took time. His fiancée Cecilia redesigned them. It was the fun break he needed before diving back into the infrastructure and security work.

Takeaways

  • If you store status pages or status messages, keep them on separate infrastructure from what you're monitoring. Chris almost fell for the same trap big companies do.
  • Set a hard budget cap at your AI provider level. It's your last line of defense against abuse or bugs. Chris set his at 1000 when he expects 300-400 monthly usage.
  • Don't store sensitive fields like subscription status or rate limits where users can modify them directly. Use read-only database rules or a separate admin table.
  • For AI applications, implement a manual fallback provider. Chris uses Gemini and Exa as a backup when Sonar goes down, which happens regularly.

Key moments

2:00The Outage Cascade Begins

We had not one but two completely separate outages that impacted users and caused a lot of frustration. And then on top of that, we had a little bit of a security incident.

5:00Blank Screen Disaster

For 5 hours straight my app literally just displayed a blank white screen. That itself is a horrible situation. But what makes it even worse is now users have no way to even contact support.

10:00The Self-Sabotage Realization

Wait, if I'm getting the custom message from Superbase, but Superbase is offline, how is that going to work? I've actually seen this happen to a bunch of big companies where their status page is tied to the infrastructure that also went down.

15:00The Rate Limit Vulnerability

They could give themselves premium or they can raise their rate limits to whatever number that they wanted. Someone could raise their rate limit to a million, spam my endpoint, and then I would rack up hundreds of thousands of dollars in API usage.

20:00The Budget Cap Safety Net

I personally know that my usage is around 300 to 400 a month. So, I have my budget cap set to 1000. If I hit that and I get an email saying you exceeded your budget, I know that something went wrong.

Get AI-powered video digests

Follow your favorite creators and get concise summaries delivered to your dashboard. Save hours every week.

Start for free