There is a tendency to talk about AI models as though organisations need to choose one. Which model are we using? Which is the best model? Should we standardise on the most capable one? Our experience building a new internal expenses application suggests a more useful question:
What is the right AI model for this particular job, at this particular stage?
We recently built Wisereach Expenses, a simple mobile-first application to replace the expense subscription services we were using previously. What became interesting wasn't just the application. It was how it was created.
We wanted to test applying different OpenAI models to different problems. So we created a 'delivery team' using four of the latest OpenAI models: Astra, Sol, Terra and Luna. They all played different roles. Some helped us think. Some built. Some refined. Some tested. And smaller models now perform work inside the finished application itself.
The result is a useful example of what a multi-model approach to AI delivery can look like in practice.
Start with the business problem, not the technology
Recording expenses was more cumbersome than we wanted it to be, and not aligned with the way our consultants work. It's just expenses admin after all. And consultants hate admin — although expenses at least has the carrot of getting your money back for doing the task!
The requirement was straightforward: make it extremely easy for somebody using a phone to photograph a receipt, capture the important information, allocate the expense correctly and submit it.
That gave us the initial concept.
From there, AI became a way of accelerating the journey from an idea to a working, supportable application.
AI helped turn the idea into something buildable
Our first step was to use basic ChatGPT to turn the relatively loose business idea into a much more structured product prompt. We didn't try to write a full requirements document. We explained the problem, the users and some of the things our consultants wanted the application to do.
We then gave that structured brief to Astra, using a model particularly suited to creating something new, to build the first working version of the application.
Very quickly, the concept had become an MVP that we could actually use.
Then the nature of the AI task changed
Once the first application existed, we no longer needed AI to invent an entire solution. The problem had changed.
We needed to adjust screens, improve workflows, correct behaviours and add relatively small pieces of functionality.
For this work we moved to Sol to act as our engineering partner.
Instead of repeatedly rebuilding the application, we could work incrementally:
Try → observe → change → test → improve
The model that is useful when creating something from nothing isn't necessarily the model you need once the product exists.
Once we had something that worked, we also used Sol for some of the less visible work needed to turn the MVP into a sustainable product.
It created the requirements and design reference documentation, then helped us build the deployment pipeline and automated regression testing.
In other words, AI wasn't just helping us write the application. It was helping us create the engineering capability around it.
The progression looked like this:
Concept → Prompt → Build → Iterate → Document → Industrialise
Then AI became part of the product
There was one obvious opportunity to make the experience better: why ask somebody to type information from a receipt when the application could read it?
Our first approach used conventional OCR. It worked, but it quickly felt like yesterday's technology. Receipts are messy — different layouts, different fonts, and different ways of showing totals, VAT and dates — so we replaced it with an AI receipt-reading agent instead.
We used Sol to build the capability, but the job of the agent itself is deliberately very simple: look at this receipt and extract a defined set of information. The application checks the response and presents it back to the user to confirm.
This is where the multi-model approach becomes particularly interesting.
The model that builds it doesn't have to run it
We used Sol to design and build the receipt-reading capability, but we don't need Sol every time somebody photographs a £15 lunch receipt.
Once the problem has been understood and the task constrained properly, receipt reading becomes a much simpler and more predictable job. That means we can use smaller, faster models such as Luna and Terra to process the receipts.
That follows exactly the principle we explored in our earlier Insight, Solve with the strongest AI. Scale with the simplest.
Use the stronger model to solve the harder problem, then capture that thinking in the prompt, rules, validation and workflow so a simpler model can do the repeatable work.
The intelligence has been engineered into the solution.
One application. Different models. Different jobs.
Looking back, the models played very different roles. Astra helped create the first version. Sol became the engineering partner, refining the application, documenting it, testing it and industrialising it. Sol also helped design the AI capability inside the product, while Luna and Terra can handle the simpler production task of reading receipts.
That's quite different from simply saying, "We built an app with AI."
We used AI throughout the delivery lifecycle, choosing the model according to the work that needed doing.
A repeatable pattern
Wisereach Expenses is a small application, but that is partly why it is such a useful experiment.
The pattern is straightforward:
Start with the business problem → use AI to shape it → use the right model to build it → use AI to improve and industrialise it → then use simpler AI inside the solution where it adds value.
The next problem could be completely different. The approach doesn't have to be.
Perhaps the lesson is that organisations shouldn't spend too much time asking, "Which AI model should we choose?"
A better question may be:
Which AI capability do we need here, and what's the simplest model that can do that job well?
That's a much more practical way to start turning AI into working business solutions.
And one final thing...
Reading this back, it sounds like a fairly substantial delivery project: concept development, product design, MVP build, iteration, documentation, deployment automation, regression testing, AI agent design and production AI integration.
It would be reasonable to assume this took months, involved a delivery team and required a significant technology budget.
It didn't.
From the first idea to the working product took less than two weeks. And the AI tooling we used was on a £20-a-month tier.
That, for us, is the most interesting part of the experiment.
The real opportunity isn't simply that AI can help write code faster. It's that a very small team can now move from a real business problem to a working, documented, tested and AI-enabled product at a speed and cost that would previously have been difficult to imagine.
That changes the economics of experimentation. It means organisations can try more ideas, solve smaller problems that would never have justified a traditional project, and learn much faster from what actually works.