How do you choose an AI implementation partner?
Working out how to choose an AI implementation partner is mostly a matter of asking questions whose answers cannot be improvised, then noticing who gets specific and who gets warm. Nine questions do the job. They take twenty minutes, they require no technical knowledge, and they will separate people who build production systems from people who assemble demonstrations.
Use them on everyone you speak to. Use them on us. A supplier who is irritated by them has answered a tenth question you did not have to ask.
What are the nine questions?
Ask these nine in this order, write down the answers verbatim, and compare them later against the proposal.
One. What exactly will this do, in one sentence a stranger would understand? Vagueness at this stage never improves later.
Two. What will it never do? A builder who has thought about failure has a ready list. A reseller has not considered the question.
Three. Which numbers must move, and who measures them? If success is described in adjectives, there is no test to pass.
Four. Whose accounts does it run in? It should be yours. If your supplier vanished tomorrow, the machine should keep working.
Five. What is the price, fixed, before we start? Hourly billing on a build puts your interests against theirs.
Six. What does the monthly fee actually produce? Monitoring and tuning against a stated standard, or it is a subscription to hope.
Seven. Where does our data go, and is it used for training? Provider, region, and terms, in writing.
Eight. What happens when it is wrong? There should be an answer that does not begin with an invoice.
Nine. What happens if it does not work at all? Ask what you owe in that case, and get it written down.
Which answers should end the conversation?
Four answers are disqualifying, and you should treat them as such regardless of how much you like the person giving them.
"It is all secure" instead of a provider, a region and a contract term. "We will scope it as we go" instead of a fixed price. "It runs on our platform" when you asked who owns the accounts. And any version of "you will be left behind" when you asked about value, because fear-selling is what people reach for when the numbers are not on their side.
None of these are technical judgements. They are the same judgements you would make about a builder quoting on an extension.
Does industry experience matter more than AI experience?
Both matter, but production experience matters most, and it is the one people forget to test for.
A demonstration is a party trick. A machine that runs unattended for months without anybody noticing it is a product, and the difference lives entirely in unglamorous places: monitoring, fallbacks, logs, what happens when a third-party system is down at two in the morning. Ask what they have running in production today and how they find out when it breaks. The answer tells you more than any case study.
Industry knowledge is useful mainly because it shortens the drawings stage. But a builder who listens well and maps your process honestly will beat a specialist who arrives with a template and bends your business to fit it.
How do you test a supplier before committing?
Ask to see something working on your business rather than on theirs.
This is the fairest test available and it costs you nothing but a meeting. A demonstration built on someone else's staged data proves only that the demo works. A demonstration built on your services, your prices and your voice proves that they understood you, which is the thing actually in question.
We show a working demonstration on the client's own business inside the first week, before anything past the pilot is committed, and we think it should be the standard rather than a differentiator. You can also play with two of the crew on a staged business right now, which is a lower-commitment way to judge whether the work is any good.
What should the engagement look like on paper?
Drawings first, fixed price, build beside existing systems, live supervised, verdict in thirty days.
That is the whole shape and it should be recognisable in any good proposal. Specifically: a written definition of done before building, a price agreed in advance in writing, work built alongside the tools you already use rather than replacing them, human approval gates for as long as you want them, and a one-page report of numbers against target thirty days after go-live.
Our method sets that out in detail, and the house behind this work explains where the habits came from, which is a decade of fixed-price building rather than a decade of AI. If a proposal you are reading is missing two or more of those five, ask why before you ask about price.
What about price transparency?
A partner who will not indicate price before a discovery call is managing you, and it is fair to say so.
There are honest reasons for scoping some work rather than listing it. Complex builds over a client's own documents genuinely vary. But an entry-level engagement can carry a published number, and we publish ours: $1,950 setup and $295 a month for a first lead machine, with wider workflow builds scoped from $4,950 and $495 a month. Larger data work is priced per pilot and we say that plainly instead of hiding it behind a form.
You do not need a firm quote before the first meeting. You do need to know whether you are in the right order of magnitude, and anyone unwilling to tell you that is spending your time deliberately.
Where to look next
What we build is organised by problem rather than by technology, which is a reasonable way to check whether a supplier is thinking about your business or about their stack. The crew shows what a single well-bounded machine looks like when it is finished.
For neutral ground, the Australian Government's AI Ethics Principles give you a governance checklist to hold any partner to, and business.gov.au lists current adoption support.
When you are ready to run the nine questions on somebody, we are happy to go first.