How much does it cost to run?

About $2.40/month at typical small-shop volume (around 200 active members and roughly 1,500 sales a month). The fixed cost is essentially zero. The variable cost is dominated by the per-sale earn function and the nightly balance email; Bedrock fires only on the monthly owner summary, so it's a small sliver. At 1,000 members and 8,000 sales a month the bill lands around $11.

Which AWS services does it use?

Lambda (Python 3.14, arm64) with Function URLs for the POS webhook and the staff redeem button, EventBridge Scheduler for the nightly balance email and the weekly lapsing sweep, DynamoDB on-demand, S3 (with versioning), SES outbound, Secrets Manager, CloudWatch Logs (7-day retention), AWS Budgets, and Bedrock (Claude Haiku 4.5 via Global cross-Region inference) for the monthly owner summary. No API Gateway, no NAT Gateway, no always-on compute, no Knowledge Base.

Where do the rules and the member list live?

The earn rules and reward tiers live in a short Google Doc in a Drive folder you control — how many points per dollar, which items earn bonus points, and how many points a reward costs. The member balances live in DynamoDB, the system's own store, because they change on every sale and need to be exact. A small drive-sync Lambda mirrors the rules doc to S3 every 15 minutes so staff can edit a rule without a deploy.

Does the loyalty tracker use AI?

Sparingly. The earn math and the redeem check use no AI — they're plain Python that reads a price and applies your rules. Bedrock Haiku 4.5 fires only once a month to write the owner a short plain-English summary of the program: how many people joined, how many rewards were claimed, and which regulars are slipping away. Most of the system is deterministic by design, because points and money have to be exact.

How does a customer find out they've earned a reward?

The moment a sale pushes their balance over a reward tier, the earn function emails them: 'You've earned a free coffee — show this at the counter.' A short nightly email also goes to anyone whose balance changed that day, with their new total and how close they are to the next reward. Customers can opt out of the nightly email and keep only the reward-earned one. Every email respects the unsubscribe link and the quiet-hours setting.

What stops staff giving a reward away by mistake?

Redeeming is one tap but it always asks for a confirm. Staff look the customer up, the screen shows the reward and the points it costs, and staff press Confirm before the points come off. The system checks the balance is high enough first, so a reward can't be redeemed twice or on an empty balance. Every redemption is written to the loy-ledger table with the staff member, the time, and the points spent, so a wrong redemption can be reversed in one tap and the trail is auditable for years.

Series · 7 parts Published June 6, 2026

Loyalty tracker

A serverless points program for a small shop. Each purchase earns points by your rules; the system keeps every customer’s balance, emails them when they’ve earned a reward, and lets staff redeem a reward with one tap. It nudges regulars who haven’t been back in a while. Every points change is logged and reversible, and staff confirm each redemption so nothing is given away by mistake. Seven posts on the same system — one diagram at a time — with an engineering reference at the end.

01

A loyalty tracker on AWS for a few dollars a month

The whole system on one page — a sign-up piece, an earn-and-balance piece, and a redeem piece, plus the four moves they share for every sale.
02

How a shopper joins the loyalty program

Three lanes create a member — a sign-up form the shopper fills in, a quick at-the-counter add by staff, and an auto-enroll when a sale comes in for a phone number the system hasn’t seen before.
03

How a purchase earns points

A sale arrives, the earn function reads the rules doc, works out the points, and picks one of four moves: skip, add points, add points and announce a reward, or hold for review. No model on the earn path.
04

How a reward gets redeemed

Look up the customer, show the reward and what it costs, and the four guardrails between a staff tap and the points actually coming off — balance check, confirm, one-at-a-time lock, and a logged, reversible ledger row.
05

How a lapsing regular gets nudged

Three actions on a regular who’s slipping away: nudge (a gentle come-back email), bonus (a one-time points top-up to win them back), and rest (mark them inactive, stop the emails). Every action is logged.
06

What the loyalty tracker costs

A few dollars a month at small-shop volume. The earn math and the redeem check call no models, and Bedrock only fires once a month for the owner summary.
07

Engineering reference: the loyalty tracker architecture

Same system, drawn purely for engineers. Service names, resource identifiers, region, Bedrock model IDs, Lambda inventory, IAM scopes, the SES outbound config, EventBridge Scheduler config, and the DynamoDB schemas.

What is a loyalty tracker?: A small serverless system that runs a points program for a shop. Each purchase earns points by your rules; the system keeps every customer’s balance, emails them when they’ve earned a reward, and lets staff redeem a reward with one tap. It nudges regulars who haven’t been back in a while. Every points change is logged and reversible, and staff confirm each redemption so nothing is given away by mistake.
How much does it cost to run?: About $2.40/month at typical small-shop volume (around 200 active members and roughly 1,500 sales a month). The fixed cost is essentially zero. The variable cost is dominated by the per-sale earn function and the nightly balance email; Bedrock fires only on the monthly owner summary, so it’s a small sliver. At 1,000 members and 8,000 sales a month the bill lands around $11.
Which AWS services does it use?: Lambda (Python 3.14, arm64) with Function URLs for the POS webhook and the staff redeem button, EventBridge Scheduler for the nightly balance email and the weekly lapsing sweep, DynamoDB on-demand, S3 (with versioning), SES outbound, Secrets Manager, CloudWatch Logs (7-day retention), AWS Budgets, and Bedrock (Claude Haiku 4.5 via Global cross-Region inference) for the monthly owner summary. No API Gateway, no NAT Gateway, no always-on compute, no Knowledge Base.
Where do the rules and the member list live?: The earn rules and reward tiers live in a short Google Doc in a Drive folder — how many points per dollar, which items earn bonus points, and how many points a reward costs. The member balances live in DynamoDB, the system’s own store, because they change on every sale and need to be exact. A small drive-sync Lambda mirrors the rules doc to S3 every 15 minutes so staff can edit a rule without a deploy.
Does the loyalty tracker use AI?: Sparingly. The earn math and the redeem check use no AI — they’re plain Python that reads a price and applies your rules. Bedrock Haiku 4.5 fires only once a month to write the owner a short plain-English summary: how many people joined, how many rewards were claimed, and which regulars are slipping away. Most of the system is deterministic by design, because points and money have to be exact.
How does a customer find out they’ve earned a reward?: The moment a sale pushes their balance over a reward tier, the earn function emails them: “You’ve earned a free coffee — show this at the counter.” A short nightly email also goes to anyone whose balance changed that day, with their new total and how close they are to the next reward. Customers can opt out of the nightly email and keep only the reward-earned one. Every email respects the unsubscribe link and the quiet-hours setting.
What stops staff giving a reward away by mistake?: Redeeming is one tap but it always asks for a confirm. Staff look the customer up, the screen shows the reward and the points it costs, and staff press Confirm before the points come off. The system checks the balance is high enough first, so a reward can’t be redeemed twice or on an empty balance. Every redemption is written to the loy-ledger table with the staff member, the time, and the points spent, so a wrong redemption can be reversed in one tap and the trail is auditable for years.

All posts

Frequently asked questions

Other series