allanninal.dev/build

Part 1 of 7 · Job status notifier series ~10 min read

A job status notifier on AWS for a few dollars a month

Every service business runs the same quiet board: jobs come in, move through a few stages, and go out. The customer who handed over a cracked phone, a bike, or a suit to be altered hears nothing in between, and starts to wonder. This post walks through the design of a small notifier that watches that board and, the moment a job moves, tells the customer where it is — in the shop’s voice, with a photo and an honest ETA — and chases anything that goes quiet.

Key takeaways

  • The shop already moves each job across a board — received, diagnosing, in progress, ready. That board is the only trigger.
  • Every genuine stage change sends the customer one update by SMS or email, in the shop’s voice, with a photo and an honest ETA.
  • The stage facts and the ETA come from the job record; one Bedrock call only phrases them. It never invents a stage.
  • A daily sweep chases any job that has sat too long in one stage, so a customer is never left guessing.
  • Designed on AWS for about $2.30/month at roughly 200 jobs a month. Quiet hours mean it never texts at 2am.

The whole system on one page

Before any code, here’s the shape of what we’re designing. A service business — a phone-repair counter, a bike workshop, a tailoring studio — takes a job in, moves it through a handful of stages, and hands it back. The customer who dropped off a cracked phone on Monday hears nothing until it’s done, and spends the week quietly wondering whether anyone has even looked at it. The system below closes that gap: it watches the board the shop already keeps, and every time a job moves, it tells the customer where their job is and when to expect the next step. Nothing more.

This is deliberately not a parcel tracker. There is no courier and no tracking number. The thing being followed is work happening on a bench, and the only source of truth about it is the shop’s own board.

System architecture: a job board and shop settings outside, three pieces and a sweep inside AWS At the top, three external boxes in a row. Far left, “The job board” — where the shop moves each job from stage to stage (received, diagnosing, in progress, ready) and drops a photo of the work; this is the only thing that triggers a message. Centre, “Shop settings” — the shop’s voice for messages, the typical duration of each stage used to work out an honest ETA, and the quiet hours; these ground every update. Far right, “Customer” — where the update lands, by SMS or email, on whichever channel the customer chose. Each connects by an arrow to the AWS account container below. The job board feeds stage moves and photos in. Shop settings ground the wording and the ETA. The customer receives one update per stage change. Inside the AWS account are three components in a row. Left, the Stage watcher — polls the board, spots a genuine forward stage change, records it, and emits one event. Centre, the Message composer — gathers the stage, the ETA, and the photo, and makes one Bedrock Haiku call to write the update in the shop’s voice. Right, the Sender — delivers the message by SMS through SNS or email through SES, respecting quiet hours. Below the middle sits the Quiet-stage sweep — a daily job that finds anything stuck too long in one stage and chases it: a holding note to the customer and a nudge to the shop. Arrows flow left to right through watcher, composer, and sender, with the sweep feeding back into the composer. A note at the bottom reads: the notifier only ever reports where a job is — it never invents a stage, and never sends in quiet hours. The job board stages + photos Shop settings voice, ETAs, quiet hours Customer SMS or email stage moves grounds one update per move AWS account Stage watcher spot a real move, emit one event Message composer one Bedrock call, photo + ETA Sender SMS or email, quiet hours honoured move message Quiet-stage sweep daily: chase what’s stuck holding note The notifier only ever reports where a job is — it never invents a stage, and never sends in quiet hours.
Fig 1. Two sources outside, three pieces and a sweep inside AWS. The job board is the only trigger. The Stage watcher spots a real move, the Message composer writes one update with a photo and an ETA, and the Sender delivers it by SMS or email. A daily sweep chases anything stuck.

What you set up once (the outside)

  • The job board. Wherever the shop already tracks work — a Google Sheet with one row per job, or the board view of whatever job system the shop uses. Each row has a job id, the customer’s name and contact, what the job is (“iPhone 13, cracked screen”), the customer’s chosen channel, and the one field that matters most: the current stage. The shop moves a job by changing that stage, exactly as they do now. They can also drop a photo of the work against the job — the screen mid-repair, the finished hem — covered in Part 4. The board is the single trigger for everything downstream; if it doesn’t move, nothing is sent.
  • Shop settings. One short doc in the same place. It holds the things you’ll want to change without a deploy: the shop’s name and the voice for messages (warm and brief, or formal), the list of valid stages in order, the typical duration of each stage (used to work out an honest ETA for the next one), the quiet hours during which nothing should send, and the dwell threshold per stage that decides when a quiet job gets chased. Change a stage name or a quiet-hours window here and the system follows; no code changes.
  • The customer. Nothing for them to install. When the job is booked in, they give a mobile number or an email and pick how they’d like updates. From then on they get one short, friendly message each time their job genuinely moves — and a holding note if it ever sits still too long — on the channel they chose.

