At the end of my article about costs there's a promise: that I'd write a separate, unvarnished piece on the experiences and the risks. This is it. Search for getting an app built in India and you get two kinds of text. Vendor pages where everything sounds frictionless. And forum threads where somebody lost their money. Both are true. Neither side writes down what actually goes wrong when an engagement like this comes apart.
I founded CODT in 2017 and I run it from Gurugram. We've built for companies in more than ten countries since. A few of the reasons these projects fail really are about the country. They're rarely the ones your board raises.
Having an app built in India: the short answer
It works when three things are settled in the contract before the first line of code: where your system runs, which route outside engineers use to reach it, and what transfers to you at the end. With those three in writing, India is a question of where people sit. Without them, no price saves you.
What nobody puts in the proposal
Time zones get talked about the most and hurt the least. Gurugram is three and a half hours ahead of Zurich in summer, four and a half in winter. Our afternoon is your morning. Projects essentially never fail over that.
What they fail over is more mundane. A vendor quotes a fixed price on the first call. It sounds like decisiveness and it's the opposite. Anyone handing you a firm number in thirty minutes should be able to show what it rests on: which scope, which assumptions, which buffer. Without that, the number is either too high and you're paying for a risk that never materialises, or too low, and then the change list arrives.
The second classic is staffing. Senior profiles in the proposal, different people in the project. One uncomfortable question before you sign takes care of it: who exactly will work on my project, by name, and can I speak to that person before I sign? If the answer dodges, that's your answer.
Then there's communication, where I'd rather not be diplomatic, because this one is about my side of the table. Politeness can sound like agreement. "Yes" can mean "I understand what you want" rather than "I think that's feasible". So I insist that commitments end up in the ticket instead of staying in the call. A misunderstanding that only surfaces in review costs more than an awkward question on a Tuesday.
The three questions that decide it
These three will get you further in twenty minutes than any reference list. They test whether someone has had to answer them before.
| Question | What a serious answer looks like |
|---|---|
| Where does my system run? | In your own jurisdiction. Settled during scoping, as part of the architecture. |
| How do the engineers reach it? | Through a route you control: either a virtual desktop your team administers, or a single static IP address from our office that your team allow-lists and can close again at any time. Which of the two applies is agreed per engagement. |
| What transfers to me at the end? | 100% of the code, IP and infrastructure, in writing. No per-seat licence on something built for you. |
And the point that comes up first in Germany and Switzerland: no client code and no client data moves to India unless your contract explicitly authorises it. If the contract is silent, the answer is no. Where a transfer is agreed, it's covered by standard contractual clauses. We build with the GDPR and the revised Swiss FADP in mind, and EU or Swiss data residency is available on request.
What it looks like when it's done properly
An NDA is signed before the first technical conversation happens. Then the first workshop and a high-level estimate: free, and usually back within three business days.
The real starting point is a paid discovery sprint, one to two weeks, $2,900–4,900, credited in full against the build. It ends with a written scope, an architecture, a costed roadmap, and the list of what we've explicitly agreed not to build. The fixed price comes out of that document.
From a signed quote it's four to five business days until the team's first sprint. Every change goes through senior review. Our sales colleagues in Switzerland work in German and French; engineering runs in English. Swiss clients can contract under Swiss law as the governing law for disputes, which is a contracting option per engagement. CODT remains an Indian private limited company.
A system built in India that doesn't live in India
The most concrete rebuttal to "India is a data protection risk" is an architecture. We built LeadTrack AI, a multi-tenant platform for AI voice agents, from here; the client is in Melbourne and the data lives in AWS Sydney. More than 100,000 live calls have run through it since, the first call goes out in under 30 seconds, and qualified-lead conversion rose 38%.
Where software is built and where data lives are two separate decisions. Gurugram and Sydney sit in different columns of the same contract.
What it costs, and what the price isn't
A first production release from our app development practice runs from $30,000–55,000 for a lean MVP to $120,000–250,000+ for a complex platform, depending on scope. The breakdown with the real cost drivers is in the costs article, and you can sanity-check your own project with the app cost calculator. Indicative 2026 bands, not a quote; the fixed price comes after the paid discovery sprint.
Here's what I'll say even though it doesn't help sales: if price is your only criterion, you will find vendors in India who quote below us. Those offers exist, and sometimes they win against us. We're not the budget version of a European vendor; we're a senior team with an Indian cost structure. In year two you see the difference in how long a new engineer takes before they can touch your code safely.
When you shouldn't build it in India
If you need a throwaway prototype for a pitch in six weeks that nobody will touch afterwards: take the cheapest offer you can find. Seriously. A discovery sprint for something that will never reach production is a waste of your money, and I don't want to sell you one.
If your requirements come out of standing over a screen together rather than out of documents, and that needs someone in the room with you twice a week, take the studio in Zurich or Munich. We could win that project. You wouldn't be happy with it.
The third case is the one I see most often, and it has nothing to do with India: there's nobody on your side with half an hour a day for decisions. The team waits. The sprint board stops moving. The sprint gets paid for anyway. Postpone the start instead.
For everything in between, location is exactly what it should be: a question you answer once and then close. We've written it up in detail for Swiss companies, and worked through India versus Eastern Europe. If you'd rather talk about your own project, tell us what you're building. You'll get a clear read within one business day on whether we're the right partner for it.
