◆Strategy
Two companies deploy Claude for what looks like the same use case. One finishes in weeks. The other burns two quarters and stalls in review. The difference is almost never the model. It is six factors that get decided, or ignored, before anyone writes a line of code.
A Claude deployment that answers questions from a defined document set, for a defined group of users, with a defined escalation path, is a bounded engineering problem. A deployment that should "help the whole department work faster" is not. The single biggest cost driver we see is the distance between those two descriptions.
Complexity compounds in specific ways. Each additional user role adds an access-control decision. Each additional document type adds ingestion and citation work. Each additional action the system can take, drafting versus retrieving versus filing, adds a review step and a failure mode someone has to own. None of this is a reason to think small forever. It is a reason to sequence. A first release with one workflow, one user group, and one measurable outcome costs a fraction of a broad launch and produces the audit evidence that makes the second release cheaper.
The question to ask before any proposal: can we state, in one sentence, what the system does, for whom, and how we will know it worked? If the answer is no, the cost is not estimable yet, and any number attached to it is a guess.
Ask where the policy manual lives and you will usually get three answers: the intranet version, the shared drive version someone amended, and the PDF attached to an email in 2022. Retrieval systems surface whatever they are pointed at. If the source content is duplicated, stale, or unpermissioned, the project inherits a data-cleanup effort that nobody budgeted.
This work is not optional in a regulated setting. A RAG system that cites a superseded policy is worse than no system, because it produces confident wrong answers with a paper trail. The honest move is to assess content readiness before committing to a timeline: which repositories are authoritative, which documents have owners, which access rules already exist and can be mirrored. That assessment is cheap. Discovering the same problems in week six of a build is not.
Every system the deployment touches adds cost in a predictable way. Read-only access to a document store is straightforward. Reading from a case management system, writing drafts back into it, and respecting its permission model is a different tier of work. Count the connections before you count anything else, because each one carries authentication, error handling, and a security review.
Governance requirements work the same way, and they should be specified up front rather than retrofitted. An audit log that captures every query, retrieved source, and output. Citation on every answer so a reviewer can trace the claim to the document. A human review step for anything that leaves the building. An access-control map that mirrors existing entitlements. Each of these is a concrete deliverable with a concrete cost, and each is dramatically cheaper to build in than to bolt on after a compliance team declines to sign off.
This is why deployments designed to support frameworks like HIPAA or SR 11-7 cost more upfront and less overall. The retrofit path looks cheaper in the proposal and rarely is.
An eval set is a collection of real questions with known-good answers, scored before launch and re-scored after every change. Skipping it saves money on paper and removes your only evidence that the system works, which in a regulated environment means the deployment stalls at the review gate anyway. The cost of evaluation scales with the stakes of the use case, not the size of the model, and it should.
Change management is the other quiet casualty. A system nobody uses has a cost of everything and a return of nothing. Training the first user group, adjusting the workflow around the tool, and establishing who handles escalations are small line items that determine whether the larger ones pay off. Budget for them explicitly or watch adoption numbers explain where the money went.
Open-ended hourly billing puts every risk described above on the buyer. Unclear scope, messy data, and late governance requirements all convert directly into billable hours, and the vendor has no structural incentive to surface them early. The invoice grows precisely when the project goes sideways.
Fixed-scope engagements invert that. When the vendor commits to a defined deliverable and an agreed success criterion, the vendor absorbs the cost of poor estimation, which means the vendor is motivated to do the readiness work honestly before quoting. This is how we structure the Governed Pilot: fixed scope, an agreed success criterion, and if that criterion is not met, the client does not pay. The structure forces the hard scoping conversations to happen before the engagement, where they are cheap, instead of during it, where they are not.
We do not publish pricing, and any figure quoted before scope, data readiness, and governance load are assessed would be fiction. What we do publish is the method: a free Claude Readiness Assessment that puts real answers behind each of the six drivers before anyone commits to a number.
The cost of a Claude implementation is knowable, but only after the six drivers are scoped honestly. Insist on that scoping before any number, and prefer a structure where the vendor loses money when the estimate is wrong, because that is the only estimate you can trust.