If you run a business in India and you’ve been quoted for custom software, you’ve probably had the same sinking feeling. One agency says ₹2 lakh. Another says ₹15 lakh. A third won’t give you a number at all until you sit through a “discovery call.” None of them will tell you plainly what you get for the money, and every one of them wants a large payment before anything exists.
So you do the sensible thing and you don’t build it. You keep running the business on spreadsheets and WhatsApp, because at least those don’t have a five-figure invoice attached to a promise you can’t verify.
That’s a reasonable fear. Custom software does become a money pit, often. But it doesn’t have to, and the difference between a build that works and a build that bleeds you dry has almost nothing to do with the technology. It comes down to how the deal is structured. Here is how to structure it so you don’t get burned.
Why custom software becomes a money pit
Three things turn a software project into a runaway cost. Nearly every horror story you’ve heard involves at least one of them.
1. The scope was never written down
Most projects are agreed in conversation. “We’ll build you a system to track deliveries.” Everyone nods. Nobody writes down what “track deliveries” actually means — how many screens, which reports, who logs in, what happens on a phone versus a desktop. Three weeks in, your idea of the system and the developer’s idea have quietly drifted apart, and the gap between them becomes “extra work” that costs extra money.
The fix is boring and it works: a written scope, listing every feature, agreed before anyone writes code. If a feature isn’t on the list, it isn’t in the price — and you both know that going in, instead of arguing about it later.
2. You’re billed by the hour
Hourly billing puts you and the developer on opposite sides. Every hour the project takes is an hour you pay for and an hour they earn from. When something goes wrong — and something always goes wrong — the cost of fixing it lands on you. You have no way to know whether a task genuinely took twenty hours or whether it was padded, because you can’t see the work.
A fixed price against a fixed scope flips the incentive. Now the developer carries the risk of the estimate. If they’re slow, that’s their problem, not your invoice. You know the total on day one, and it doesn’t move unless you change the scope.
3. You pay for the whole thing before you see any of it
This is the big one. The standard deal asks for 50% upfront and the rest on delivery, for a system you have never seen and cannot picture. You’re not buying software. You’re buying a promise, secured with your cash, from someone you met last week.
The fix is to never pay in full for something you haven’t seen running. There are two ways to arrange that, and we’ll cover both.
How to structure the deal so you’re protected
Insist on a demo first
The single most powerful thing you can ask for is a working demo built with your own data, before you commit to the full build. Not a slideshow. Not a mockup. A thing you can click, showing your actual outlets, your actual routes, your actual numbers.
A demo does two things. It proves the developer can actually build — anyone can talk, far fewer can ship. And it collapses the biggest risk in the whole process, which is that you and the developer imagined two different systems. Once you’ve clicked through a real demo, there’s no ambiguity left about what you’re buying.
If a developer won’t build a demo, ask yourself why. Usually it’s because a demo is real work and they’d rather lock in your deposit first. That reluctance is information.
Break it into phases
Don’t commission the whole system at once. Break it into phases, and make the first one small — one team, one route, one process. Pay for that phase, watch it work in your real operation for a few weeks, and only then commission the next.
Phasing caps your risk. At any moment, the most you can lose is the phase you’re currently in, not the entire project budget. It also means the software earns its keep before you spend more — if phase one doesn’t pay for itself, you’ve learned that cheaply, and you stop.
Tie payments to things you can see
Structure the payments around delivered, visible milestones, not calendar dates or “progress.” A payment schedule like deposit on scope sign-off, balance when the phase is running in your business keeps the developer’s incentive aligned with yours: they get paid when you get something that works, not before.
What it actually costs in India
Here’s the honest picture, because most guides bury it under a range so wide it’s useless.
You’ll see figures quoted anywhere from ₹1.5 lakh to over ₹1 crore. That range is real, but it’s meaningless for you, because it spans a two-person shop’s first tool and a bank’s enterprise platform. For a small or mid-sized business automating one genuine workflow — a delivery tracker, an inventory system, a dashboard that pulls your real numbers into one screen — a focused first build typically lands in the low lakhs, not the tens of lakhs. You scale spend later, as the system proves itself and you add to it.
What actually moves that number is not the count of features. It’s complexity, and above all integrations — how many other systems your software has to talk to. A tool that stands alone is cheap. A tool that has to read your existing invoicing software, sync with your accounting, and push updates to WhatsApp is a bigger job, because each of those connections is a small project of its own. When you get a quote, the honest question to ask is not “how many features” but “what does this have to connect to, and has anyone confirmed those connections are possible?” Surprises there are the most common cause of budget overruns.
Questions to ask before you sign anything
Take these to any developer or agency you’re considering. The answers tell you almost everything.
- Will you build a working demo with my data before I commit? If no, walk.
- Is the price fixed, and can I see the scope it’s fixed against? If they only bill hourly, your costs are open-ended.
- Can we start with one small phase instead of the whole system? If they insist on the full build upfront, your risk is the full build.
- What does this software need to connect to, and have you confirmed those connections work? Unconfirmed integrations are where budgets die.
- When I’ve paid in full, do I own the code? You should. Get it in writing.
- What happens if I’m not happy? A confident builder has a clear answer. A vague one has a vague answer.
The bottom line
Custom software is not inherently risky. Badly-structured software deals are risky. The technology is rarely what sinks a project — the structure is. Demand a demo before you commit, a fixed price against a written scope, and small phases you can stop after. Do that, and the money-pit scenario mostly disappears, because you never have more at stake than a single phase you’ve seen working with your own eyes.
That’s not a sales trick. It’s just the only sensible way to buy something you can’t hold in your hands.