A buyer's AI agent vetted us before they bought. Here is what it fetched, what 404'd, and what we changed.
Before a buyer paid, their AI agent read our legal page, our support page and our security.txt on their behalf — and guessed four URLs that did not exist. A dated account of the visit, from our own access log, and the four routes we added the same morning.
On the morning of 30 August 2026 this store sold its first licence. The order itself took eleven seconds. The evaluation that preceded it took two hours the day before, and part of it was not done by the buyer at all. It was done by a program acting on their behalf.
This page is the account of that visit, taken from our own access log, with everything that could identify the buyer left out. We are publishing it because the pattern it shows is going to be ordinary very soon, and because it changed four things about this site the same morning.
What the log shows
The buyer arrived from a DuckDuckGo search on one of our comparison pages — the page that answers "what is a self-hosted alternative to a well-known retail point-of-sale product". From there the path was the one you would expect from a careful person: a related product page, the home page, the product they eventually bought, its live demo, the suite that bundles it with four neighbours, two of those neighbours' pages, the pricing page, and the page that explains how to connect an AI assistant to the software.
Interleaved with those page views, from the same network, was a second visitor with a different signature. Its User-Agent named an AI coding assistant, and it did not browse the way a person browses. In the space of a few minutes it fetched:
/legal— the terms, the refund policy, the licence./support— what is covered, how to reach a human, what happens when a download fails./.well-known/security.txt— the machine-readable security contact defined by RFC 9116.- the product page, and the home page.
Then it asked for four URLs that did not exist:
/suites/contact/p/field-service-suite/jobora(the product's bare slug, without the/p/prefix)
Each of those returned a 404. The agent did not retry with a different spelling; it reported what it found and moved on. Fifteen hours later the buyer came back through the same search engine and bought.
We do not know what the agent's owner asked it. The fetch pattern is consistent with a simple instruction — check whether this vendor is legitimate before I pay them — and the four guesses are exactly what a person would type if they were looking for a bundle, a way to get in touch, and a shorter address for the product. The point is not that the agent was clever. The point is that its report almost certainly contained the sentence "the site has no contact page", and that sentence was wrong for a reason entirely of our making.
What "vetting" looks like to a machine
A person deciding whether to trust a small software vendor looks for signals that are hard to fake: a real terms page, a named refund policy, a way to reach someone, evidence that the software exists and runs. An agent looks for the same things, but it can only find them at addresses it can guess or that the site tells it about.
That makes the machine-readable surface of a store load-bearing in a way it was not two years ago:
/llms.txt— a plain-text index of what the site is and what it sells, written for language models. Ours lists every product with its current price, the suites, the hosted tier, every guide, and the reference pages. Every figure on it is read from the database at request time, so it cannot drift from the store.- Structured data — each product, suite and comparison page carries a schema.org
ProductandOfferblock with the live price. security.txt— the standard place to put a security contact. The agent fetched it third.- A pricing page with every price on it — added earlier this month after another agent guessed
/plans,/pricing,/pricing-plansand/plans-pricingin sequence and 404'd on all four. - The obvious addresses —
/contact,/suites, and a product's bare slug. These are not standards. They are what people and their agents type.
The first four we had. The fifth we did not, and the agent found the gap in under a minute.
What we changed the same morning
By the time this page was drafted, the four missing addresses existed and had been verified from outside the network:
/suitesis now an index of every suite: what each one bundles, its one-time price, what the same apps cost bought separately, and the difference. The figures are computed from the current single-licence prices on every request; there is no typed number on the page, and a test refuses a build that contains one./contactredirects permanently to the support page, which now carries a contact section for everything that is not a support request./p/field-service-suiteand/p/field-service— a suite's slug under the product prefix — redirect permanently to the suite.- A bare product slug —
/jobora,/invora,/FLEETORA— redirects permanently to the product page. A bare suite slug, with or without-suite, redirects to the suite. Anything that is neither is still an honest 404; the redirect is registered after every other route so nothing existing can be shadowed by it.
Eighteen tests cover the new routes. The change shipped through the same deploy pipeline as everything else on this site, which — as of the same morning, for an unrelated reason — refuses to release a build in which any sellable product lacks its download file.
Why we are telling you this
Three reasons.
First, because it is true and dated, and this site's whole argument is that you should be able to check what it says. The access log is not public, but the routes are: try /contact, /suites, or /jobora now.
Second, because if you sell software, this is coming for you too, and the fix is cheap. Look at your own 404 log for the addresses that are guessed rather than mistyped. /contact, /pricing, /plans, /docs, /status, /security, a product name without its prefix — every one of those is a report an agent will hand to its owner, and "the site has no contact page" is a worse sentence to have in that report than it deserves to be.
Third, because the buyer's agent was not our referrer. It was their due-diligence tool. The search engine brought them; the comparison page kept them; the demo, the suite page and the pricing page did the persuading; the agent checked our homework. Each of those stages is a page we control, and each of them can be made better at its job. That is the work in front of us, and this page is the first receipt.
Nothing here identifies the buyer. The product is named because a product does not identify a person; nothing else from the order is disclosed. If you are the buyer and would rather this page did not exist, write to us at the support address and it will come down the same day.