Practical notes from the engineers who build agents, copilots and AI products.
Text to SQL solution projects fail for five reasons, and none of them is model quality: metrics with no agreed definition, a demo schema that is not the production schema, permissions enforced in the prompt, no evaluation suite to catch regressions, and a launch to everyone at once.
Six weeks is enough to launch a real AI product if scope is locked on day five. Here is the week-by-week plan, exactly what ships, what waits for v1.1, and what it costs in INR and USD.
The hidden costs of a text to SQL solution are semantic layer maintenance, evaluation and regression runs, warehouse compute from generated queries, access control work, and retraining people when the schema changes. Budget 20 to 35 per cent of the build price every year for them, on top of model usage.
Startups and enterprises build the same text to SQL solution differently in four places: scope, governance, security and integration depth. A startup ships forty questions over one schema in eight weeks from $12,500 or ₹8 lakh. An enterprise spends most of its budget on governance and takes twelve to sixteen weeks.
Ask a text to SQL solution vendor how they measure accuracy, who writes and owns the semantic layer, what happens when your schema changes, who pays for model and warehouse usage, and what you keep if you leave. Vague answers to those five are the reliable signal.
A text to SQL solution built in India costs ₹8 lakh to ₹25.6 lakh, or $12,500 to $38,500, for a production deployment across two or three data domains. Delivery model, warehouse readiness and residency requirements move the figure more than the city your partner sits in.
Measure a text to SQL solution on three layers: execution accuracy against a golden question set, trust signals such as refusal rate and repeat usage, and the business outcome the system was funded for. Report one headline number, verified answer rate, with the other layers underneath it.
Buy a text to SQL solution when your data lives in one BI platform, your metrics are already defined there and fewer than fifty people will ask questions. Build when questions cross systems, permissions are complex or the answers go to customers. Most organisations end up doing both.
A text to SQL solution can be DPDP-compliant, but only by design. The Act cares about four things your architecture decides: where processing happens, which rows the asker may see, what the logs keep, and whether the purpose was stated. Get those right and the risk is no worse than your existing BI tool.