build.allanninal.dev

Part 1 of 7 · Price monitor series ~5 min read

A competitor price monitor on AWS for a few dollars a month

A small business loses track of what its competitors charge the moment it gets busy. The rival down the road that quietly cut its headline product by 15% last Tuesday. The online store that runs a flash sale every payday weekend. The supplier who crept their list price up 3% and nobody noticed for two months. Checking all of that by hand is the kind of chore that never makes it to the top of anyone’s day. This post walks through the design of a small monitor that watches those pages for you, notices when a price actually moves, and tells the right person with enough context to decide — without ever touching your own prices.

Key takeaways

  • Three sources for watched pages: a Drive watch list, a paste-a-link lane, and a catalog import lane.
  • Every page ends in one of four moves on each check: steady, first alert, repeat move, or big swing.
  • Per-page rules: a move threshold (default 5%), a check rate, and the owner who hears about it.
  • It checks gently — honors robots rules, staggers requests, backs off on errors. It only suggests.
  • Designed on AWS for about $2/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, "Watched pages" — a Google Drive watch list naming each competitor product page to check, plus a paste-a-link lane and a catalog import lane that add new pages to the list. Centre, "Rules and voice" — a Drive folder with a rules doc covering the move threshold per page, the check rate, and the owner, plus a voice doc with the alert message templates. Far right, "Owners" — the team members responsible for each product line; alerts land in their Slack DMs or, if no Slack ID is set, their email. Each connects via an arrow to the AWS account container below. Watched pages have an outgoing arrow into AWS. Rules and voice feed in to ground every alert. Owners receive alerts with the product, the competitor, the old and new price, the size of the move, a small recent history, your own listed price for reference, and a snooze button. Inside the AWS account are three components in a row, mirroring the layout above. On the left, the Page checker — fetches each watched page politely, reads the price with a saved rule, and stores the reading. In the middle, the Watcher — runs on a schedule; reads the price history; compares the new reading to the last one and the threshold; picks one of four moves: steady, first alert, repeat move, or big swing. On the right, the Dispatch — sends the alert via Slack or email, respects quiet hours and a daily cap, and tracks which alerts have already gone out. Internal arrows flow left to right. A note at the bottom reads: the monitor only suggests — it never changes your own prices. Watched pages list, paste-link, catalog Rules and voice thresholds, owners, templates Owners where alerts land pages in grounds alert with context AWS account Page checker fetch politely, read price, store reading Watcher picks one of four: steady, alert, repeat, swing Dispatch Slack or email, respects quiet hours reading move The monitor only suggests — it never changes your own prices.
Fig 1. Three sources outside, three pieces inside AWS. Pages flow in from a Drive watch list, a paste-a-link lane, and a catalog import lane. The Watcher runs on a schedule and picks one of four moves. Dispatch sends the right alert to the right person at the right time.

What you set up once (the outside)

  • Watched pages. A Google Sheet in a Drive folder, one row per page: product name, competitor, page URL, the field to read (the price, and sometimes a stock or sale flag), a check rate, your own listed price for reference, the owner email, and a move threshold (how big a change counts as worth knowing). You can fill it in once and forget it; new pages can also enter via two other lanes covered in Part 2 — a paste-a-link lane (drop a URL into a Slack box and the monitor reads it once and proposes a row) and a catalog import lane (products tagged in your own store catalog get matched to competitor pages automatically).
  • A rules folder. Two short Google Docs in a Drive folder. The rules doc covers the move threshold per page or per product line — how big a price change has to be before the monitor bothers you (default 5%), how often to check, and the quiet hours and daily cap so a busy sale day doesn’t bury you in alerts. The doc also lists the owner per product line (or per individual page, if it overrides) and the polite-fetch settings the monitor must obey. The voice doc holds one alert message template per kind of move — what the Slack DM or email actually says.
  • Owners. The people responsible for each product line. Each owner has a Slack member ID (so the alert is a DM, not a public ping) or, if Slack isn’t set up for them, an email address. Alerts land with the product name, the competitor, the old and new price, the size of the move, a small recent-history sparkline, your own listed price for reference, and a “Snooze” button that quiets that page for a while.

