Most custom software projects fail not because of bad engineering. They fail because of bad scoping.
We've seen it repeatedly — businesses spend 10-20 lakhs on a custom platform, and 6 months later the team has gone back to Excel and WhatsApp. The software exists. Nobody uses it.
Here are the three questions we ask every potential client before we agree to take a project.
Question 1: Who specifically will use this, and what are they doing today?
Not "the sales team." Not "our operations." A specific person: "Ravi, our sales manager, currently spends 3 hours a day manually copying data from our WhatsApp into a Google Sheet to track leads."
If you can describe the person and the manual process they're replacing, we can build software that actually helps them. If you can't, we're probably going to build something that looks impressive in a demo and collects dust in production.
The goal is never "digital transformation." The goal is making Ravi's 3 hours into 20 minutes.
Question 2: What does success look like in 90 days — in one sentence?
Not a list of features. One measurable sentence.
"Our sales team responds to every lead within 5 minutes instead of 4 hours."
"Our operations team processes 200 orders a day instead of 80."
"Our clinic has zero double-bookings."
If a client can't answer this, we help them figure it out before we start. Because without a clear success metric, the project scope will expand infinitely and nobody will ever agree that it's done.
Question 3: Who will maintain this after we build it?
This one kills more projects than anything else.
Custom software is not a one-time purchase. It's a living system that needs updates, bug fixes, and new features as your business evolves. If there's no plan for who maintains it — internal team, retainer with us, or another vendor — the software will slowly break and eventually be abandoned.
We'd rather have this conversation before a project starts than 8 months in when the client is frustrated and we're doing emergency fixes.
Why we turn down projects
We turn down roughly 30% of inbound projects. Usually because the answers to these three questions reveal that the client isn't ready to build software yet — they need to fix a process problem first.
That's not a criticism. It's just that software can't fix a broken process. It will just automate the chaos and make it worse faster.
The best projects we've worked on started with a client who knew exactly what pain they were solving, who would use the solution, and how they'd know it was working.
Those projects ship on time, within budget, and actually get used.