Service 04
When off-the-shelf won't cut it, we build it.
AI Architecture & Builds
AI architecture is the foundation layer that decides whether AI in your business is a feature or a permanent capability: where the data lives, how systems talk to each other, how models are accessed and governed, and what the software on top looks like. We design that layer and build the software that sits on it.
Engineers, not slide decks
We have spent more than fifteen years shipping commercial software that Australian businesses run their operations on: enterprise ERP, e-signature platforms, automation for managed service providers. The systems that consultancies recommend are the kind we have built and supported.
That background shows up in unglamorous ways. We are conservative about dependencies. We assume a system will be maintained by someone who was not in the room when it was designed. We treat error handling, observability and the migration path as part of the build rather than a phase that gets cut. And we scope for the version that survives three years, not the one that demos well in six weeks.
The four layers we work across
Data and integration
Getting information out of the systems it is trapped in, and into a shape something can act on. Usually the least visible and most valuable part of the work. Where a system has a supported API we use it; where it does not, we build a defensible boundary rather than an integration that breaks on the vendor's next release.
Knowledge and retrieval
Where AI needs to reason over your policies, contracts, procedures and history, that content needs to be reachable, current and permission-aware. Retrieval done properly is mostly an information architecture problem, not a vector database problem.
The model layer
How models are accessed, which workloads use which model, how prompts and behaviour are versioned, how cost is controlled, and how the whole thing is logged. Designed so the provider underneath can change without rewriting the business logic above it.
Applications
The software people touch: internal tools, operations dashboards, customer-facing applications, and the approval interfaces that make human oversight practical rather than theoretical.
Custom software with AI designed in
Not everything we build is an AI system. A meaningful share of our work is straightforward custom software for businesses whose operation does not fit what the market sells: a job management tool for an unusual delivery model, a portal that replaces a fortnightly spreadsheet exchange, an internal system that finally connects two departments.
What is different is that we design these with AI as a first-class input rather than something bolted on in version two. That mostly means structural decisions: capturing data in a form a model can reason over, building the action surface as callable tools from the start, and putting approval and audit in the foundation rather than retrofitting them after a governance review.
- Internal tools and operations dashboards
- Customer and supplier portals
- Integration middleware between systems that were never designed to meet
- Document generation and processing pipelines
- Approval, exception and audit interfaces for the automation around them
What is yours, and what it costs to run
Your data is yours, and so is the business knowledge underneath it: how your operation runs, the rules, the exceptions, the judgement we encoded. None of that becomes ours because we automated part of it, and none of it is held hostage.
The system itself normally runs as a hosted service. An ongoing agreement covers the running of it: hosting, model usage, the third-party subscriptions the workflow depends on, and support. Those costs exist whoever carries them, and we would rather put them on the table than imply a production system runs for nothing.
What you get either way is a system that is not opaque to you: plain-English documentation of what it does and why, a runbook, and enough architectural context that your team can hold an informed conversation about it with anyone, us included.
Ask early
Commercial terms, including anything about the code itself, are set out per engagement rather than by a blanket policy, and they are worth settling before a build starts rather than after. Raise it in discovery and we will put the answer for your system in writing.
What you get
- A reference architecture for how AI is accessed and governed across the business
- Integration layer between the systems that currently cannot talk to each other
- Custom applications: internal tools, customer-facing apps, or both
- Retrieval and knowledge infrastructure where the work demands it
- Deployment, monitoring and cost controls
- Full source, documentation and a handover that assumes we leave
Best fit when
- Businesses where the off-the-shelf option would mean changing how the business works
- Operations held together by spreadsheets and manual transfer between systems
- Organisations wanting the AI capability as an owned asset rather than a subscription
Frequently asked questions
Should we buy a platform or build something custom?
Buy, wherever a product fits. It will almost always be cheaper and better supported. Build when the off-the-shelf option would require you to change how the business works, when the process is the actual differentiator, or when the annual licence cost across your team exceeds what owning it outright would have been. We will tell you which of those applies, including when the answer costs us the build.
What technologies do you build on?
Mainstream, well-supported, boring-on-purpose choices: TypeScript, Python, React and Next.js, Postgres, and the major cloud platforms. We build primarily on Anthropic's Claude for model work. The test we apply is whether another competent engineer could pick the system up in a week.
Can you work with our existing codebase?
Yes. A good share of the work is extending or integrating with systems that already exist rather than starting from nothing. We will review what is there and be straight with you about whether extending or replacing is the better economics.
What happens after the build?
You choose. Full handover and you run it, an optional support retainer, or an ongoing arrangement where we keep extending it. All three are normal, and the handover documentation is the same in every case.
More questions answered on the full FAQ.
Read next
When off-the-shelf won't cut it, we build it.
Tell us about the process you'd point this at. Thirty minutes, no preparation, and a straight answer on whether AI Architecture & Builds is the right first move, or whether something else on the list is.