allanninal.dev/build

Part 1 of 7 · Warranty registration handler series ~11 min read

A warranty registration handler on AWS for a few dollars a month

A warranty is only worth what you can prove, and the proof usually goes in the bin with the packaging. This post walks through the design of a small serverless system that turns registering a new product into a thirty-second scan — verified against the business’s own orders, with the coverage explained in plain language and the reminders already on the calendar — and quietly hands any later claim to a person.

Key takeaways

  • A buyer scans the QR on the product (or fills a short form) with the serial and proof of purchase; seconds later the warranty is registered.
  • The system verifies the purchase against the business’s own order records — a serial that was never sold, or a duplicate, is turned away.
  • It computes the warranty term and the exact expiry, stores a queryable record, and one Bedrock call explains the coverage in plain language.
  • Maintenance and pre-expiry reminders are scheduled at registration and released on their due dates, so the customer hears back at the right moment.
  • Designed on AWS for about $1.80/month at roughly 200 registrations. A serial registers exactly once; any later claim goes to a human with the record attached.

The whole system on one page

Before any code, here’s the shape of what we’re designing. Almost every product ships with a warranty and a little card that asks the buyer to register it — and almost nobody does. The card goes in the bin, the receipt fades, and eighteen months later a customer with a genuine fault can’t prove what they bought or when, while the business has no idea who owns its products or how to reach them. The system below closes that gap at the one moment the buyer is actually holding the thing: they scan a QR code, the purchase is checked against real order records, and the warranty is registered, explained, and diarised within seconds.

System architecture: a buyer registering a product, order records and the team around it, four pieces inside AWS At the top, three external boxes in a row. Far left, “Buyer’s phone or browser” — the person who scans the QR on the product or opens the short web form and enters the serial and proof of purchase. Centre, “Order records” — the shop’s own sales data, one row per order with the serial, purchase date, and channel, mirrored into AWS so a registration can be checked against a real sale. Far right, “Your team” — the person who picks up any later warranty claim or anything the system won’t handle automatically. Each connects by an arrow to the AWS account container below. The buyer submits the registration and receives the confirmation. Order records ground every verification. Your team receives claims and escalations. Inside the AWS account are four components. Left, Receive and verify — takes the form or QR post, runs anti-abuse checks, and verifies the serial and receipt against the order records, rejecting anything never sold, already registered, or out of window. Next, Compute and store — works out the warranty term and exact expiry, claims the serial with a conditional write so it registers exactly once, and saves a queryable record with the expiry indexed. Next, Confirm — one Bedrock Haiku call that turns the stored coverage into a plain-language confirmation sent to the buyer. Below the middle sits Remind and route — a scheduled sweep that reads the indexed expiry dates and sends maintenance and pre-expiry reminders, and the lane that hands any later claim to a person with the record attached. Arrows flow left to right through receive, compute, and confirm, with branches down into remind and route. A note at the bottom reads: a serial registers exactly once, duplicates and out-of-window purchases are rejected, and a human handles every claim. Buyer’s phone scans QR, fills the form Order records serial, date, channel Your team where claims land registration in, confirmation out verifies claim with the record AWS account Receive & verify check serial against real orders Compute & store term + expiry, claim serial once Confirm one Bedrock call, coverage in plain words valid stored Remind & route reminders + claims to a person rejected later claim expiry due (sweep) A serial registers exactly once, duplicates and out-of-window purchases are rejected, and a human handles every claim.
Fig 1. Three things outside, four pieces inside AWS. A buyer registers a product; Receive & verify checks it against real orders, Compute & store computes the expiry and claims the serial once, and Confirm explains the coverage. A scheduled sweep sends reminders, and any later claim branches to a person.

What you set up once (the outside)

  • The QR sticker and the form. Whatever your product already carries a serial on — a battery, a frame, a control board — gets a small QR label that opens the registration form pre-filled with that serial. Buyers without the scan can reach the same short web form and type the serial by hand. The form asks for two things only: the serial and a proof of purchase (an order number, or a photo of the receipt). It posts to one AWS URL, and its signing key lives in Secrets Manager. This is Part 2.
  • Order records. The sales data you already have — from your shop platform, till, or dealer network — with one row per order: the serial or batch it shipped with, the purchase date, and where it was bought. This is mirrored into AWS so a registration can be checked against a real sale rather than taken on trust, and it’s what tells the system a serial was genuinely sold, when, and therefore whether it’s still inside the registration window. A small settings doc alongside it holds the warranty terms per product and the reminder timings. This grounds Part 3.
  • Your team. The person who handles anything the system deliberately won’t decide on its own — chiefly a warranty claim, months or years later. They get the claim with the full registration attached: the serial, the verified purchase, the computed expiry, and the confirmation that went out. The system registers, explains, and reminds; a human handles claims, exceptions, and anything that smells wrong. This is Part 5.

