AI Product Engineering

Move AI from prototype to production.

We help product and engineering teams turn AI experiments into reliable capabilities — integrated with their application, their data, their infrastructure and the workflows their customers actually use.

The prototype worked. That is usually not the problem.

The problem is the distance between a demo that impresses a room and a capability your customers depend on — where the answers stay consistent, the cost is predictable, the latency is acceptable, the failure modes are understood, and somebody can explain why it produced a particular output last Tuesday.

That distance is engineering, not prompting. It is where most AI projects stall.

Where AI work usually gets stuck

• The proof of concept has not moved in three months
• It answers well in demos and badly on real inputs
• The same question returns different answers each time
• Retrieval returns the wrong passages, so the answer is wrong
• RAG works on a clean test set and not on the real corpus
• Nobody can say what it costs per user
• Responses are too slow for the interface they sit in
• Legal or security has not signed off on what leaves the building
• Everything is welded to one provider's API
• There is no way to tell whether a change made it better
• There is no logging, so failures cannot be reconstructed
• The data pipeline feeding it is fragile or manual
• It works standalone but is not integrated with the product
• It cannot handle the volume you are about to put through it

What production actually requires

How we work through it

1. 1Establish a baseline — Build an evaluation set from your real inputs and measure what you have now. Without this, every later change is guesswork.
2. 2Fix retrieval before touching the model — In most underperforming systems the model is fine and the context it receives is not.
3. 3Design the guardrails — What it must not do, what it must refuse, what needs a person, and what gets validated before it acts.
4. 4Instrument everything — Tracing, logging and cost attribution, so behaviour in production is explainable.
5. 5Integrate properly — Into your application, authentication, data model, CI and release process.
6. 6Tune cost and latency — Model selection, caching and context size, measured against the baseline.
7. 7Operate it — Monitoring, regression evaluation on changes, and a plan for provider outages and model deprecations.

Capabilities we bring

• LLM integration into existing applications and APIs
• Retrieval-augmented generation, vector and hybrid search, re-ranking
• AI assistants over your own documents, policies and product data
• Document intelligence — extraction, classification and structuring
• Predictive and recommendation models where the data supports them
• Multi-step orchestration and tool use, with explicit boundaries
• Evaluation frameworks and regression testing for AI behaviour
• Guardrails, output validation and refusal handling
• Observability, tracing and cost attribution
• MLOps, deployment and cloud infrastructure
• Security, access control and data-handling design

We ship and operate our own product

We do not only build software for clients. Ausvanta is our own compliance and operations platform for Australian NDIS providers — rostering, GPS time tracking, incident management, claiming and audit evidence. We designed it, built it, and continue to operate it for paying customers in a regulated sector. That means releases, uptime, support load and production incidents are our problem too, not just a handover document. See Ausvanta.

Who we usually do this for

Product and engineering teams inside Australian software companies, SaaS businesses and mid-market organisations that have built something with AI and now need it to be dependable. Often a team with strong engineers who have not yet had to run an AI system in production, or a technical founder who needs a second set of eyes on the architecture before committing to scale.

Where this sits in our services

• AI & Machine Learning — the underlying model, retrieval and data work
• Custom Software Development — the application the AI capability lives inside
• Quality Assurance — testing and regression practice, including for AI behaviour
• Cloud & DevOps — deployment, scaling, monitoring and cost visibility

Questions we get asked

How do you move an AI prototype into production?

The prototype usually proves the idea works on good inputs. Production is about everything else: what happens on bad inputs, how you know quality has not regressed, what it costs per request at real volume, how fast it responds, what it does when the provider is down, who can see what, and how you debug a wrong answer three weeks later. We start by building an evaluation set from your real data so there is a measurable baseline, then work on retrieval, guardrails, observability and cost — in that order, because each one makes the next measurable.

What is RAG?

Retrieval-augmented generation. Rather than relying on what a model learned during training, you search your own content for the passages relevant to a question and give them to the model along with the question. The model answers from that material. It is the standard way to make an assistant answer from your documentation, policies or product data, and it lets answers cite a source. Most RAG systems that disappoint are failing at the retrieval step, not at the model.

When should a company fine-tune an AI model?

Later than most people assume, and rarely as a first response to poor quality. Fine-tuning is genuinely useful for teaching a consistent output format, a specialist tone, or a classification task with plenty of labelled examples. It is the wrong tool for adding knowledge — that is what retrieval is for — and it creates ongoing work every time the base model changes. We would want to see that prompts, retrieval and workflow have been addressed first, with evaluation data showing where the remaining errors are.

How do you reduce hallucinations?

Mostly by changing what the model is asked to do. Give it the right source material through good retrieval; instruct it to answer only from that material and to say when it cannot; require citations so an unsupported claim is visible; constrain the output format so it cannot wander; validate the output against your own data before acting on it; and keep a person in the loop where being wrong carries a cost. Measurement matters as much as technique — without an evaluation set you cannot tell whether a change helped.

How do you control AI API costs?

Start by measuring cost per request and per user, which many teams are not tracking at all. Then: use a smaller model for the steps that do not need a larger one, cache repeated work, keep prompts and retrieved context tight rather than sending everything, batch where latency allows, and set hard spending limits with alerts. Prompt and context size is usually where the money goes, and it is usually reducible without hurting quality.

Are we locked into one model provider?

You do not have to be. We generally put an abstraction between your application and the provider so models can be swapped, compared and routed per task. That said, portability has a real cost and providers differ in genuine ways, so we treat it as a deliberate decision rather than a default. The important thing is that switching is an engineering task, not a rewrite.

Already live and not behaving? That is a different conversation — see AI Rescue & Optimisation →