How to Choose an LLM Provider Without Getting Burned

For genuine custom work in Australia, a small single-use-case deployment on cloud-hosted sovereign infrastructure runs roughly $25,000 to $60,000 to implement, a medium build with retrieval and one integration $60,000 to $120,000, and a large multi-use-case or on-premises enterprise deployment $120,000 to $280,000, plus infrastructure. If someone quotes $5,000 for a custom LLM, they are almost certainly configuring a prompt on top of an overseas API and reselling it. That can be a perfectly reasonable purchase, and if it suits your use case you should buy it knowingly rather than believe you are getting a bespoke system. What you are not getting is data sovereignty, model portability, or an asset you own. Ask what the price includes: data ingestion, evaluation, integration and support are where real cost sits.

Use both, in sequence. Discovery and scoping genuinely cannot be fixed-priced accurately, because nobody knows the state of your documents until they look at them. A short time-and-materials or fixed-fee discovery engagement is the honest structure there, and it should produce an architecture, an evaluation set and a costed build proposal you could take to another vendor. The build itself should then be fixed-price against that scope, because by then the unknowns are resolved and the vendor is the party best placed to carry delivery risk. Be wary of open-ended time and materials for the build phase: it rewards slow progress and leaves you carrying every estimate error. Equally, be wary of a fixed price quoted before anyone has seen your data, which usually means the vendor has priced in a large contingency or plans to argue about scope later.

No honest provider will guarantee that an LLM is correct one hundred per cent of the time, and a vendor who offers that is telling you they do not understand the technology. What is realistic, and what you should require, is a measured accuracy threshold on a defined evaluation set that gates production release. In practice that means: before the build, you and the provider agree on 200 to 500 real questions from your staff with known correct answers. The system is measured against that set on context precision, context recall, faithfulness and answer relevance. You agree thresholds in advance, and the final payment milestone depends on meeting them. This turns accuracy from a marketing adjective into a contractual test. It also gives you a regression suite for every future change to the system.

For sovereignty, what matters legally is where the data is processed and stored and which jurisdiction can compel access, not where the provider has an office. An Australian-owned integrator deploying onto a US-controlled platform does not give you sovereignty, and an offshore firm deploying entirely into ap-southeast-2 on infrastructure you control might. That said, an Australian provider matters practically in three ways. They are accountable under Australian law, including the Privacy Act and the Australian Consumer Law. They understand the regulatory context you actually operate in, whether that is OAIC guidance, APRA CPS 234 and CPS 230, the Information Security Manual, or the Voluntary AI Safety Standard. And support in your timezone matters enormously when a production system misbehaves at 9am Melbourne time and your vendor is asleep in California.

Compare them on four axes rather than on capability alone, because at the top end capability is closer than most vendors admit. First, sovereignty: open-weight models can run entirely inside your boundary, while an API wrapper sends your prompts to whoever holds the API. Second, unit economics: API costs scale linearly with usage forever, and a system that becomes genuinely useful becomes genuinely high-volume, which is where private hosting pulls ahead. Third, portability: you can move an open-weight deployment between providers and hardware, while a wrapper vendor sits between you and a model you could otherwise call yourself. Fourth, effort: an API wrapper genuinely is faster and cheaper to stand up. If your data is low-sensitivity, volumes are modest and you need something in a fortnight, the wrapper is the right answer, and we will say so.

Plan for four to seven months end to end and you will not be disappointed. Selection itself, from shortlist to signed contract, typically takes six to ten weeks including a paid proof of concept, and longer if procurement runs a formal tender or a panel process applies. Discovery and architecture take two to four weeks. The build for a first production use case usually runs eight to twelve weeks, including data ingestion, retrieval tuning, integration and evaluation against the agreed test set. Then allow three to four weeks for security review, user acceptance and a staged rollout, and longer if an IRAP assessment or an internal privacy impact assessment sits on the critical path. The single biggest schedule risk is not engineering. It is document access: getting the right people to grant the right permissions to the right repositories.