What runs on every check (the inside)

  • The page checker. Reads the watch list and, on each page’s schedule, fetches the page politely — one quiet request, a clear identifying user agent, honoring the site’s robots rules and any crawl-delay. It reads the price using a saved rule for that page (a small recipe that says where on the page the number lives). The reading — price, currency, in-stock flag, and a timestamp — is written to the price-history store. If the saved rule can’t find a price (the page layout changed), that’s the one place a model gets involved, covered in Part 2.
  • The watcher. Runs on a schedule, staggered across the day so requests never arrive in a burst. Reads the latest reading and the recent history for each page. Computes the change since the last reading and compares it against the per-page threshold. Picks one of four moves. Steady: the price didn’t move past the threshold — do nothing. First alert: the price crossed the threshold for the first time — tell the owner with full context. Repeat move: it moved again in the same direction since the last alert — re-alert, mention the previous reading. Big swing: a large jump (default twice the threshold, or a stock change) — flag it as urgent. The watcher itself doesn’t call a model — the move logic is plain Python.
  • Dispatch. Reads the voice doc, formats the alert message for the chosen move, and sends it. Slack DMs go through the Slack API. Email goes through SES outbound. Both honor quiet hours (no alerts between 7pm and 8am local by default) and a daily cap so a sale day doesn’t bury an owner. Every dispatch writes a row so the next check can tell whether this move already went out. A weekly digest summarizes the moves that week, plus any pages that failed to read. A monthly summary writes a short narrative: who moved, by how much, and where you sit against the market.

In plain words

You sell a popular kettle for $79. Your closest rival lists the same model. The monitor checks their page twice a day. On Tuesday at lunchtime the rival drops it to $69 — a 13% cut, well past your 5% threshold. The owner of that product line, Priya, gets a Slack DM: “Competitor Acme dropped the 1.7L kettle 13% — was $79, now $69 — you list it at $79. [recent history] [link to their page]” with a Snooze button. Priya looks at it, decides not to match (her margins are tighter), taps Note and types “holding price, our reviews are stronger.” The monitor logs the decision and keeps watching. Two weeks later the rival quietly puts it back to $79; the monitor sends a one-line “Acme kettle back to $79” so Priya knows the sale ended. Nothing in this story changed Priya’s price — the system only ever told her what happened.

The cost of running this is about $2 a month at SMB volume. The cost of not running it is the week you kept selling at full price while three rivals quietly undercut you, or the supplier increase you absorbed for two months because nobody was watching the list.

Design rules that shaped every decision

  • The monitor only suggests. There is no path that edits your store, your catalog, or any price.
  • Every alert ships with full context — product, competitor, old and new price, the size of the move, recent history, your own price. The owner never has to dig.
  • Four moves, always. Steady, first alert, repeat move, big swing. There is no fifth.
  • Be polite. Honor robots rules, stagger requests, identify yourself, back off on errors. A page that keeps failing is paused, not hammered.
  • Quiet hours, a daily cap, and a move threshold keep alerts rare and worth reading. Noise burns trust.
  • The watch list lives in Drive. Adding a page, changing an owner, or shifting a threshold doesn’t need a deploy.

Why this shape

Most owners track competitor prices in one of three places: a browser tab they keep meaning to refresh, a spreadsheet they update once a quarter, or a vague memory of what things cost last time they looked. The tab gets closed. The spreadsheet goes stale the day after it’s built. And memory is the worst of the three: it tells you a competitor is “about the same” right up until you lose a deal you didn’t know you were losing.

The setup above keeps the list of what to watch in a doc the team already edits, but adds a small system that looks at those pages on a gentle schedule and speaks up only when something actually moved. Alerts come with enough context to decide on the spot. They’re rare by design — a threshold, quiet hours, and a daily cap mean an owner only hears about changes worth hearing about. And crucially, the system never acts on your behalf: it watches, it tells, and the pricing decision stays with a person who can weigh margin, reviews, and stock the way no rule can.

The next four posts walk through each piece in turn: how a competitor page gets watched, how a price move gets noticed, how an alert reaches the owner, and how an alert gets handled. One diagram per post. A cost breakdown and a final engineering reference at the end.

All posts