← App Prototypes
App Prototypes 2026-11-05

Stop Ledger

A log of every text-message opt-out a small business receives, with the deadline to honor each one.

Stop Ledger
Prototype

Stop-Ledger

A log of every text-message opt-out a small business receives, with the deadline to honor each one.

Date: 2026-11-05 Form factor: web app Status: Prototype

What it is

Stop-Ledger reads the replies that come back from a business's text campaigns and flags the ones that read as opt-outs. That includes "STOP", but also "please stop texting me about sales" and "wrong number, leave me alone". Each opt-out gets a 10-business-day clock, a suggestion for which lists it covers, and a one-click suppress button.

Who it serves

The owner or office manager of a small clinic, salon, gym or home-services shop that texts appointment reminders and promotions through a basic SMS tool. They know "STOP" has to work. They are less sure what to do with a free-text "I'm done with these", or whether an opt-out on promos also has to stop reminders. Today that is handled by whoever happens to read the inbox.

Why it could be profitable

Model: flat monthly subscription for small businesses (something like $29–$79 depending on message volume), with a higher tier for agencies running several client accounts. It would sit alongside an existing SMS provider, not replace it.

The timing: the FCC's 2024 order says consumers can revoke consent to calls and texts by any reasonable means, and that revocations must be honored within 10 business days. Per a National Law Review report dated 2026-01-07, the "revoke-all" part (an opt-out on one message applies to all of that sender's automated messages) was pushed to 2027-01-31, while the other parts were already in effect. TCPA claims are a familiar litigation risk for small senders, which is the reason someone might pay for this.

The thin spots: I did not verify the penalty figures or the current litigation volume, so the size of the market is a guess. Many SMS platforms already handle the plain STOP keyword, so the product only matters for free-text opt-outs, cross-list scope and audit records. Whether owners will pay for that, instead of treating it as a settings page in their existing tool, is untested. This is not legal advice and a real product would need a lawyer reviewing the rules engine.

Form factor & scope

Web app. The prototype is a single page with a canned inbox and a keyword matcher. It has no SMS integration.

How to run it

  1. Open index.html in any modern browser.
  2. Opening from file:// uses a small embedded fallback dataset. To see the full 12-message set from sample-data.json, serve the folder (for example python3 -m http.server).
  3. Toggle "Simulate revoke-all" to see the scope text change, and type into "Test a reply" to try your own wording.

What's in this prototype

  • Reply inbox with opt-out detection, filterable by all / opt-outs / not yet suppressed / overdue
  • Deadline math: 10 business days from receipt, skipping weekends and listed holidays, measured against a fixed demo date of 2026-11-05
  • Status tags (suppressed, days left, overdue) and a Suppress button that moves a number to the suppression list
  • Scope hint per opt-out, which changes under the revoke-all toggle, and a "scoped request" flag for messages like "stop the reminders but I still want promos"
  • Reply tester for checking phrasing

Roadmap

  • Import from common SMS providers' exports or webhooks
  • Better intent detection than a keyword list, with a human-review queue for ambiguous replies
  • Exportable audit trail showing when each opt-out was received and honored
  • Quiet-hours and consent-record checks before a campaign sends
  • Multi-client view for agencies

Sources

Requirements

Stop-Ledger — Requirements

Goals

  • A user can see at a glance which customer replies are opt-outs and which are overdue.
  • No opt-out is left without a visible deadline.
  • The scope of each opt-out (one list vs. all lists) is stated, not assumed.

Primary user

Owner or office manager of a small service business sending appointment and promotional texts. They check the reply inbox a few times a week and need to know what must be suppressed and by when.

Functional requirements

  • FR1: Load replies (phone, received date, text, list, suppressed flag) from sample-data.json, with an embedded fallback if fetch fails.
  • FR2: Classify each reply as opt-out or normal using a phrase list, and show the matched phrase.
  • FR3: Compute a deadline of 10 business days after receipt, excluding weekends and listed holidays.
  • FR4: Show days remaining or days overdue relative to a fixed demo "today".
  • FR5: Show summary counts: replies, opt-outs, not suppressed, overdue.
  • FR6: Filter the inbox by all / opt-outs / not suppressed / overdue.
  • FR7: Sort by urgency (fewest days left first).
  • FR8: A Suppress button moves a number to the suppression list and updates counts.
  • FR9: Display a scope hint per opt-out; a toggle switches it between per-list and all-lists.
  • FR10: Flag opt-outs containing qualifiers ("but", "still want", "only") as scoped requests needing review.
  • FR11: A free-text tester reports whether typed text reads as an opt-out.
  • FR12: Escape all message text when rendered.

User stories

  • As an office manager, I want overdue opt-outs at the top, so that I handle the riskiest ones first.
  • As an owner, I want "please stop texting me" recognized, so that I don't depend on customers typing STOP.
  • As an office manager, I want one click to suppress a number, so that it takes seconds.
  • As an owner, I want to see which lists an opt-out affects, so that I don't keep sending reminders to someone who left.
  • As an owner, I want ambiguous replies flagged, so that I can ask rather than guess.
  • As an owner, I want to test how a phrase is read, so that I understand the tool's limits.

Non-functional requirements

  • Runs from file:// with no build step, no network calls beyond the local JSON.
  • Keyboard-usable controls and labelled inputs.
  • Data stays in the page; nothing is transmitted.

Out of scope (for the prototype)

  • Real SMS integration or sending
  • Persisting state across reloads
  • Legal determinations; the phrase list is illustrative

Open questions

  • Which SMS providers expose reply data well enough to integrate with?
  • How should "cancel" in an appointment context be told apart from an opt-out?
  • Do small senders pay for this, or do they expect it from their SMS provider?

More from App Prototypes