An AI app that pays its rent

Ask a small-business owner what an AI app would do for them and most will describe a chatbot. Ask us and we will describe a job. The tools we build for clients do not talk to customers. They take one long, repetitive piece of work off a desk, do it well enough to be trusted, and leave a person to check the part that matters.

What does a working one look like?

Frank Zoller Authentic History runs militaria auctions in the United States. Every auction meant 1,250 lots entered by hand: photograph the item, then type a title, a description, a starting price and an estimate, one lot at a time, before a single piece could be sold. The work was not difficult. It was long, and it sat in front of every auction.

The platform we built takes the photographs and writes the listing rows. Behind it sits a reference corpus of 32,000 past items — titles, descriptions, estimates and the prices they actually fetched — so a repeat item pulls its own history and a new item is identified and described from the image. The filled template uploads to the auction site exactly as it always did. The first live auction ran on it on 16 August 2026, and the client counts 400+ hours saved.

The part that made it usable is not the writing. It is the review step. Every output carries a confidence score, and only the uncertain items are flagged for a person. Everything else passes straight through. A tool that needs every answer checked has saved nobody anything; a tool that knows which of its answers to distrust has.

There was a second finding we did not go looking for. Once the whole history sat in one place, it was plain that realised prices had been landing below estimates for years. Nobody could have seen that across a few thousand loose spreadsheets. That is the other thing a narrow tool does: it puts your own data where you can finally read it.

Why is it so narrow?

Oorlogsspullen is a militaria shop in the Netherlands. The tool we built for it does one thing: it drafts a product listing from what the shop gives it, in the shop’s own voice, and a person reads the draft before it goes live. There is no dashboard, no account system, no settings page — nothing that was not needed to get a listing from a photograph to a draft. We publish no figures for it, because none have been measured and cleared, and we would rather say that than invent one.

It is narrow on purpose. Most of the value in a tool like this sits in one task, and most of the cost sits in everything built around that task to make it feel like a product. Every extra feature is a thing that can break, a thing somebody has to maintain, and a thing that makes the honest question — did this remove hours — harder to answer.

• One input, one output. A photograph in, a listing out. Nothing in between that needs a manual.
• No accounts. The moment strangers log in, you have acquired password resets, permissions and a duty of care.
• A visible review step, sized to how expensive a mistake is.
• Your own data as the reference, because that is the part no product on the shelf can copy.
• Documented well enough that the next person could run it without calling us.

How do you know it pays its rent?

Before we build anything we ask the client one question: what does this replace, in hours or in money? If the answer is vague, the tool will be vague, and it will end up as a demo that impresses visitors and changes nothing. If the answer is specific — this many lots, this many hours, this person, every week — the scope writes itself and so does the test for whether it worked.

Measure for a month before adding a single feature. If the hours did not move, stop. You have learned something cheaply, which was the point of starting small.

Should you build or buy?

Buy, most of the time. If software already exists that does most of the job, the part you compromise on is almost always cheaper than the maintenance you avoid. We say that against our own interest, because a build you regret costs us the relationship.

Build when the process is genuinely yours. The auction platform cleared that bar because the reference set was the client’s own history, and no product on the market has that history. The listing writer cleared it because the shop’s voice and categories are its own. If the reason your tool would work is knowledge nobody else has, it is worth building. If the reason is that you would like a tool, it is not.

Who owns the code?

You do, and it should be written down before the first invoice. Ask for the repository in your name, with the agency added as a contributor rather than the other way round. Ask for the hosting in your own account, paid on your own card. Ask for the reference data to live somewhere you can export from. Ask for the documentation — the plain-language file that says what the tool does, how to run it and what to do when it fails.

Then ask the question that separates a build from a dependency: if we stopped working together on Friday, what would stop working on Monday? A good answer is nothing — you would need to find someone to maintain it, as you would with any software. A bad answer is anything that mentions a licence, a key or an account the agency controls.

What does it cost to keep?

The build is the part on the proposal. The running costs arrive afterwards, and they are where budgets quietly break. The model behind the tool is billed on use, so real volume matters more than the demo suggested. The provider will change and reprice that model on its own schedule, and something that worked will stop working with no error message to tell you. And the review step is real work, done by a real person, every week — count it as a cost from day one rather than discovering it in month three.

A tool with nobody responsible for it does not break. It degrades, which is worse, because nobody notices until the output has been wrong for a while. Agree a monthly amount for care, or agree that there is none and mean it.

So the shape of the thing is unglamorous. One job. One input, one output. A review step sized to the cost of a mistake. Your own data, your own code, your own hosting. A number you measured before the build and again a month after it. That is what an AI app for a small business looks like when it is built to earn its keep, and it looks nothing like a chatbot.