Method
How we work.
Two weeks watching the work. A written report you can argue with. One thing built and tested against real jobs from your business. Then it is yours to keep.
01 · The method
What happens, week by week.
- 1
Weeks one and two – we watch.
A half-day workshop with the four to six people who run the work, then three to five shadowing sessions beside the people who do it — timing quotes, counting retypes, watching what happens when a supplier price is out of date. We take copies of twenty or thirty real jobs; they become the test set later.
- 2
End of week two – the report, then a 90-minute readout.
The report arrives before the meeting so you can read it without us in the room. Five to eight opportunities, ranked and scored, a recommendation, what we could not check, and a fixed quote for the top item. If the honest answer is to build nothing, that is what it says, and the diagnostic fee is the only money you spend.
- 3
Then we build one thing.
Fixed price, half up front. Before any code, we agree what “working” means in numbers, and you sign it — that number becomes the acceptance test, and the same number you refuse to pay on. Every week you see the software running on your own data. No status deck.
- 4
Then we measure.
Baseline during the two weeks, the same measure at 30 and 90 days after go-live. Developers using AI tools were 19% slower on real tasks and believed they were 20% faster — people cannot tell, so we count. If the number does not move, you get that in writing. metr.org ↗
- 5
Then we hand it over, and stay if you want us.
Working software, procedures, a walkthrough video per workflow, the test set, and a plan for when it goes wrong. The retainer is optional on 30 days’ notice — take it when the workflow touches customers or money, skip it when your system is stable.
02 · Testing
We test it like a new apprentice.
We take a hundred real jobs from your business and run them through. The output is a count, not a feeling: it got 84 right, here are the 16 it did not, and why each one failed. Then we fix those and run the lot again.
We keep the hundred. When something changes in six months, we can show you that nothing which used to work has stopped. And if it passes everything first go, the test was too easy, and we write a harder one.
100
real jobs from your business in every test set — the messy ones, on purpose. Kept for life, so every future change answers to them.
The technical version
For whoever reviews the work on your side. Checked 8 August 2026.
Error analysis comes first.
We read at least 100 traces of the real task, note each failure, group and count them. Fixes go in order of frequency, which is rarely the order in which they annoyed anyone. hamel.dev ↗
Graders are binary.
Every check is a written rule with a pass or a fail. One-to-five scores hide drift: two reviewers give a 3 for opposite reasons and the average looks stable.
Judges are validated against human labels.
Where a model grades another model, we label a sample by hand first and measure the judge against it. An unvalidated judge measures its own opinion. hamel.dev ↗
The regression suite runs in CI.
At least 100 examples: the core cases, one for every bug ever fixed, and the known edge cases. When a vendor ships a new model, the suite answers “did anything break?” in an afternoon. hamel.dev ↗
Retrieval is measured on its own.
Where the system looks something up first, the lookup is scored separately. Otherwise a wrong answer and a missing document look identical, and you spend a week fixing the wrong thing.
A suite that always passes is not a suite.
At 100% the examples are too easy. Around 70% is usually the suite doing real work — we will show you a failing test on handover day and explain why we left it there. hamel.dev ↗
03 · Data
Where your data goes.
Credentials are per client. API accounts, cloud and subscriptions are opened in your name and billed to you. Nothing of yours runs through a shared Westringia account.
The provider terms are the ones that matter. Anthropic's commercial terms say it may not train on customer content; anthropic.com ↗ OpenAI says API data is not used for training unless you opt in. developers.openai.com ↗ Contract terms can change; we re-read them when they do. Last checked 8 August 2026.
If personal information leaves the country, Australian Privacy Principle 8 applies and you stay accountable for the overseas recipient. oaic.gov.au ↗ You cannot contract that away — you can design so less has to leave, which is what we do. The services we use are named on our privacy page.
What we do not have: ISO 27001, SOC 2 or IRAP. If your procurement requires one, the honest answer today is no — better heard in the first conversation than the fourth.
04 · Ownership
You own all of it.
The code, in your repository.
From the first commit, under your organisation. You watch it get built and you keep the history.
The accounts and credentials.
Every key and subscription in your name, on your card. Removing us is a ten-minute permissions change.
Written procedures.
What it does, what it deliberately does not, and what to do when it stops — written for seven in the morning.
A walkthrough video per workflow.
Five to fifteen minutes of the real system doing the real job. New staff watch it instead of booking us.
The tests and labelled examples.
The part most suppliers keep. It lets the next person change things without breaking what works.
An exit plan, in every statement of work.
Written before the work starts: the accounts to transfer, the running costs without us, and the skills the next person needs.
If we get hit by a bus.
Fair question for a firm this size. Nothing we hold is needed to keep your system running — no Westringia runtime, no licence, no part only we can open. The real cost is a handover: a competent contractor and a fortnight with what we left behind, which is why the documentation is a deliverable with a price, not a favour at the end.
05 · Technical
For the person reviewing the work.
Skip this if you do not build software. It is here so your reviewer does not have to ask for it on a call.
Agent tools and MCP servers.
A model gets a few tools with narrow permissions — nothing reaches a customer without a human pressing the button. Shared systems sit behind a Model Context Protocol server.
Retrieval.
We start with the simplest approach that could work — keyword search over a good index often beats an embedding store — and test both rather than assume. The refresh schedule is documented, because a stale index fails confidently.
Model routing and fallback.
Different steps get different models, each with a second provider behind it, and the fallback is exercised in testing. Models retire on published schedules, so this is maintenance, not paranoia. developers.openai.com ↗
Observability.
Every run gets a trace ID; prompts and versions are logged with the output so a run can be reproduced months later. Without it, the first serious complaint is unanswerable.
Cost per task.
Quoted before the build, tracked after: tokens, retries, cache. A few cents a run is one proposition at ten runs a day and another at a thousand.
Where we stand with the model vendors.
We are an OpenAI Select Partner — OpenAI's recognition of firms with the experience to build and deliver AI well, with partner resources and early sight of platform changes. We hold no tier with anyone else, take no vendor commissions, and model choice still follows the job.
The next step
Tell us what's slow.
Describe the part of your week that takes too long. A person replies, usually the same day. The first call is free, runs about half an hour, and ends with a straight answer on whether anything is worth building.
Or email hello@westringia.com directly. No deck, no sales process.