AI that earns its place in the product
LLM features built into software where they replace real work or surface something specific a person would have missed — not a chat window nobody asked for.
The bar for shipping an AI feature
Most “AI features” are decoration: a chatbot in the sidebar, a summarise button nobody presses, generic advice that could apply to anyone. The test we apply is simple — would a person actually miss this if we removed it? If the honest answer is no, it doesn’t ship.
Where AI does earn its place, it’s usually one of three things:
- Turning something a person writes in plain English into a structured draft they’d otherwise type by hand
- Reading a user’s own data and flagging the specific thing worth acting on, not a generic tip
- Pulling signal out of volume — patterns across sessions, records or transactions no one has time to read
What building it in actually involves
Adding AI is not a plugin. What makes it hold up in production is the work around the model:
- Prompting built and tested against your real data, not a demo dataset
- Structured output, so downstream code gets fields it can rely on rather than free-form prose
- Per-user data scope — the model only sees what that user is entitled to see
- Human-in-the-loop by default: AI produces a draft or a suggestion, a person makes the call
- Cost and latency measured before launch, so you know what running it costs at your volume
Proof it ships
Notara started as an AI-assisted NDIS documentation platform — support workers describe a shift in plain English, and it generates draft case notes, incident reports and progress notes, flagged for human review. We designed, built and deployed it: authentication, Stripe subscriptions, Claude API integration, sensitive-data handling and a database structured around a regulated-adjacent domain.
We’ve since shipped AI features into a personal finance planner and a GAMSAT prep platform — in both cases built from the user’s own data rather than generic advice.
Common questions
What does AI integration actually involve?
Working out where a language model genuinely beats the current process, then building it in properly — prompting tested against your real data, structured output your code can depend on, per-user data scoping, and a human reviewing anything consequential before it’s acted on. The model is the easy part; the constraints around it are the work.
Do we need our own AI model?
Almost never. Most products are best served by an established model accessed through an API, with the value coming from your data and the constraints you put around it. Training or fine-tuning a model is worth discussing only once a specific limitation of the off-the-shelf option is blocking you.
Who owns the code and the accounts at the end?
You do. The repository is in your organisation’s name, hosting and API accounts are registered to your business, and the handover includes documentation another developer can pick up without calling us.
Tell us what you’re trying to build
From a rough idea or a written brief — either is fine. A 30-minute call, no charge, and a realistic view of what it would take.
Book a call