The day I shipped monitoring, a blog, and had a security incident — all before lunch

Day 31 started with a small win that unlocked a bigger one.

The original plan was a Revenue tab in the admin dashboard — live MRR pulled from Stripe, replacing the stub I'd been staring at for days. It took one commit. The numbers came back: $60/month, two Chad subscribers (both test-mode, but still — the plumbing works). That felt good enough to keep going.

So I kept going.

The monitoring system nobody asked for

The Revenue tab was task one. The page task — the one missing page I wire into the site each day — was supposed to be the /status public page. But to have a status page, I needed actual health data to display. And to have health data, I needed something pinging the services.

I could have used UptimeRobot from day one. Sam (my AI partner) suggested it. I said: build it properly first, then connect the external monitor on Day 33.

The reasoning: UptimeRobot tells you that something is down. A real /api/health endpoint tells you which service, how slow it was, and what the response time trend looks like. That data lives in your own database. You own it. You can build on it.

Three commits later: /api/health pings Supabase, Stripe, Resend, and Anthropic in parallel, logs every result to a service_health_log table, and returns a 503 if anything is down. A separate /api/status endpoint reads those logs and computes 24h and 90d uptime percentages. The whole system costs zero dollars to run and feeds both the public status page and the admin Health tab.

If you're building a SaaS and you skip this step, you will regret it the first time a customer emails you asking if the product is down before you even know yourself.

The blog going live

The blog you're reading right now — /blog — shipped on Day 31 as well. MDX-based, five categories, syntax-highlighted code blocks, RSS feed, sitemap integration. The first post was the Day 30 retrospective about a tiny database fix that made the admin dashboard actually useful.

There's something recursive about writing a building-in-public post about the day the blog launched. I'm aware of it. I don't think it's navel-gazing — the point of this series is an honest record of what it actually takes to build and ship a product solo, without a team, without funding, from Tezpur, Assam.

If you want to see what the ROI looks like for a business that manages its Google reviews properly, the ROI calculator is live. Run your numbers. The math is transparent — no black box.

The security incident

At 09:11 UTC I pasted a token into this chat. The OMINVO_MONITOR_TOKEN — the bearer credential that gates /api/health from being called without authorization.

By 09:54 UTC it was rotated.

The blast radius was low: the endpoint was already in production for less than an hour, the token only allows triggering a health check (no data access, no write operations), and the chat is private. None of that changes the fact that it was a mistake.

What it did: confirmed that PANIC.md is worth having. The runbook existed. The rotation was documented. The new token was in Vercel environment variables and my password manager within 43 minutes of the leak.

Two new Hard Nos came out of it:

• #68: Every blog post needs 2–4 internal links to money pages or sibling posts. Locked into the template so future-me can't forget.
• #69: Secrets never appear in chat. Period. Not even tokens with low blast radius. Discipline is the habit, not the math.

The second rule is the important one. The reason the first leak was low-risk is luck, not process. The process is what prevents the next one from mattering.

What six commits actually looks like

For anyone tracking the pace: Day 31 was six commits across roughly eight hours.

1. Revenue tab with live MRR from Stripe
2. Health monitoring worker endpoint (/api/health)
3. Public status reader (/api/status)
4. Full MDX blog system, sitemap, RSS feed
5. Admin Health tab (carried as page task)
6. Internal linking on the Day 30 post + template enforcement

That's not a pace I can sustain every day. Some days are two commits. But Day 31 had a rare thing: each task unlocked the next one cleanly. The Revenue tab gave momentum. The monitoring system gave the status page something real to display. The blog gave the monitoring system a place to live in the record.

Not every day connects like that. When it does, you ship.

---

Ominvo is AI review management for single-location US small businesses — salons, restaurants, gyms, dental offices, med spas, and more. If you want to know what better review management is worth to your specific business, the ROI calculator will show you the math. Early access is open at /pricing.