How much does it cost to run?

About $2.40/month at typical small-business volume (a handful of sources and a few thousand rows a week). The fixed cost is essentially zero. The biggest single line is the one Bedrock call a week that writes the summary paragraph; gathering and comparing the numbers is plain Python and costs pennies. At ten sources and heavy weekly volume the bill lands around $9.

Which AWS services does it use?

Lambda (Python 3.14, arm64) with a Function URL for the email links, EventBridge Scheduler for the Monday run, DynamoDB on-demand, S3 (with versioning), SES outbound, Secrets Manager, Parameter Store, CloudWatch Logs (7-day retention), AWS Budgets, and Bedrock (Claude Haiku 4.5 via Global cross-Region inference) for the one weekly summary paragraph. No API Gateway, no NAT Gateway, no always-on compute, no Knowledge Base.

Where do the numbers come from?

From the sources you point it at: a sales export in a Google Sheet, a Stripe or bank CSV in a Drive folder, a point-of-sale daily summary, whatever holds your real figures. A small sync Lambda mirrors each source to S3 on a schedule; the builder reads from S3 so the run is predictable and you get S3 versioning for free. You list each source once in a short config doc, and the builder gathers from all of them.

Sparingly. Gathering the numbers, computing the comparisons, and deciding what counts as a notable change are all plain Python — no AI. Bedrock Haiku 4.5 fires once a week, at the end, to turn the already-computed numbers into a short plain-English paragraph. The model is handed the real figures and told to only describe them; it never sources a number itself.

How do I know a number in the report is real?

Every figure in the report is computed by plain Python from your source data before the writing step ever runs. The summary paragraph is built only from those computed figures, and the email shows the underlying table next to the words so you can check any sentence against the numbers. If a source is missing, stale, or a figure jumps in a way that looks wrong, the builder flags it in the report rather than guessing — so a blank or a glitch never gets quietly reported as a real result.

What happens when a number looks off?

Plain-Python checks run before the report is written: a source that didn’t update, a figure that jumped far outside its normal range, a total that doesn’t reconcile. Anything that trips a check is added to a Needs a look section at the top of the report with the figure, what was expected, and why it tripped. The number is shown but clearly marked as unverified, and every flag is recorded in the wr-flags DynamoDB table so the trail is there if you want to see how often a source misbehaves.

Series · 7 parts Published June 20, 2026

Weekly report builder

A serverless builder that gathers a small business’s own numbers — sales, new customers, cash in and out, top items — from the sources you point it at, compares them to last week and last month, writes a short plain-English “here’s how the week went, here’s what changed” summary grounded in the real figures, and emails it every Monday. It only reports facts from your data, never invents a number, and flags anything that looks off. Seven posts on the same system — one diagram at a time — with an engineering reference at the end.

01

A weekly report builder on AWS for a few dollars a month

The whole system on one page — a gather piece, a writer piece, and a sender piece, plus the one rule they all share: every number in the report comes from your data.
02

How the numbers get gathered

Each source you list — a sales sheet, a Stripe export, a bank CSV, a point-of-sale summary — is mirrored to S3 on a schedule, then read and turned into one clean set of weekly figures.
03

How the weekly report gets written

Plain Python computes every figure and every comparison to last week and last month first. Only then does one Bedrock call turn those real numbers into a short paragraph — it never sources a figure itself.
04

How the report reaches the owner

Every Monday morning the report is sent by email, in the owner’s timezone, with the summary up top, the numbers table below, and the four checks between the writer and the inbox.
05

How a number that looks off gets flagged

Plain-Python checks catch a stale source, a figure far outside its normal range, or a total that doesn’t add up. Anything that trips goes in a “Needs a look” section — shown, but marked unverified, never reported as fact.
06

What the weekly report builder costs

A couple of dollars a month at SMB volume. The builder runs once a week, gathers and compares with plain Python, and only fires one Bedrock call to write the summary paragraph.
07

Engineering reference: the weekly report builder architecture

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

What is a weekly report builder?: A small serverless system that emails a small-business owner one clear weekly report of their own numbers. It gathers the figures that matter (sales, new customers, cash in and out, top items) from the sources you point it at, compares them to last week and last month, writes a short plain-English summary of how the week went and what changed, and sends it every Monday. It only reports facts from your data; it never invents a number, and it flags anything that looks off for you to check.
How much does it cost to run?: About $2.40/month at typical small-business volume (a handful of sources and a few thousand rows a week). The fixed cost is essentially zero. The biggest single line is the one Bedrock call a week that writes the summary paragraph; gathering and comparing the numbers is plain Python and costs pennies. At ten sources and heavy weekly volume the bill lands around $9.
Which AWS services does it use?: Lambda (Python 3.14, arm64) with a Function URL for the email links, EventBridge Scheduler for the Monday run, DynamoDB on-demand, S3 (with versioning), SES outbound, Secrets Manager, Parameter Store, CloudWatch Logs (7-day retention), AWS Budgets, and Bedrock (Claude Haiku 4.5 via Global cross-Region inference) for the one weekly summary paragraph. No API Gateway, no NAT Gateway, no always-on compute, no Knowledge Base.
Where do the numbers come from?: From the sources you point it at: a sales export in a Google Sheet, a Stripe or bank CSV in a Drive folder, a point-of-sale daily summary, whatever holds your real figures. A small source-sync Lambda mirrors each source to S3 on a schedule; the builder reads from S3 so the run is predictable and you get S3 versioning for free. You list each source once in a short config doc, and the builder gathers from all of them.
Does it use AI?: Sparingly. Gathering the numbers, computing the comparisons, and deciding what counts as a notable change are all plain Python — no AI. Bedrock Haiku 4.5 fires once a week, at the end, to turn the already-computed numbers into a short plain-English paragraph. The model is handed the real figures and told to only describe them; it never sources a number itself.
How do I know a number in the report is real?: Every figure in the report is computed by plain Python from your source data before the writing step ever runs. The summary paragraph is built only from those computed figures, and the email shows the underlying table next to the words so you can check any sentence against the numbers. If a source is missing, stale, or a figure jumps in a way that looks wrong, the builder flags it in the report rather than guessing — so a blank or a glitch never gets quietly reported as a real result.
What happens when a number looks off?: Plain-Python checks run before the report is written: a source that didn’t update, a figure that jumped far outside its normal range, a total that doesn’t reconcile. Anything that trips a check is added to a Needs a look section at the top of the report with the figure, what was expected, and why it tripped. The number is shown but clearly marked as unverified, and every flag is recorded in the wr-flags DynamoDB table so the trail is there if you want to see how often a source misbehaves.

All posts

Frequently asked questions

Other series