product 4 min read

We just caught a silent bug that would have spammed your inbox on day one

A trial-nudge email query had been quietly failing for five months. Nobody got the email. Nobody complained. Here's what happened and why we're telling you.

CM
Caleb McGennis

Yesterday I pushed a fix that caught a silent monitoring bug — one we had running for five months without knowing it was silent.

Here’s what it was. Every trial on this platform gets 30 days. Fourteen days in, we’re supposed to send a check-in email: “Noticed you haven’t published a process yet — want a hand?” It’s the nudge that keeps someone from quietly disappearing. The code to send it was written in May. The database column it queried didn’t exist.

The column was called is_public. The actual column is visibility. Supabase (our database) returns count: null when you query a column that doesn’t exist — it doesn’t throw an error. Our code read count: null and concluded “zero orgs need a nudge.” Every day for five months.

Six of our seven external trial organizations ran through their entire trial, got exactly zero emails from us, and silently lapsed to the free tier. The seventh is still mid-trial. If we hadn’t caught the bug this week, she would have been number seven.

That’s the story I wanted to tell you, because I think it says something about how to pick a software vendor that most pitch pages don’t.

The failure mode nobody writes about

The dangerous bugs aren’t the ones that crash loudly in your face. Those get fixed in 20 minutes because someone yells at us in Slack. The dangerous ones are the ones that look fine. The code runs. No exception. No alert. No stack trace. The user quietly experiences a slightly worse version of your product and churns six weeks later for “reasons.”

Software companies don’t talk about these publicly because the easiest thing is to fix them silently and never mention it. I decided to mention it, because the alternative — pretending we don’t have them — is worse.

What we actually changed

Three shipments this week:

  1. The nudge query now reads the correct column. Our one in-trial organization gets her mid-trial check-in on October 26.
  2. Every trial email now carries a working unsubscribe link. It didn’t before. CAN-SPAM says it has to. More importantly, if someone wants to be left alone, they deserve a one-click way out that actually works. We shipped the endpoint, wired it into every outbound email, and verified the fallback: if the opt-out database read fails for any reason, the whole run halts rather than silently emailing people who already told us to stop.
  3. An audit of every similar bug class — scheduled functions querying nonexistent columns, API endpoints writing to the wrong database client, authentication code assuming the wrong response shape. We found three more issues in internal analytics scripts (not production, but still wrong). All fixed.

Why documentation is the actual insurance

The honest reason this bug lived for five months: the person who wrote the code wasn’t the person who read it last. By the time the broken behavior became visible — six missing trial activations, a flat MRR line, no customer anger because the users never knew what they were missing — the original intent was lost in git history.

This is the exact problem we built the product to solve. SOPs are insurance against knowledge walking out the door. In our case, the “knowledge walking out the door” was a correct database column name — not an employee leaving, but the same information decay.

The fix wasn’t just a code change. It was a documented standard: before any new scheduled job ships, grep every column it references against the live schema. That standard is now in our team’s docs. If I get hit by a bus tomorrow, the next engineer finds the rule.

What this means for anyone kicking our tires

I’m not writing this to pitch you a flawless platform. We’re early-stage and this product still has sharp edges. I’m writing it because when something goes wrong on a tool you depend on — and it will — the question that matters is whether the team behind it is paying attention. Whether they notice. Whether, when they notice, they tell you.

I noticed. I’m telling you.

If you’re evaluating What’s the Process For and that reads as a bug not a feature, I understand. If it reads the way I hope — “a founder who’s actually paying attention and willing to say so out loud” — then grab the trial. The one who’s two weeks into hers right now is about to get a working nudge email with a working unsubscribe link. That’s the floor we’re building from.

Start a free trial — 30 days, no credit card. If you want to see our pricing first, it’s there.

The bus-factor problem is why we built this. Yesterday reminded us that we’re not immune to it either.

Tagged transparency trust process-documentation bus-factor

Ready to document your processes?

Start creating SOPs your team will actually use. Free to get started.

Start Free Trial

Get templates like this in your inbox

We send practical SOP templates and process documentation tips. No fluff, no spam.