There has never been a worse time to choose an AI vendor on vibes. The demo economy is booming: a slick chat window, a canned prompt, a founder who can say "agentic" four times in a sentence. Underneath, most of what gets sold in India today is a thin layer over someone else's API - priced like engineering, delivered like a wrapper. When the underlying model changes, when a token bill triples, or when a regulator asks who owns the data, the wrapper has no answer.
This guide is written for the people who sign the contract: founders and executives in India and abroad deciding how to buy AI. It is deliberately even-handed. Renting is often the right call. Building is often overkill. The point is not to push you toward one - it is to give you a framework sharp enough that no vendor, ours included, can sell you the wrong thing.
Build vs rent: the decision that comes before every other one
Almost every AI project sits somewhere on a spectrum between renting and building. Renting means you consume a hosted model through an API and shape its behaviour with prompts, retrieval, and tooling. Building means you own the weights - you fine-tune, post-train, or train a model that becomes your asset, not your recurring bill. Both are legitimate engineering. Confusing one for the other is where money dies.
Rent when the task is generic, the volume is modest, the accuracy bar is forgiving, and speed to market beats everything. A support-triage bot, a first-draft content tool, an internal search assistant - a well-built retrieval layer over a frontier API will beat a bespoke model on both cost and calendar. You are buying capability you could never train yourself, and paying per use is honest pricing for that.
Build when the model itself is the moat. If your data is proprietary and your domain is narrow - clinical notes, aviation maintenance logs, Indian legal language, a fraud pattern only you can see - a smaller model you own can outperform a giant you rent, at a fraction of the inference cost and with none of the vendor lock-in. You build when latency, data residency, unit economics at scale, or IP ownership stop being nice-to-haves and start being the business.
Renting buys you capability. Building buys you an asset. Know which one you are actually paying for before you sign.
The honest middle
Most serious systems are hybrids: a rented frontier model for the hard reasoning, an owned small model for the high-volume, latency-sensitive, or privacy-bound path. The right partner does not evangelise one religion. They map your workload, run the numbers on both, and tell you where the line sits - including when the answer is "just rent it, you don't need us to train anything."
The questions that separate engineers from resellers
You do not need to be technical to expose a body-shop. You need the right questions and the discipline to listen for a straight answer versus a slide. Ask these in the first meeting.
- Do you own the weights? If we build a custom model, who holds the IP, and can we take it with us if we leave? A vendor that hesitates here is renting you something and calling it owned.
- Can you actually train and post-train, or only prompt? Ask what they have fine-tuned, on what hardware, with what data pipeline. "We do RAG" is retrieval, not training - both are valid, but they are not the same skill.
- How do you evaluate? This is the single most revealing question. Real teams have an eval harness: task-specific test sets, regression suites, human review, measurable accuracy and cost baselines. Demo-driven shops change the subject.
- What happens when the base model changes? Frontier APIs deprecate and shift behaviour constantly. Ask how they detect drift and protect your system from a silent regression.
- Where does our data live, and who can see it? Get specifics on residency, retention, and whether your data trains anyone else's model.
- What is your governance posture? SOC 2, ISO 27001, GDPR, HIPAA, India's DPDP Act - which apply to us, and can you show current evidence, not intentions?
Note the pattern: every question has a factual answer. Compliance certifications either exist or they don't. An eval harness either runs or it doesn't. If answers arrive as adjectives - "robust," "enterprise-grade," "cutting-edge" - you are being marketed to, not engineered for.
Governance and compliance: the part nobody demos
The demo never shows you the audit trail, and that is exactly where the risk lives. If you operate in healthcare, finance, or anywhere personal data flows, the certifications are not paperwork - they are the difference between a system you can defend and a breach you can't.
- SOC 2 (Type II especially) tells you the vendor has operating security controls a third party has audited over time, not just on paper.
- ISO 27001 signals a formal information-security management system - relevant for enterprise and cross-border deals.
- GDPR matters the moment any EU resident's data touches the system; HIPAA the moment US health data does.
- India's DPDP Act increasingly governs how Indian customer data is processed, stored, and consented - a competent Indian AI partner should raise this before you do.
You do not need every certification for every project. You need a vendor who can tell you precisely which ones apply to your use case and prove the ones that do. "We take security seriously" is not a control. An auditor's report is.
Red flags: how to spot a body-shop wearing an AI costume
The Indian services market is deep, talented, and - in AI specifically - flooded with firms rebranding generic staff augmentation as "GenAI transformation." A few tells surface fast.
- Demo-driven, eval-free. The whole pitch is a live demo and zero discussion of how quality is measured or defended in production. Demos are theatre; evals are engineering.
- Black-box delivery. You get an endpoint and no visibility into architecture, prompts, model choices, or costs. If you can't inspect it, you can't own it, and you can't fix it at 2am.
- Headcount pricing on an outcome problem. Billing purely by bodies-per-month, with no tie to accuracy, latency, or business metrics, optimises for staffing, not for solving your problem.
- No opinion on build vs rent. A partner who wants to train a custom model before understanding your volume and accuracy needs is selling their capacity, not your outcome.
- Buzzword density over specifics. If you can't get a straight answer on what runs where, who owns what, and how it's measured, the fog is the product.
Why engineering-led studios beat body-shops
The structural difference is incentive. A body-shop's product is billable hours, so its instinct is to maximise headcount and duration. An engineering-led studio's product is a working system, so its instinct is to minimise the moving parts and make the thing measurably good. Same market, opposite gravity.
Engineering-led shows up as small senior teams instead of large junior benches, evals and observability from day one, a documented architecture you could hand to another team, and a willingness to say "you don't need this." It is the difference between a partner who owns the outcome and a supplier who fills a rota. When people ask who builds custom LLMs in India, or where to find the best applied AI studio in Chennai, this is the real filter - not the logo wall, but whether the team can train, evaluate, and defend what they ship, and whether they'll tell you when not to build at all.
A body-shop sells you effort. An engineering-led studio sells you a system that works when they're not in the room. We don't rent AI. We engineer it.
Cost framing: rent looks cheap until it isn't
Renting has near-zero upfront cost and a per-token bill that scales linearly with usage - beautiful at pilot scale, brutal at production scale. Building has real upfront cost - data work, training, evaluation - and then near-marginal inference cost you control. The crossover is a volume question, not an ideology question.
Do the arithmetic honestly. Estimate monthly token volume at real usage, not demo usage. Price the rented path over 18-24 months, including the tax of re-engineering every time the base model shifts. Price the built path including the one-time investment amortised across that same window. Below the crossover, rent. Above it, owning the model often pays for itself and then keeps paying. A vendor who won't build this model with you - or who assumes their preferred answer before running it - is guessing with your budget.
How to shortlist without getting sold
Turn the framework into a process. It takes a week and saves quarters.
- Write the problem before you write the RFP: the task, the accuracy bar, the volume, the data sensitivity, the latency need. Vendors who reshape your problem to fit their offering reveal themselves immediately.
- Ask every shortlisted vendor the same six questions above, and score straight answers over confident ones.
- Request one real artefact: an eval report, an architecture diagram, or a reference where they can talk specifics - not just a testimonial.
- Run a small paid pilot with a defined success metric before any large commitment. Watch how they measure, not just what they ship.
- Confirm the exit: who owns the code, the model, and the data if you walk. Ownership you can't leave with isn't ownership.
If a partner comes through all five clearer than when they started - sharper on your build-vs-rent line, honest about where you shouldn't spend, able to show their evals - you've found engineers. That is the whole game. The best AI partner in India is not the one with the loudest demo; it's the one who'd rather be right about your problem than be hired for the wrong one.