When you should use Claude or GPT instead

We build on-premise AI infrastructure. This post is about when buying it would
be a mistake.

We are going to make an argument against our own product, because the
alternative — pretending every organisation needs what we sell — is how this
category loses the trust of the people evaluating it.

So here is the honest version, with the arithmetic.

The floor, in one number

Below roughly 90,000 queries a month, no on-premise deployment pays back
inside three years — including the cheapest one we build.

That figure comes from our own cost model, computed against our entry-tier
deployment at ₹8.1 lakh, and it ignores electricity and staff time. In other
words it is biased in favour of owning, and it still says no.

Modelled at 700 tokens per query, $4 per million tokens, ₹88/USD.

Put a real organisation against that. A team of twelve people, each asking
around 400 questions a month, spends about ₹1,200 a month on frontier API
access — roughly ₹43,000 over three years, against ₹8.1 lakh of hardware.

They should use Claude or GPT. We tell them so, and then we refer them out.

The five cases where cloud is the right answer

01 — Your volume is low and isn't growing

This is the arithmetic above, and it is not close. If your usage is a few
thousand queries a month and you have no credible reason to expect ten times
that within two years, metered access is simply cheaper — and it stays cheaper.

The nuance worth checking: growing usage changes the answer quickly. Volume
that doubles every six months crosses the floor faster than most teams expect,
and the fleet you would buy is cheaper today than the one you would buy later.
But growth you are hoping for is not growth you have. Model what you are
running now.

02 — You need capability only the frontier has

Frontier models are more capable than anything you can run on your own hardware,
and we are not going to tell you otherwise. On raw reasoning, they lead, and any
vendor claiming their mid-size open model matches them is either benchmarking
selectively or relying on you not to check.

There are workloads where that lead is the whole job:

• Novel reasoning with no documentary basis. Strategy work, open-ended
  analysis, problems whose answer is written down nowhere in your organisation.
  Retrieval has nothing to retrieve, so the architecture we would sell you adds
  nothing.
• Frontier-grade code generation. The gap between frontier and open models
  on hard programming tasks is real and currently large.
• Very long multi-step synthesis across unfamiliar domains, where the task
  is to hold a great deal of heterogeneous context and reason across it in a
  single pass.

If that describes your primary use case, buy the capability. You are paying for
the thing that is actually scarce in your workload.

03 — Nobody is going to own the infrastructure

Owned hardware needs an owner. Not a large team — but someone accountable for
patching, monitoring, capacity, and the phone call at 11pm when a node stops
answering.

That can be your platform team, or it can be us on a retainer. What it cannot be
is nobody. An unowned on-premise deployment degrades quietly: models drift out
of date, the index stops being refreshed, and eighteen months later you own
depreciating hardware running a system nobody trusts.

If you have no infrastructure function and no intention of acquiring one,
someone else's operations team is a genuine feature, and you should buy it.

04 — You don't yet know what you're building

Buying infrastructure is a commitment to a shape of workload. If you are still
establishing whether AI helps your organisation at all, that commitment is
premature — and, more importantly, it is unnecessary.

Prototype on cloud APIs. Find the two or three workflows that actually create
value. Measure what they consume. Then run the arithmetic, with real numbers
instead of projections.

We would rather you arrive with six months of usage data than with a budget and
an assumption. The conversation is better and the design is better.

05 — Your data has no confidentiality dimension

Much of the case for on-premise is about material that must not leave your
control — regulated data, privileged records, trade secrets, commercial terms.

If your workload runs on public information, published material, or data you
would be comfortable seeing on a competitor's screen, that entire argument does
not apply to you. What remains is the cost argument, and the cost argument is
settled by volume alone. See case 01.

What does not disqualify you

The list above is genuine, and it is also frequently over-applied. Four things
that people treat as disqualifying are not:

Being small. Our entry deployment is ₹8.1 lakh, not ₹80 lakh. A
fifty-person firm doing sustained document work clears the floor comfortably.
Size is not the variable — throughput is.

Not being regulated. The compliance argument is the loudest one in this
market, which leaves a lot of organisations assuming the rest doesn't concern
them. If your pricing model, formulations, client list or deal pipeline is the
business, confidentiality matters to you whether or not a regulator says so.

Not having a data science team. You need infrastructure ownership, not
research capability. Those are different functions, and most organisations
already have the first.

Your documents being a mess. Scanned PDFs, inconsistent naming, seven years
of email attachments — that is the normal condition of enterprise data, and
handling it is the work, not a prerequisite for starting it. "We should tidy our
data first" postpones the project indefinitely, because the tidying never
finishes.

The answer is usually a split

In practice most enterprises with a mature cloud estate land on neither
extreme. Regulated and high-volume work runs on-premise; overflow, experimental,
and frontier-capability work runs on cloud APIs.

That is a legitimate architecture rather than a fudge — but it is only safe if
the split is enforced in code rather than by staff discipline. A policy saying
"don't put client data in the cloud tool" is not a control. A model registry and
a privacy filter that make the sensitive path physically unable to reach an
external endpoint is.

If a vendor offers you a hybrid design and cannot show you where that boundary
is enforced, the hybrid is a diagram, not an architecture.

A ten-minute self-check

Four questions. Honest answers only.

1. What is our actual monthly query volume? Not projected. If it is under
   about 90,000, stop here — the arithmetic has decided.
2. How much of our valuable work depends on documents or records only we
   have? If the answer is "most of it", retrieval architecture is your
   constraint. If it is "almost none", it isn't.
3. Would we be comfortable if this material appeared on a competitor's
   screen? If yes, the confidentiality argument does not apply to you.
4. Who would own the hardware on a Tuesday night? If there is no name, fix
   that before buying anything.

If you answered low volume, public data, no owner — use Claude or GPT. You
will get more value faster, and you will not be carrying an asset that needs
justifying.

Why we publish this

Because the alternative is worse for us.

The fastest way to lose a technical buyer is to answer a legitimate objection
with a sales line. Every evaluator in this market has sat through a pitch where
every question had the same answer, and they discount everything that follows.

We would rather be the vendor whose disqualification criteria are published, so
that when we do say yes, this fits, the statement carries information.

We have walked away from build engagements where the right answer was a
pure-cloud setup or a different partner. Advisory credibility outlasts any
single contract — and a buyer who was told the truth once tends to call back.

Want to check the arithmetic on your own numbers? Our cost model is open —
enter your query volume, average context length, and the deployment you would
need, and it will tell you where, or whether, the crossover falls.

Think you're above the floor? A one-day Discovery Sprint produces a written
recommendation for your specific workloads, including the recommendation not to
proceed.