build.allanninal.dev

Part 1 of 7 · Deadline reminder series ~5 min read

A deadline reminder on AWS for a few dollars a month

A small business has more recurring deadlines than anyone keeps in their head. The payroll run that has to be submitted two days before payday. The quarterly sales-tax filing that is always “next week” until it is late. The business license that renews every year on a date nobody remembers. The workers’ comp policy. The annual report to the state. Most of these repeat forever, each one owned by a different person, each needing a different amount of warning. Miss one and the cost is a penalty, a lapsed permit, or a payroll that runs late. This post walks through the design of a small system that keeps a simple calendar of every recurring obligation, reminds the right person early enough to act, and escalates if one is about to be missed — then confirms when it is handled.

Key takeaways

  • Three sources for deadlines: a Drive sheet you keep, an inbox forwarding lane, and a calendar import lane.
  • Every deadline ends in one of four moves on each check: clear, first reminder, follow-up, or escalate.
  • Per-type lead times: payroll gets a nudge at 5 days, a follow-up at 2, an escalation at 1.
  • Reminders carry full context, respect quiet hours and weekends, and roll forward the moment a cycle is done.
  • Designed on AWS for about $1.60/month at typical small-business volume.

The whole system on one page

Before any code, here’s the shape of what we’re designing.

System shape: three sources, three pieces inside AWS At the top, three external boxes in a row. Far left, "Recurring deadlines" — a Google Drive sheet listing each recurring obligation with its name, type, owner email, how often it repeats, the next due date, and the lead time, plus an inbox forwarding lane and a calendar import lane that add new deadlines to the list. Centre, "Rules and voice" — a Drive folder with a rules doc covering per-type lead-time chains, deadline owners, and the escalation point, plus a voice doc with the reminder message templates from gentle to firm. Far right, "Owners and manager" — the person responsible for each deadline who receives reminders, and the manager who gets the escalation when a deadline is about to be missed. Each connects via an arrow to the AWS account container below. Recurring deadlines have an outgoing arrow into AWS. Rules and voice feed in to ground every reminder. Owners receive reminders that carry the deadline name, the type, the days remaining, and a link to any reference; the manager receives the escalation. Inside the AWS account are three components in a row, mirroring the layout above. On the left, the Deadline intake — receives deadlines from each source, parses forwarded notice PDFs via Textract and Bedrock, and writes the cleaned row into the list. In the middle, the Checker — runs daily; reads the deadlines; computes days-to-due per deadline; picks one of four moves: clear, first reminder, follow-up, or escalate. On the right, the Sender — sends the reminder via Slack or email, respects quiet hours and weekends, and tracks whether the deadline has been handled. Internal arrows flow left to right. A note at the bottom reads: every reminder stays calm — and the checker rolls a deadline forward the moment its cycle is marked done. Recurring deadlines sheet, inbox, calendar Rules and voice lead times, owners, templates Owners + manager where reminders land deadlines in grounds reminder with context AWS account Deadline intake parse, normalize, add to the list Checker picks one of four: clear, reminder, follow-up, escalate Sender Slack or email, respects quiet hours deadline move Every reminder stays calm — and the checker rolls a deadline forward the moment its cycle is done.
Fig 1. Three sources outside, three pieces inside AWS. Deadlines flow in from a Drive sheet, an inbox forwarding lane, and a calendar import lane. The Checker runs daily and picks one of four moves. The Sender sends the right reminder to the right person at the right time.

What you set up once (the outside)

  • Recurring deadlines. A Google Sheet in a Drive folder, one row per recurring obligation: name, type (payroll, tax filing, license renewal, insurance, compliance), owner email, how often it repeats (monthly, quarterly, yearly, or a custom day pattern), the next due date, the lead time, and a link to any reference document. You fill this in once with the deadlines you already know, then let new ones flow in from two other lanes covered in Part 2 — an inbox-forwarding lane (forward a renewal notice or a tax letter to a dedicated address and the system proposes a row for one-tap approval) and a calendar import lane (tag a calendar event and it becomes a proposed deadline).
  • A rules folder. Two short Google Docs in a Drive folder. The rules doc covers the lead-time chain for each type — how many days before the due date the system should remind, and how many times. Payroll typically gets a nudge at 5 days, a follow-up at 2, and an escalation at 1; tax filings get a longer 30/14/7/2; license renewals get 60/30/14/7. The doc also lists the owner per deadline (or per type, if it overrides), the escalation target if a deadline stays unhandled, the quiet hours, and any holiday days to skip. The voice doc holds one reminder template per step — the gentle first nudge, the firmer follow-up, the escalation.
  • Owners and manager. The person responsible for each deadline receives the reminders. The manager receives the escalation when a deadline is about to be missed. Reminders land with the deadline name, the type, the days remaining, a link to any reference, and the three buttons covered in Part 5.

