I sat with a founder this week who runs two cafes and a small events business. She does not use a project management tool. She does not use a CRM. Her entire operation lives inside a shared notes app split across three phones, hers, her assistant manager's, and her weekend lead's.

I asked why not a shared dashboard instead. She said dashboards assume someone opens them. Notes get read because they show up the same place as a text from her sister. That answer changed how I am building the daily brief inside FounderFlow. It cannot be one more tab someone has to remember to open. It has to show up where attention already lives, or it does not exist for her at all.

I am onboarding the first thirty founders into FounderFlow myself, one call at a time. No signup form, no automated email sequence. Just me watching how each person actually runs their business before I let the software near it.

It is slower than I planned. It is also teaching me things a form would never surface. One founder tracked her whole business through a shared notes app between three phones. Another had a rule that nothing counted as urgent unless a customer called twice. I would not have known to build for either of those cases if I had not sat with them first.

Before FounderFlow, I ran a care home for years. In that world, a false alarm isn't just annoying, staff stop trusting the call button, and eventually someone stops running when it goes off. That single lesson shaped FounderFlow more than anything from my software background.

When I started building an alerting system for founders juggling multiple businesses, my first instinct was the classic engineer move: flag everything that looks slightly off, let the human sort it out. Care home experience made me distrust that instantly. A system that cries wolf trains you to ignore it, right up until the one time it's real.

I've mentioned before that I override FounderFlow's "Needs Review" flag about 1 in 6 times. Someone asked me last week why I haven't tried to drive that number to zero, and it's a fair question, so here's the honest answer.

Early on I treated every override as a bug to fix. Then I actually started logging what I was overriding and why. Most of them weren't the model being wrong, they were the model being right about the data and wrong about the context, a cafe supplier invoice that looked like an anomaly but was just a seasonal order, a "dormant" lead that was actually just someone on vacation. The kind of thing that isn't in any dataset, it's just in my head from running the business.

Early on, FounderFlow let you dismiss an alert with one tap and move on, no explanation needed. I almost removed that in a redesign, because I wanted every override to come with a reason (too noisy, not relevant, already knew, etc.), figuring the extra data would help it learn faster.

I tested the "reason required" version on myself for two weeks before shipping it. What I noticed was that on my busiest days, I started ignoring alerts instead of dismissing them, because typing a reason felt like one more task, and ignoring something takes zero effort. That's worse than a clean dismiss, an ignored alert looks identical to one nobody has looked at yet, so it pollutes the "unreviewed" queue instead of clearing it.

I always assumed the software company was the "loud" business, most transactions, most moving parts, most likely to throw off a weird number. The cafe felt like the quiet one, a few dozen orders a day, easy to eyeball.

Turned out the cafe was generating more false-positive-looking noise than the software company ever did. Weather changes foot traffic day to day. A local event doubles orders for one afternoon. A regular's schedule shifts and a "usual" order disappears for two weeks then comes back. All of that looks like a signal if you're not used to reading it, and none of it means anything is actually wrong.

I'll admit something a little funny for someone who builds monitoring software: I still keep one thing tracked by hand, in an actual spreadsheet, separate from FounderFlow.

It's a weekly gut-check column. One line per business, written in my own words, on what I felt was off that week even if nothing technically triggered an alert. Not data, just instinct.

A prospective customer asked me this on a call before she'd even signed up: "What does it tell me on day one, before it knows anything about my business?"

Fair question, and an uncomfortable one, because the honest answer at the time was "not much that you can trust yet." That conversation is basically why the calibration flow exists now.

A customer asked me straight out last month: "Can you guarantee zero false alarms?" I get why she asked, false alarms are annoying and they train people to stop paying attention.

Here's what I actually told her: no, and you don't want that guarantee even if I could make it. Chasing zero false positives always means quietly raising the bar for what counts as a signal, which means real problems start slipping through as false negatives instead. You don't remove the errors, you just move them somewhere more expensive to find.

A few months back I almost added a "snooze all Monitor Only alerts" button. It was a rough week across all three businesses and the low-confidence flags felt like noise I didn't have time for.

Then a Monitor Only alert about a slow temperature drift in the cafe's walk-in cooler sat quietly for four days before I finally looked at it, and it turned out to be the early warning sign of a compressor issue that would've been a much bigger problem (and a much bigger bill) a week later.