What runs on every registration (the inside)

  • Receive and verify. The form posts a registration to one Lambda Function URL. The function checks the request is genuine and not part of a flood, then verifies the serial and proof of purchase against the mirrored order records — rejecting a serial that was never sold, one that’s already registered, and a purchase that falls outside the eligibility window. This is Parts 2 and 3.
  • Compute and store. For a verified registration, the system reads the warranty term for that product, computes the exact expiry date from the purchase date, and writes the record — claiming the serial with a conditional write so the same unit can never be registered twice. The expiry and reminder dates are indexed so the sweep can find them later. This is Part 4.
  • Confirm. One Bedrock Haiku 4.5 call takes the stored coverage terms — what’s covered, for how long, until when — and writes a single warm, plain-language confirmation for the buyer. The model phrases the coverage; it never decides what the coverage is. This runs at the end of Part 4.
  • Remind and route. A scheduled sweep reads the indexed dates and sends the reminders each warranty earns — a maintenance nudge partway through the term, a heads-up before the cover lapses — exactly once. And the claim lane hands any later claim to a person with the record attached. This is Part 5.

In plain words

It’s a Saturday afternoon and someone has just wheeled a new e-bike out of Cadence Cycles. On the down-tube is a small sticker: “Scan to register your 5-year warranty.” They scan it, the form opens with the frame serial CDN-8842193 already filled, they type in the order number from the receipt, and tap send. Within about eight seconds their phone shows: “You’re registered, thanks! Your frame is covered for 5 years and the motor and battery for 2, until 14 July 2028. We’ll remind you when your first free service is due.” Behind that, the system matched the serial to the actual sale, saw the purchase was two days ago and well inside the window, computed the expiry from the purchase date, and stored the record — and the shop didn’t touch a thing.

Two years and ten months later, a scheduled sweep notices that frame’s motor-and-battery cover expires in a month. The buyer gets one message: “A heads-up — the motor and battery cover on your Cadence bike ends on 14 July. Frame cover continues to 2033.” A fortnight after that they email to say the motor’s cutting out. That’s a claim, not a registration — the system does not try to adjudicate it. It pulls the stored record, attaches the verified purchase and the exact coverage, and drops the whole thing in front of a person at the shop, who can see at a glance the claim is inside the motor warranty and act on it. One scan at the start, well-timed nudges in between, and a human on the one decision that matters.

Design rules that shaped every decision

  • One serial, one warranty. A conditional write on the serial means the same unit can never be registered twice, however many times someone tries.
  • No purchase, no cover. Every registration is checked against real order records; a serial that was never sold, or is out of window, is rejected.
  • The dates are computed, not typed. The term and expiry are derived from the product and the purchase date, then stored — never entered by hand.
  • The model only writes words. Verification, the maths, and the scheduling are deterministic; Bedrock just explains the coverage in plain language.
  • Remind at the right moment, once. Maintenance and pre-expiry nudges are diarised at registration and each fires exactly once, honouring opt-out.
  • Claims go to a person. The system registers, explains, and reminds; it never adjudicates a claim — that lands with a human, record attached.

Why this shape

Most small brands handle registration one of three ways: a paper card almost nobody posts back, a generic web form that trusts whatever the buyer types, or nothing at all. The paper card is lost the moment the box is opened. The trusting form is worse than useless — it fills a database with serials that were never sold, warranties on grey-market units, and dates people guessed — so when a claim arrives no one believes the record anyway. And doing nothing means the business never learns who owns its products, can’t warn them about a recall, and meets every customer for the first time at the worst possible moment: when something has broken.

The shape above fixes exactly that. It leans on the order records the business already keeps as the single source of truth, so a warranty only exists behind a real sale. It makes registering effortless at the one instant the buyer is motivated — product in hand, box just opened — by putting a QR on the thing itself. And it turns the record into something that keeps working: reminders that bring the customer back for a service or a renewal, and a claim path that arrives with the evidence already gathered. The common case — a genuine buyer registering a genuine product — is fully automatic; the few that are duplicates, fakes, or out of window are turned away, and the one case that needs judgement, a claim, is put in front of a person.

The next four posts walk through each piece in turn: how a registration gets submitted, how a purchase gets verified, how a warranty record gets stored, and how the reminders get scheduled. One diagram per post. A cost breakdown and a final engineering reference at the end.

All posts