What runs on every check (the inside)

  • The deadline intake. Three sources feed the list. The Drive sheet is the canonical store. New deadlines can also be added via the inbox forwarding lane (forward a notice to deadlines@your-company.com, the system uses Textract to read the PDF and Bedrock Haiku 4.5 to extract name, type, due date, and repeat, then drops a one-tap approval card in the owner’s Slack to confirm before the row is added) and the calendar import lane (tag a calendar event with #deadline and the same approval flow runs).
  • The checker. Runs once a day at 8am local. Reads the deadlines. For each one, computes days-to-due. Compares against the per-type lead-time chain in the rules doc. Picks one of four moves. Clear: the due date is still far off, or this cycle is already handled — do nothing. First reminder: just crossed the first lead-time step — send a gentle reminder with full context. Follow-up: crossed a later step with no action — send a firmer reminder, mention when the previous one went out. Escalate: hit the final step with no action — tell the manager named in the rules doc; log it. The checker itself doesn’t call a model on the daily check — the move logic is plain Python.
  • The sender. Reads the voice doc, formats the reminder message for the chosen move and tone, and sends it. Slack is the default; email is the fallback through SES outbound. It honors quiet hours (no sends between 6pm and 8am local by default) and skips weekends and holidays. Every send writes a row in DynamoDB so the next day’s check can tell whether a reminder already went out. A weekly digest summarizes everything coming up. A monthly summary writes a one-paragraph narrative: what was handled, what slipped, and what is due next month.

In plain words

Your quarterly sales-tax filing is due on April 30. It is owned by Dana, your bookkeeper, and the rules doc gives tax filings a 30/14/7/2 lead-time chain. On April 1, thirty days out, the system sends Dana a gentle Slack reminder: “Heads up — the Q1 sales-tax filing is due April 30. Here’s the link to last quarter’s.” Dana is busy and doesn’t act. On April 16, fourteen days out, a firmer follow-up that mentions the first one. On April 23, a week out, another. On April 28, two days out, with still nothing marked done, it escalates to the owner, Sam, so a human can make sure it happens. The moment Dana taps Done, the system records the filing as handled, rolls the next due date forward to July 30, and goes quiet on this one until the next cycle’s first lead time. Nobody hears about a deadline that is already handled.

The cost of running this is about $1.60 a month at SMB volume. The cost of not running it is the late-filing penalty, the lapsed permit that stops a job site, or the payroll that runs a day late because the person who submits it was on holiday.

Design rules that shaped every decision

  • Every reminder ships with full context — deadline name, type, days remaining, link. The owner never has to dig.
  • Four moves, always. Clear, first reminder, follow-up, escalate. There is no fifth.
  • The tone climbs from gentle to firm. Nothing rude ever goes out, even on the escalation.
  • Quiet hours, weekends, and holidays are respected. A reminder is a finite resource; bad timing burns it.
  • Marking a cycle done rolls the deadline forward on the next check. The system never reminds about a handled cycle.
  • Every send and every owner action is logged. Audit a filing next year and you can see every reminder that went out.

Why this shape

Most teams track recurring deadlines in one of three ways: a person who remembers to do it when they have time, a spreadsheet of “things due” that nobody opens, or a pile of paper notices in a drawer. The person works until they are busy — and the weeks they are busiest are exactly the weeks a quarter-end stacks up. The spreadsheet is a list, not a system: it tells you what is due but does nothing about it. And the drawer is how a business ends up paying a late-filing penalty it could have avoided with one day’s warning.

The setup above keeps the deadline list in a sheet the team already maintains, but adds a small system that looks at that list every day and acts only when something is actually coming due. Reminders go out early enough to matter — with more warning for a tax filing than for a payroll run, because the right lead time depends on the type. They are gentle by default and only firmer as a due date nears. They carry the context the owner needs. They escalate to a manager cleanly when it is time. And they roll forward the moment a cycle is handled. The system is invisible on the days nothing is due; it only shows up when an obligation is approaching and someone needs to act.

The next four posts walk through each piece in turn: how a deadline gets on the calendar, how a deadline comes due, how a reminder reaches its owner, and how a deadline gets marked done. One diagram per post. A cost breakdown and a final engineering reference at the end.

All posts