I built a chair stock dashboard because manually checking refurb sites every few days had already failed. I was choosing between a Steelcase Leap V2, a Herman Miller Embody, and a Haworth Fern. The stock was scattered across refurb stores, listings disappeared or sat out of stock, and I kept forgetting to check.
That kind of automation used to feel suspiciously close to developer procrastination. By the time I had written the scraper, the dashboard, the deployment bits, and the alerting, I could probably have just bought the chair.
This time the maths changed. The project took a couple of hours, replaced a manual habit I was bad at keeping, and helped me buy a Haworth Fern within a few days. I saved more than £100 against the alternatives I had been looking at.
The old bargain was bad
The manual version was not complicated. Open a few sites. Search for three models. Check whether anything was in stock. Repeat every few days.
The problem was that the market did not behave like a tidy product search. I was looking at refurbished office furniture, not a single shop with stable inventory. Some stores had product pages for out-of-stock chairs. Some had category pages that mixed chairs, parts, filters, and old listings. Some had stock language that contradicted itself.
That is exactly the kind of job humans are bad at repeating and developers are tempted to automate badly. A scraper for one personal purchase sounds like too much machinery. A useful version needs more than a request loop. It needs enough parsing to avoid false positives, some storage, a readable dashboard, and a way to tell me when something changed.
Before AI coding agents, I would have treated that as too much work for a chair.
The cheap part was not the scraper
The reason this worked was not that scraping suddenly became neat. It was that the boring infrastructure was already present.
I already had a server where a small app could run under Docker Compose. The project could be deployed as a container, store state in SQLite, sit behind the existing routing setup, and send notifications through Gotify. That meant the actual shape of the tool could stay narrow:
- fetch a configured list of chair pages and searches
- normalize stock and price signals
- show the candidates on a dashboard
- keep diagnostics visible without making them the default view
- alert only after a real change
The repository ended up with 85 configured watches across the three models I cared about. Some watches were direct product pages. Others were search or category pages that could emit multiple possible matches.
That is the part AI coding agents changed for me. Building one scraper by hand is fine. Building lots of slightly different scrapers, plus the dashboard around them, is where the old version of this project would have become a weekend sink.
Here, the agent could chew through the repetitive surface area: Shopify listings, WooCommerce pages, generic product pages, category pages, and weird stock labels. I still had to inspect the output and tighten the rules, but I was not hand-writing every parser from a blank file.
The dashboard had to distrust itself
The useful version was not the one that showed every scraped row. It was the one that hid rows it did not trust.
The cleanup notes from 10 June 2026 show why. One baseline had 85 watches, 119 latest rows, 21 unknown rows, 4 conflicting rows, and 67 rows with parser warnings. That is not a shortlist. It is a pile of possible evidence.
The later dashboard separated the two jobs. The default view showed actionable candidates grouped by chair model. Diagnostics kept the suspect rows, empty searches, duplicate-suppressed rows, stale entries, parser warnings, and scrape failures available for inspection.
That distinction mattered. If a tool like this sends alerts on every noisy row, it becomes another inbox to ignore. The scraper only alerted for candidate rows, and only after it had a baseline. Stock transitions into in_stock or low_stock could send a Gotify notification. Price changes could do the same. The first successful scrape did not alert just because the database was empty.
That is the difference between "I wrote a scraper" and "I built a thing I can leave running while I make a purchase decision."
What it bought me
The practical result was boring in the correct way. I stopped remembering to check chair sites. The dashboard kept checking. A task I had been putting off because the search was annoying turned into a few days of watching a shortlist.
I ended up buying a Haworth Fern from Symon Furniture. The listing even used the Haworth Ferm typo, which is exactly the kind of detail a manual search can miss and a configured watch can include deliberately.
The saving was more than £100. That is enough to make the couple of hours feel rational, but the money is not the whole point. The stronger lesson is that this kind of personal tool has become easier to justify when three things are already true:
- the search is repeated and I keep missing it
- the market is fragmented enough that one site's alerts are not enough
- deployment and notifications are already cheap for you
If I had needed to set up a server, routing, persistence, alerting, and a dashboard framework from scratch, the old bargain might still have lost. With that scaffolding already in place, the cost moved down to "can I describe the job clearly and inspect the output?"
The rule I would reuse
I would not build this for every purchase. I would build it again when the thing I want lives across lots of small shops, the stock changes faster than my memory, and a wrong alert is irritating rather than dangerous.
The limit is important. AI coding agents did not remove scraper maintenance. They did not make hostile pages cooperative. They did not make noisy retail HTML trustworthy. What they changed was the threshold where a narrow, temporary tool becomes worth attempting.
For me, that threshold has moved. Personal automation used to be where developers went to avoid the task. With a prepared self-hosting setup and a coding agent that can cover the repetitive parts, it can now be the shortest path through the task.