Gro Clinics
$116K
Monthly subscription revenue secured
78%
Consult to subscription conversion
17K
Out of sync records reconciled
AI Engineering
The systems your team actually runs on. Built, shipped, running in production.
We build the AI and the revenue system it runs on.
Most people we talk to have already tried this once. The pilot demoed well, then it stalled somewhere between the demo and the security review, on three questions nobody had answered: what happens when the model is wrong, who gets to see which data, and what it costs per month at real volume. We answer those three before we build anything.
What we build keeps working in production. Retrieval that answers from your own records and cites the source, so a person can check it. Agents that call your internal tools with the same access as the person asking, and nothing more. Pipelines that read the documents your team still opens by hand.
We have been building revenue systems for Australian companies for more than a decade, and we build on Claude every day. Plenty of firms will show you a model doing something clever. Far fewer will put one into production, inside your security rules, and still be answering for it a year later.
Businesses we build for
Trust and safety, answered first.
Most AI projects stall the day someone in IT asks where the data goes. We’d rather answer that here than in week six.
The next question usually comes from whoever runs the team it’s built for: is this here to replace us? No. We automate the re-keying, the chasing and the checking, so people get their day back for the work that needs a human.
Your CRM stays the one place your data lives. We access client platforms as authorised users under least privilege and revoke at project end. When a tool we build for you needs a working copy of some records, like the deal fields a forecast reads, that copy sits on a Neighbourhood server in Sydney, kept separate for each client. On written request, we delete or return it within 30 days of the engagement ending. When a client tool we build for you uses AI, we mint a dedicated API key, scoped to that tenant. Your data is not visible to any other client’s instance, and no client’s data is used to train or fine-tune any model.
Anything that acts on your behalf gets a written action policy first. Routine steps run and are logged, sensitive ones notify a person, and anything irreversible waits for a human to say go. Every run leaves a record, so when someone asks what the system did, you read the log. Hosting, subprocessors and the incident plan are on our Trust Centre.
What we build, and what each one fixes.
These are the six kinds of AI work we get asked for most. A project is usually one or two of them, and your statement of work spells out exactly what yours includes.
Document processing
Your team still opens licences, statements and contracts one at a time and types what’s in them into another system. We build the pipeline that reads them, sorts them and pulls the details out, and anything it isn’t sure about goes to a person to check.
Answers from your own records
When the answer is split across the CRM, a shared drive and someone’s inbox, people ask whoever has been there longest. We build a tool that answers from your own systems and shows the record each answer came from, so anyone can check it in a click.
AI that does the task in your tools
For the jobs where someone reads one screen and updates another. It can only see and do what the person asking is allowed to, and every step that changes something follows a written action policy.
Matching records across millions of rows
The same customer turns up five times under five spellings, so nobody trusts the count. We match records to the people they actually belong to, and if a source couldn’t be reached, we name it next to the number.
Reports that turn up on their own
Someone on your team spends hours each week pulling numbers from three places that never quite agree. We build one pipeline behind a scheduled digest that’s in the inbox before the day starts.
Keeping your systems in sync
The CRM says one thing, the portal another and the feed a third. We connect them so each system holds the same record of a customer, instead of its own partial copy.
What we built, and what it moved.
How we usually build it.
Most AI proposals tell you what the thing will do. Fewer say how it gets built, and that’s usually what decides whether it gets past your security review and whether it’s still working six months after launch.
This is roughly how we go about it. Think of it as the order we work in when we can, and every project bends it a bit. Some need all six steps, some only need two, and plenty start in the middle, often with cleaning up the records, because that’s where the last attempt got stuck. What your project includes gets agreed in your statement of work.
Scope Before anything gets built, we try to answer the three questions that usually stall a pilot at the security review.
- What happens when it’s wrong. We map the failure modes, what each one would cost you, and which ones need a person to catch them.
- Who can see what. Permissions set per person, from the access they already have in your systems.
- What it costs at real volume. Model and hosting costs worked out from your own document counts and query rates, where we can get them.
Data The model is usually the easy bit. Getting your records into a state it can answer from tends to be most of the work.
- One system wins for each field. Where your CRM and another system disagree, we agree with you which one is right and write it down.
- Chunking and index freshness, set on purpose. How a document is split and how often the index refreshes can change an answer more than the prompt does.
- Answers cite their source. Each answer links back to the record it came from, so a person can check it in a click.
Evals We write the eval set before the prompts. It’s the step most projects skip, and usually the gap between a good demo and something people keep using.
- Real cases, graded by your people. Pulled from your own work, including the ones that went wrong.
- A pass mark agreed up front. Good enough becomes a number for each type of case, before the first output.
- Production mistakes go back in. When it gets something wrong live, that case joins the eval set, so every later change gets tested against it.
Build Prompts get treated as code: versioned, reviewed, and given only the access they need.
- Prompts in the repo. Versioned alongside the code, and each change runs against the evals before it merges.
- Tools scoped to the person asking. Wherever the platform allows it, the agent inherits the user’s permissions instead of a broad service account.
- A written action policy. Routine steps run and get logged, sensitive ones notify a person, and anything irreversible waits for someone to approve it.
Launch Live to a small group first, with a review queue behind it and a way to roll it back.
- Small group, review queue. Anything below the confidence threshold goes to a person before it goes through.
- Every call logged. Input, output, latency, cost, and what a human changed.
- A rollback you can name. One switch back to the previous version, or to how the process ran before.
Upkeep Model versions change and so do your processes, and neither one sends you a heads up.
- Evals rerun on every change. A new model version, prompt or tool gets tested against the suite, and the result goes in the pull request.
- Cost per run, and per finished job. So you can see what the system costs against the work it actually does.
- Back to the first three questions. Every so often we check the answers from Scope still stand as your volume and your team change.
Bring us the process everyone in the building has learned to work around.
Book a callBuilt on Claude
We build on Claude, and we have done the training. Between us the team has completed roughly 75 courses on Anthropic Academy, and the people sitting that training are the same people who build your system. There is no layer between the two.
Most of our work runs on commercial Claude plans, with the Anthropic API behind the AI features inside the tools we build for you. Three judgements sit under every build, and we have made all three dozens of times already:
- Which model. The trade between how fast it answers, what it costs per run, and how hard the task actually is.
- Which plan. Commercial plans for the people doing the work, the API for the features running inside what we build you.
- Which pattern. Retrieval, an agent, a pipeline, or none of the three, which is a real answer and sometimes the right one.
Having those three settled before we start is why scoping opens on what these models are genuinely good at instead of on a demo, and why the build opens on an architecture we already know works. Shorter route from idea to something running, and far fewer of the expensive detours.
See what we build with it
Meet the engineers
-
Harry Spicer-ShortAI & Digital Strategist -
Natalia ZiarkowskaAI & Digital Strategist -
Sophie CostelloAI & Digital Strategist -
Trav WhiteHead of AI Engineering, Founder
A lot of AI pilots stall. Here’s how we get ours live.
Most of it comes down to four things we build in wherever the project allows.
- A review step. Anything the system isn’t confident about goes to a person to check before it goes through.
- A way back. A rollback to the previous version, or to how the process ran before.
- A named owner. Someone you know by name looking after it, on a scope we agree up front.
- A plan for when it’s wrong. The likely failure modes, what each would cost you, and which ones a person needs to catch.
The question is never whether the demo looks good. It is what the system does with the one document in a thousand it has never seen, and whether anyone notices.
We build for ASX listed companies, household names and operators running national networks. None of them handed that over on the strength of a demo. Most put us through their own security review before anything went live, and plenty of that work is still running years later.
“You go to them with a system that’s in shambles and needs to be replaced in less than two months, and it also has to stay live, and you did it. Neighbourhood will just never let you down. You just get it done.”
Kate Radley
Head of Digital Technology, Gro Clinics ANZ · Read the case study
We use AI heavily. Here is what it is allowed to do.
Who we build this for.
It suits companies past the experimenting stage. Financial services, property and construction, anyone regulated or just careful: enough volume that doing it by hand is costing real money, enough governance that somebody has to sign off, and a process everyone has learned to work around. That last one is usually where we start.
When we tell you not to build it.
Some of the better calls we have made on this were to talk someone out of it. Four things put a project in that column, and we would rather find them in the first conversation than in month three.
-
The volume is not there.
Under a few hundred of the thing a month, a person doing it by hand is cheaper and nobody will notice the difference. Build the report instead.
-
Nobody can say what right looks like.
If two of your people grade the same case differently, the eval set cannot exist yet. Settling that is often the whole win, and it does not need a model.
-
The process is about to change.
Automating something you are three months from replacing means paying to build it twice.
-
The real problem is the data.
A model sitting on top of wrong records gives you wrong answers faster, and with more confidence behind them.
Questions we get asked.
How do you guard against hallucination?
We build the checks in. Extractions are checked against the source document, anything the system is not sure about goes to a review queue instead of going through, and a person approves before the file moves. Every run is logged: what was read, what was extracted, and what a human changed.
Who takes responsibility when it gets something wrong?
We do, for the build. You do, for the decision it supports. That split is written into the scope up front, rather than worked out during an incident.
If we stop working with you, what happens to our data and how fast can we get it out?
We follow a formal off-boarding checklist: all access and API keys are revoked or rotated, and client data is deleted or returned within 30 days of engagement end on written request. On the way out you get the repository, the credentials, the documentation and the export path for anything we built on top.
Do we own what you build?
Yes. It is in the contract, not in the goodwill.
Who maintains this in a year?
Your team or ours, and we agree which before we build. If it is yours, handover includes the runbook, the documentation and the training. If it is ours, it is a stated monthly scope with a named person on it.
Will this replace my team?
No. The role changes shape: less re-keying and chasing, more of the work that needs a person.
Tell us what’s not working.
A few lines is enough. You will get a human reply within one business day. After a first call with Matt, one PM plans it and builds it.
Got it, there.
We will be back to you within one business day. Rather not wait? Pick a time with Matt below and skip the email round, or call 1300 71 61 41.