What runs on every move (the inside)

  • The stage watcher. A small Lambda polls the board every few minutes and compares each job’s current stage against the last stage it recorded. A genuine move — a known stage, a step forward, not a duplicate — gets written to a stage-history table and emitted as one stage.changed event. A typo, a sideways correction, or the same move seen twice is ignored. This is Part 2.
  • The message composer. Triggered by that event. It gathers the facts: which stage the job moved to, the honest ETA for the next stage from the settings, and the photo if there is one. One Bedrock Haiku 4.5 call turns those facts into a single message in the shop’s voice — “your repair is now in progress, ready by Thursday.” The model is handed the facts and told to use only those; it never decides the stage or the ETA. This is Part 3 (and Part 4 for the photo and the ETA).
  • The sender. Delivers the finished message on the customer’s channel — SMS through SNS, or email through SES — and records what went out. If the message would land inside quiet hours, it’s held until morning. Every update is de-duplicated against what was already sent, so the same news never goes twice. The daily quiet-stage sweep that chases stalled jobs is Part 5.

In plain words

Maya drops her cracked iPhone at the repair counter on Monday. It’s booked as job J-2042 and she picks text updates. Tuesday morning the technician moves J-2042 from received to in progress and snaps a photo of the opened phone. Within a few minutes Maya gets a text: “Hi Maya — good news, we’ve started on your iPhone screen repair. We expect it ready to collect by Thursday afternoon. Here’s a quick look: [photo]. — The Repair Bench.” Thursday lunchtime the job moves to ready and she gets a second text: “Your iPhone is repaired and ready to collect any time before 6pm. See you soon!” Two messages, both true, both in the shop’s voice, and nobody at the counter had to stop and write them.

Now the version that goes wrong without this. A different job, J-2051, goes into awaiting parts on Tuesday and the part is back-ordered. Nobody thinks to tell the customer, who turns up Friday expecting a finished job and leaves annoyed. With the sweep running, on Thursday the system notices J-2051 has sat in one stage for three days, sends the customer an honest holding note — “your repair is waiting on a part; we’ll update you the moment it arrives” — and flags it to the shop. The customer is told before they have to ask, and the job stops being forgotten.

Design rules that shaped every decision

  • The board is the only trigger. The notifier reports the shop’s own stages and never gets ahead of them.
  • One genuine move, one message. Forward changes only — never a typo, a sideways edit, or a duplicate.
  • Facts come from the record, words come from the model. Bedrock phrases the update; it never decides the stage or the ETA.
  • Honest ETAs only. A “ready by” is shown only when the shop has set one, with a buffer — never a wishful guess.
  • Never go quiet on a customer. A job stuck too long in one stage gets a holding note before they have to chase.
  • Respect the clock. Quiet hours hold overnight messages until morning; no one is texted at 2am.

Why this shape

Most small shops keep customers informed one of three ways: someone remembers to call, the customer phones to ask, or nobody says anything until the job is done. Remembering to call is the first thing that slips on a busy day. Waiting for the customer to ask turns every job into an interruption — and a customer who has to chase is already half-unhappy. And saying nothing until the end means the one time something genuinely slips, the customer finds out by turning up to a job that isn’t ready.

The shape above keeps the board the shop already maintains as the single source of truth, and adds a small system that turns each move on that board into one honest message — with a photo that proves work is really happening and an ETA the customer can plan around. The dull, easy-to-forget updates send themselves; the few jobs that genuinely stall get caught and explained before they become a complaint. And because the model only ever phrases facts it’s handed, the customer never gets told their job is “ready” when the board says it isn’t.

The next four posts walk through each piece in turn: how a stage change gets detected and trusted, how a customer update gets composed, how photos and ETAs get attached, and how a quiet stage gets chased. One diagram per post. A cost breakdown and a final engineering reference at the end.

All posts