Suchagenten
Software that reads the used car market for me and explains every verdict.

- Type
- Side project, in everyday use
- Role
- Product, UX and UI, built with AI assistance (Claude Code)
- Timeframe
- November 2026, first search run on 2 Nov, current state from 7 Nov
- Platform
- Local web app, desktop and mobile, light and dark theme
- Tech
- Python, SQLite, HTML/CSS/JS without a framework, Claude API
Summary
I was looking for a used van, and the right vehicles are hard to find with the filters of the listing sites. What matters is the engine, the wheelbase and the body, and exactly these details are often missing or only mentioned in the free text.
So I built an app in which hard rules and an AI model work together. The rules filter out, the AI judges what cannot be expressed as a rule, and in the end I decide myself. The real design question was: How do I trust a system that makes a thousand decisions for me, without having to check each one?
The problem
I was after one of three structurally identical vans, Renault Trafic, Opel Vivaro or Nissan Primastar, with room behind the seats for a bed or a motorbike. Whether a van fits depends on details no site filter covers: a specific engine, the long wheelbase, passenger car registration instead of a panel van.
That led to three concrete tasks:
- Volume: By 7 November, 1,173 listings from two sites had come together.
- Messy data: One of the sites usually states neither engine capacity nor number of seats, and details in a listing contradict each other.
- Time pressure: Good offers go quickly, so the search has to run regularly and report what is new.
A moment that shows the design question
The system reported search runs for over an hour and a half, but nothing new appeared in the list. I took it for a bug. In fact the system had correctly filtered out all new listings, it just wasn’t visible anywhere.
The system was working correctly, and still I doubted it. The moment shows what runs through the whole app: Automatic decisions have to be traceable and correctable.
Key decisions
Decision 1
The funnel shows what the system filters out
A result list only shows what is left. The funnel above the list also shows how it got there: 958 listings seen, 179 passed the rules, 26 a fit according to the AI. A click on “passed the rules” or “a fit according to AI” filters the list, so the statistic doubles as navigation. What was filtered out is one click away too, and the numbers add up: 179 in the list and 779 filtered out make exactly the 958 listings seen.

Decision 2
Rules first, then AI
Having the AI rate every listing would be easier to build, but more expensive, and harder to follow in clear-cut cases. So rules check first. They filtered out 737 listings, most often because of “Kasten” (panel van) in the title. The AI only comes in where judgement is needed.
The price is more effort in configuration, and wrong rules can hide good listings. Three things help against that:
- Two levels: Exclusion criteria filter out, warning signs only cost points. “Engine damage” in the title is an exclusion. In the description it stays a warning sign, because it might also say “no engine damage”, and the AI judges that context.
- The preview from decision 5 shows the consequences of a rule before it applies.
- The “filtered out” view lists every rejected listing with its reason, duplicates included. If I disagree, one click puts it back in the list, and the AI rates it in the next run.

Decision 3
The AI is allowed to be unsure
A plain yes or no would fake a certainty that isn’t there with incomplete listings. So there are three verdicts and a score. Of 499 rated listings, 14 got a yes, 217 a maybe and 268 a no. The large maybe is honest: often a detail is missing that only a question to the seller can settle.
A verdict alone isn’t enough, though. The inspection report therefore shows what speaks for the vehicle and what still needs checking. Here the AI noticed that the data field says 22,000 km, but the description says around 220,000 km. The low value would have looked good in any filter list.

Rejected vehicles stay reachable through the filter, so I can check the AI’s verdict. AI errors are planned for too: some ratings contained only “x” or nothing as their conclusion. New ratings are retried once in that case, and the interface shows the most important finding instead.

Decision 4
The badge condenses the verdict
In a dense table, the verdict has to be readable at a glance. The shape comes from the inspection sticker on a car: ten ring segments show the score, the colour shows the verdict. For accessibility the verdict also appears as text next to it. The badge is the only striking shape in the app, surfaces and controls stay neutral.

Decision 5
From hard-coded logic to a tool for any search
At first the criteria were fixed in code. With search agents, any search can now be set up through the interface, with several vehicles, its own criteria and its own results.
The form mirrors how buying criteria actually work: key data as hard limits, exclusions and warning signs as terms, wishes as points. What cannot be expressed as a rule, I describe to the AI in my own words.

Two details change the relationship to configuration the most:
- Consequences before saving: Lower the price limit, and you immediately see which vehicles drop out of the list and why. Without this preview, every rule change would be flying blind.
- Costs where they arise: The estimate sits right next to the choice of listing sites, here about $3.60 a month in continuous operation. New agents start with the free site, the paid one has to be switched on deliberately.


Decision 6
Deleting has to feel final and be reversible
The recurring annoyance in a car search is the listing you rejected long ago that shows up again once it is re-posted. So deleted vehicles stay gone, even if they reappear as new or on the other site, and the AI no longer rates them. Because that goes so far, there is an immediate “Undo” and also a “Deleted” view.

Visual language
The app should feel like an inspection log, factual and precise: neutral greys, amber as the only accent for what is new, numbers in monospace so prices and mileage can be compared in columns. Colour comes from the content, from the badges and the photos of the vehicles.
The design follows the system setting for light and dark. On a phone the table turns into a list of cards, because the search often continues on the go.

As of 7 November 2026, agent “Transporter”
Outcome
The 201 deletions and 10 bookmarks show that I really use the list as a working list in everyday life. When moving from hard-coded logic to agents, I checked 1,131 real listings against the old rules, without a single difference. On top of that there are 69 automated tests and a data backup before the switch.
Limits and what I would do next
- One person as the test group: I am the only user and have not run usability tests. The settings require a lot of domain knowledge and would probably be too complex for other people. Next, I would let two or three people set up an agent without explanation.
- Trust is not measured: I have not systematically checked whether the AI wrongly rejects good vehicles. It would make sense to record every rejection I correct by hand and calculate an error rate from that.
- Local only: The app runs only on my computer, and notifications require an open browser tab. To use it on the go, it would need a server.
What I take away
The central work on an AI product lies less in the model than in everything around it that builds trust: visible filters, honest uncertainty, reasons and easy corrections. And AI-assisted building shifts the work: when building gets faster, deciding what to build and when it is good enough matters all the more.
Next project

