Software that pays its rent
We build custom AI apps for businesses with a repetitive, expensive job that a model can now do. We decide how the software earns or saves before we design a screen. For Frank Zoller Authentic History we built a listing platform that turns photographs into complete auction listings, 1,250 lots per auction, trained on a 32,000-item reference corpus, and it has saved 400+ hours.
In detail
What does a custom AI app development agency actually build?
Small, specific software that does one expensive job inside a business, with a model doing the part that used to need a person reading. A listing writer. A catalogue filler. A sorter that flags only what a human needs to see. Not a chatbot bolted to a home page. The test for whether a job is worth building for is simple: it is repeated, it is slow, it costs a wage or a weekend, and the output can be checked. If it fails any of those, we say so and you keep your money.
The Zoller listing platform
Frank Zoller Authentic History runs militaria auctions, and every auction meant 1,250 lots typed by hand: a title, a description, a start price and an estimate for each, one at a time, before anything could be sold. The work was not hard. It was long, and it sat in front of every sale.
We ingested 32,000 past items, their titles, descriptions, estimates and realised prices, into a hosted backend as the model's reference set. Photographs go in; complete listing rows come out. A repeat item pulls its own history; a new one is identified and described from the image. The output is confidence-scored, so only the uncertain items are flagged for a person and everything else passes straight through to the upload template. The first live auction ran on 16 August 2026, and the build has saved 400+ hours of the client's time.
One thing we found because the data was finally in one place: realised prices sat consistently below estimates across the whole set. The software was built to save typing. It also told the business something about its pricing it could not have seen lot by lot.
How a build is scoped
- 01
The money first
Before a screen is drawn we write down how the software pays: hours it removes, sales it adds, errors it prevents, and what each is worth a month. If that does not clear the build cost inside a year, we tell you not to build it. Software without a price is a hobby with a repo.
- 02
The corpus
A model is only as good as what it is shown. We find the data you already have, past listings, past orders, past descriptions, and make it the reference set, so the output sounds like you and not like a model.
- 03
The narrow version
The first build does one job end to end, for one user, with a review step. It goes live early and gets used, because a tool that is used for a month teaches more than a specification argued over for three.
- 04
Triage, not automation
We never remove the human; we move them to the exceptions. Confidence scoring decides which items need a look, so the person checks a few instead of all of them.
- 05
Handover
The code, the hosting accounts and the written knowledge base are yours. For ehsaan, a marketplace app, the first build took 23 prompts and now runs against a 19-section knowledge base so the product keeps its own rules as it grows.
Build or buy
| Build it | Buy it | |
|---|---|---|
| When | The job is specific to how you work and no product fits without bending you | A product already does the job well enough |
| Cost shape | Larger upfront, then hosting | Smaller monthly, forever, rising with every seat |
| Your data | Yours, in your own accounts | Theirs, under their terms |
| The risk | Building a thing nobody uses | Paying for a thing that never quite fits |
| Our advice | Only when the money page clears | First, if a product exists; we will name it |
What does a custom AI app cost to build?
It depends on the job, so we price it to the number it is meant to produce under Tailored rather than from a rate card. A narrow tool that drafts listings from photographs is a different build from a marketplace with payments and accounts. What is the same every time: the scope is written against how the software earns, the first version is small, and you own the result. There is a longer piece on what a custom AI app costs in the journal, with the questions to ask whoever quotes you.
Builds we have done
- An AI listing platform for an auction house: photographs in, complete catalogue rows out, with review triage.
- An AI writer for Oorlogsspullen, a militaria shop in the Netherlands, that drafts its product listings.
- A person-to-person thrift marketplace app for ehsaan, with its brand and launch in the same contract.
- A website for the same auction house, zollerhistory.com, built in an archival direction around the accession card.
The questions that follow.
Which models do you use?
Whichever fits the job and the budget, and we will say which one and why. The model is a component; the corpus, the review step and the scope are what make the tool work.
Do I need my own data?
You almost certainly have it: past listings, past orders, past emails. Most businesses are sitting on the reference set and do not know it.
Who owns the code?
You do. The repository, the hosting and the model accounts are in your name from the start, and the knowledge base is written so another developer could pick it up.
Can it start smaller than a full app?
Yes, and it should. The first version does one job for one user, and we widen it only after it has earned its keep.
How long does a build take?
A narrow tool can be in use within weeks; a full app is months. We give you the dates against the scope, and the first version always ships before the last feature is argued over.
The price is published.
Where this leads.
No deck. No discovery theatre. One metric, one date, in the contract.