Case study · Auction filtering
How one mechanic got back 1.8 hours a week
An independent mechanic was spending 2 hours a week working an auction list that was mostly cars he had already rejected. Twelve days after the first commit, he had a system that shows him only what he has not seen, running on his own machine.
- 1.8
- hours a week, on his own estimate
- $135
- a week, at the rate he puts on his time
- 12
- days, first commit to last
The challenge
He is an independent mechanic who buys salvage vehicles at online auction and repairs them, on his own paid membership, working from an iPad. One person, no team, no back office. Every hour he spends sorting a list is an hour he is not spending on the part of the job that makes money.
He put the routine at 1 hour a sitting, 2 sittings a week, working through hundreds, even after filtering. Roughly 90% of what came back each time were cars he had already looked at and turned down. The auction site is good at finding candidates. What it cannot do is remember which ones he has already decided about, so every session started at the top of a list he had mostly seen before.
The solution
One click instead of a scrape. The auction site already exports an entire result set to a file. Measured at 39 rows on a narrow search, and it runs up to the site’s own 1,000-row cap on a broad one, carrying 21 columns of vehicle data. He exports it himself and brings it into the app. A second click copies the search page he already has open, which is where the photos and a few fields the export has no column for come from. Both are things he does, not things the app does for him.
Every car carries a state. New, opened or decided. The default view shows only the ones he has not ruled on, and the moment he decides about a car it drops out and stays out. That single behavior is what removes the repeated work.
Filtering runs on the server. The simpler version filters in the browser, and past a thousand accumulated vehicles it starts showing a confident screen of results drawn from only part of his data. He would have had no way of knowing. Moving it server-side removed a wrong answer he would never have caught.
The results
The 90% he was re-reading every session is what the system is built to take off his desk. On his own figures that is 1.8 hours a week returned to him, worth $135 a week or about $7,000 a year at the $75 an hour he puts on his own time. Those are his estimates of his own routine, not readings taken off a stopwatch.
It is built to run on his own machine, with the iPad reaching it over his own network. The server makes 0 requests to the auction site. There is no login in it, no crawler and no copy of his account. The one thing that does reach the auction site is visible on screen. Vehicle photos load in his browser from the marketplace’s own image addresses, the ones that came off the page he captured. He owns the machine, the data and the schedule it runs on.
If this sounds familiar
If someone capable is spending a few hours a week redoing work a system should have remembered for them, put their hourly rate against it and see what a year comes to. In his case the work was already being done. It was just being done twice.
Build figures are a frozen snapshot as of 2026-08-20: 74 commits and 59 test files, across 2026-08-08 to 2026-08-20. The commands producing them run inside the client’s own repository, which is private, so they are recorded for whoever re-locks this snapshot: git rev-list --count HEAD · find . \( -name '*.test.ts' -o -name '*.test.tsx' \) | grep -v node_modules | wc -l · git log --format='%ad' --date=short | sort -u | sed -n -e 1p -e '$p' · awk 'END{print NR-1}' shared/fixtures/search-export-filtered-39.csv · head -1 shared/fixtures/search-export-filtered-39.csv | awk -F',' '{print NF}'. The 2-hour week, the 90% and the $75 hourly rate all come from the client, in conversation.