Reminders feel like a product. They're usually a feature

No-shows cost real money. An empty chair at the dentist, a missed consultation slot, a table held and wasted — each one is revenue that simply evaporates, and a reminder the day before measurably cuts how often it happens. So the idea arrives wearing a product's clothes: wire a texting service to a calendar, fire a message before each appointment, and charge for the revenue you save. It demos in an afternoon, and here's the part that makes it convincing — it actually works. The text goes out, the no-show rate drops, the thing does its job. That's precisely why it's easy to mistake for a business.

This is a short piece because the correction is short, and it's the most useful thing the build-idea exercise produces: a clean example of an idea that works perfectly and is still not a product. Seeing why teaches a test you can run on the next idea before you build it.

Ask where the reminder lives

A reminder is not about itself. It's about an appointment — and the appointment lives somewhere else. It lives in a booking system: the calendar that holds the slot, the customer record, the scheduling rules, the cancellation flow, the timezone the customer is in. To send a single reminder you need the appointment time, the contact details, whether the slot was already cancelled, and which timezone to read "tomorrow at 9" against. You own none of those. You borrow every one of them from the booking system.

So the reminder is the last and smallest step of a workflow whose entire body belongs to something else. Sell it on its own and you're selling the tail of a product whose body the buyer already has — Calendly, a salon's booking tool, a clinic's practice-management software — each of which ships reminders as a checkbox, because the reminder is so obviously a feature of the thing that owns the appointment.

The test: what data does it own?

Here's the tell, and it generalizes into a question worth asking of any idea before a line is written: what data does this thing own? A real product owns a record someone would miss if it vanished — the booking, the account, the ledger, the uploaded file. The reminder owns nothing. Delete the reminder service and every appointment is untouched; delete the booking system and the reminder has nothing left to fire about. A thing that owns no data of its own, and acts only on data owned elsewhere, is a feature of whatever owns that data. That isn't an insult — features are essential, and most of a product's value is in its features. It's just a different thing from a standalone product, and the difference decides whether anyone will buy it by itself.

You can see the same verdict from the foundation's side, which is the other half of the proof. Sending a reliable, templated, retried message on a schedule is such a thoroughly settled capability that it already runs inside a foundation as a plain module — the email-service behind both Smallbox products sends receipts and reset links from a queue with a history and a bounded retry. A reminder is one more templated message on that existing queue. The fact that it's an afternoon's work on top of a foundation is not evidence it's a quick business; it's evidence it's a feature, because the things that are features are exactly the things the module already does for free. What that email module keeps and what it leaves to the provider is its own note — and a reminder rides every bit of it.

The one shape where it edges toward a product

Honesty cuts both ways, so here's the exception. There's a narrow case where reminders lean toward a product: a vertical where the reminder is the load-bearing reason the workflow exists, and no incumbent already owns the booking — a trade whose practitioners still run on a paper diary and a phone. But look closely at what you'd be building there. To send the reminder you'd first have to capture the appointment, the customer, and the schedule — so you'd be building the booking system, and the reminder would still be its feature. The reminder didn't graduate into a product. You backed into building the product it was always a feature of, which is a fine thing to build — just not the thing you thought you were selling.

The verdict

The honest verdict is the deflating one, and it's worth stating plainly: an appointment reminder is almost always a feature inside a booking system, not a standalone SaaS — and the fastest way to have known that was to ask what it owns and hear nothing back. Build it, by all means. Build it as part of the system that owns the appointment, where it's cheap, obvious, and genuinely valuable. As its own product it has no ground to stand on, because it has no data to stand on.

That's the real payoff of running the test early: it's far cheaper to find the "this is a feature" answer in a paragraph than after a quarter of building. When the messaging, scheduling, and logging are already part of the foundation, wiring a reminder into a product that owns its appointments is an afternoon — which is exactly the right amount of effort for a feature, and exactly the wrong amount of confidence to mistake for a company.