Custom Software Development Cost in India: Real Numbers from Client Projects
Here is a situation that happens far more often than the software industry admits: a founder hires a developer, pays a deposit, watches a few demos, and then one day the developer is unreachable. Or they send a resignation message. Or they announce they are going freelance and are “wrapping things up.” The codebase is 60% done. The business depends on it going live. And suddenly the founder is staring at a GitHub repository they cannot read, trying to figure out what to do next.
The same thing happens inside companies. A CTO or internal lead developer quits mid-project. The incoming person inherits a codebase that was never properly documented, built by someone who kept everything in their head. The organization has already spent budget. The deadline is approaching. And no one is entirely sure what actually works.
These situations are not rare. According to the Standish Group’s CHAOS Report 2024, 19% of software projects are outright cancelled or abandoned before delivery, and a further 52% are “challenged” — late, over budget, or missing key features. A Harvard Business Review analysis found that large IT projects run on average 27% over budget, with some exceeding original estimates by more than 200%. The failure is not always dramatic. It often arrives quietly, in the form of a developer who stops responding, a codebase that “needs a bit more time,” and eventually, a business that has spent months and money on something that does not work.
This guide is for the people left holding the problem. Not developers — business owners, founders, operations leads, CTOs who have just inherited a broken or stalled project and need to understand their options, their costs, and the first three calls they should make.
Why This Happens — and Why It Is Not Always the Developer’s Fault
The instinct, when a developer leaves a project unfinished, is to look for someone to blame. That instinct is understandable. It is also usually not very useful.
There are genuinely bad actors in software development — freelancers who take payment and disappear, agencies that overpromise and underdeliver, contractors who simply do not have the skills they claimed. Those situations exist and they are worth being angry about.
But the more common scenario is subtler. The Standish Group identifies the top causes of software project failure as unclear requirements (39%), scope creep (33%), inadequate planning (29%), and communication breakdowns (25%). Technical failure — which most people assume is the culprit — ranks last at 17%. Most projects fail because of people and process problems, not because the developer was incompetent.
What this means practically: when a developer leaves an unfinished project, the reasons are usually some combination of the following.
- The original requirements were underspecified. The developer built what was described, not what was needed, and the gap only became visible late in the process.
- Scope grew without a corresponding adjustment in timeline or budget. The developer kept adding to the work without anyone formally agreeing to extend the engagement.
- The relationship broke down. Developers, like any professional, sometimes reach a point where they decide the engagement is not working and walk away.
- The project was more complex than anyone estimated at the start. This is extremely common with custom software. What looks like a three-month project in a requirements document often turns out to be a six-month project in execution.
None of this is meant to excuse poor behavior. It is meant to orient you toward what actually matters: not who was at fault, but what you have, what it will take to finish, and who can do it.
Most software projects fail because of people and process problems, not because the code was bad. The Standish Group identifies unclear requirements and scope creep as the top causes — technical failure ranks last.
The First 72 Hours: What You Actually Need to Do
There is a short window after a developer leaves where the actions you take determine how much the situation costs you — in time, money, and stress. Here is what to do immediately.
Secure Access to Everything
Before anything else, collect and verify that you control access to every system involved in the project. This means the repository (GitHub, GitLab, Bitbucket, or wherever the code lives), the hosting environment, the domain and DNS settings, any third-party API keys or service accounts the developer set up, and any cloud infrastructure like AWS, Azure, or Google Cloud.
This step sounds obvious. It is frequently overlooked. Developers often set up services under their own personal accounts as a shortcut. When they leave, access goes with them. If the relationship ended badly, you may find that access is actively revoked.
If the developer is still reachable, request all credentials and access transfers in writing, via email. If they are not reachable, begin the account recovery process with each service provider immediately. Cloud providers have formal processes for transferring ownership — they take time, so start early.
Get the Code — All of It
Request a complete export of the current codebase, including all branches, not just the main or production branch. Also request any database schemas, environment configuration files, API documentation, and any design files that exist.
If the developer used a version control system properly, you will be able to see the history of every change made, which is extremely useful for whoever takes the project over. If they did not use version control properly — and many solo developers and small shops do not — you may only have the files as they exist at the moment of departure.
Do not be alarmed if what you receive looks like an impenetrable mass of folders and files. A competent technical reviewer can make sense of it. What matters at this stage is that you have it.
Do Not Touch It Yet
This is counterintuitive, but important. The moment you start making changes to the codebase without understanding it, you risk compounding whatever problems already exist. Even well-intentioned tweaks can break dependencies, overwrite work in progress, or obscure what was there before.
Your goal in the first 72 hours is to secure and inventory, not to fix. The fixing comes after a proper technical review.
What Service You Actually Need — and What to Call It
One of the most disorienting parts of this situation is not knowing what to ask for. If you call a software company and say “my developer left and my project is unfinished,” you will get very different responses depending on who picks up the phone. Understanding the service categories will help you find the right vendor faster.
Application Management and Support
This is the service you need if your software exists in a functioning or partially functioning state and you need a team to take ownership of it, stabilize it, fix bugs, and continue development. Application Management and Support covers taking over an existing codebase from a previous developer, bug fixing and stabilization, adding missing features that were planned but not built, and ongoing maintenance after the project is complete.
This is probably the most accurate description of what most businesses in this situation require. It is not new development — it is continuation and repair of existing development.
Legacy System Modernization
If the codebase you inherited is not just unfinished but also built on outdated technology, full of technical debt, or structured in a way that makes extending it extremely difficult, the work may go beyond application support into modernization territory. This involves re-architecting parts or all of the system, migrating to a more maintainable technology stack, or rebuilding specific components that are too broken to repair cost-effectively.
The distinction matters because modernization takes longer and costs more than support and continuation. A good technical reviewer will tell you whether you are in support territory or modernization territory within a week of looking at the codebase.
Custom Software Development
In some situations, what you discover after a technical review is that the existing code is not salvageable. The developer built the wrong thing, or built it so poorly that fixing it costs more than starting fresh. In those cases, you may need new custom development rather than a rescue operation. This is the least common outcome — most codebases, even messy ones, have salvageable value — but it does happen.
| Service Type | When You Need It |
|---|---|
| Application Management & Support | Software exists and partially works. You need continuity, bug fixes, and feature completion. |
| Legacy System Modernization | Software exists but is built on outdated tech or has severe structural problems that make continuation impractical without re-architecting. |
| Custom Software Development | Code review reveals the existing work is not salvageable. A fresh build is more cost-effective than rescue. |
The Code Review: Your Most Important First Step with Any New Vendor
Before any vendor quotes you a price for finishing the project, they need to review the existing code. This is not optional. Any company that offers to take over and complete a project without first reviewing what exists is either very inexperienced or not being straight with you.
A proper code review of an unfinished project covers several things: the completeness of what has been built relative to what was planned, the quality of the code and whether it follows standard practices, the degree of technical debt and how much it will slow down future development, the documentation available and whether the codebase is understandable without the original developer, and any security vulnerabilities that need to be addressed before the software is used in production.
This review typically takes between three days and two weeks depending on the size and complexity of the project. Some vendors offer this as a paid engagement, which is reasonable. Others will include it as part of a broader discovery phase. What you should be skeptical of is anyone who skips it entirely.
The output of the code review should be a plain-language report that tells you: what is done, what is broken, what is missing, what it will take to fix, and roughly what it will cost. You do not need to understand every technical detail in the report. You need to understand the business implications.
One Honest Warning
Some businesses, after a bad experience with a developer, are so eager to find a replacement that they agree to a new engagement before the review is complete. This is how you end up in the same situation again. The code review is the most important due-diligence step you have. Give it the time it requires.
What to Share with a New Vendor — A Practical Checklist
The quality of information you provide to a new vendor directly determines the accuracy of their assessment and quote. Here is what to gather and share.
Technical Assets
- Complete codebase export (all branches, all files)
- Database schemas and any existing data exports
- Environment configuration files (.env, config files, deployment scripts)
- API documentation or any integration specs
- Access credentials for hosting, domain, third-party services
- Any design files (Figma, Adobe XD, screenshots, wireframes)
Project Documentation
- Original requirements document or specification (even if informal — emails, slide decks, voice notes count)
- Any user stories, feature lists, or task boards from the original engagement
- Meeting notes or communication history that clarifies what was agreed
- Any contracts or statements of work from the previous developer
Business Context
- What the software is supposed to do, in plain language — not technical specs
- Who the end users are and how they will use it
- What is not yet built that is necessary for the software to be usable
- What the deadline is and what drives it (investor demo, client commitment, product launch)
- What budget is available for the remainder of the project
The more of this you can provide upfront, the faster the code review goes and the more accurate the initial assessment will be. Missing information does not derail a review — it just means the reviewer has to make more assumptions, which adds uncertainty to the quote.
Three Real Situations — and What the Path Forward Looked Like
These are drawn from actual engagements handled by Mind IT Systems, with client details anonymised.
The Healthcare Platform That Had Already Failed Once
A Chicago-based healthcare startup came to us after their previous development partner had spent nine months on a mobile app — a platform for connecting nurses to healthcare facilities for flexible staffing shifts — without delivering a functioning product. The founder had already sunk significant money into the engagement and was understandably frustrated.
After reviewing what existed, we found that portions of the UI and design work were usable, but the backend architecture was not viable for production. We rebuilt the backend and integrated the salvageable front-end work. Within three months of taking over the engagement, we had delivered what the previous company had not managed in nine.
The lesson from that engagement was not that the first company was incompetent across the board. They had done usable design work. The problem was that nobody had caught the architectural issues early enough for them to be corrected. The founder was not technical enough to spot it, and the developers were not transparent enough to flag it.
Source: Verified Clutch review — HourHealth Inc., Chicago, Illinois. Review submitted January 2023.
The Prescription Delivery Service with a Half-Built OS
A UK-based prescription delivery company hired us to build a bespoke operations management system. Their previous situation was not a developer walking out mid-project — it was that they had come to us with basic requirements and a history of being let down by vendors who could not handle custom work of that complexity.
We took on the project with a scope that gave us a clear line of accountability: they provided the requirements, we owned the implementation. The system was built on MySQL and AWS. Three months into the engagement, the client described the software as having “increased our visibility and efficiency” and said they planned to continue the relationship for enhancements.
What made this work was that the client had enough of their own documentation from previous attempts that we could use it as a foundation — even incomplete documentation is better than nothing. They also made themselves available for regular weekly reviews, which meant issues surfaced early.
Source: Verified Clutch review — RxTracked, London, England. Review submitted January 2024.
The Real Estate Business Running on Spreadsheets
Not every software rescue starts with a departed developer. A New Delhi property advisory firm came to us with a different version of the same underlying problem: no one had ever built them a system, and the business was now too large to run on the Excel sheets and informal processes they had been using since founding.
What they needed was a centralized property inventory and customer management platform that replaced their spreadsheet workflows. By the time we were engaged, they had already wasted months trying to spec the project themselves without technical guidance.
The outcome: reduced dependency on multiple spreadsheets, faster property search and client matching, better data consistency, and a digital foundation they could build on. The project did not involve rescuing an abandoned codebase — but the root cause was the same. A business had reached the limit of what informal systems could support, and needed someone to take ownership of building the right thing from scratch.
Source: Verified Clutch review — Genie Realty, New Delhi. Review submitted May 2026.
“In just three months, they achieved what the previous company couldn’t in nine.” — Verified Clutch review, healthcare staffing platform client, Chicago.
How Much Does This Cost — and How Long Does It Take?
These are the two questions that matter most to anyone in this situation, and they are also the hardest to answer without seeing the specific project. That said, there are reasonable ranges.
Cost Ranges
For a simple application rescue — taking over a reasonably well-structured codebase and completing 20-40% of remaining work — expect costs in the range of $20,000 to $80,000. This assumes the existing code is of reasonable quality and the remaining scope is clearly defined.
For a project where technical debt is significant and architectural problems need to be resolved before development can continue, costs typically run $40,000 to $190,000 depending on the scope and complexity of the system.
If the assessment concludes that a full or substantial rebuild is necessary, you are looking at a new custom development engagement. Based on Mind IT Systems’ project history across 200+ engagements, custom development projects for this type of mid-market business application typically run between $25,000 and $250,000. The Clutch-verified average project size for our engagements is $50,000 to $199,000.
Hourly rates for experienced offshore teams in India working on these rescue and development engagements typically range from $25 to $60 per hour. In-house or Western agency rates for equivalent work run three to five times higher.
Timeline
A code review to give you an honest assessment of the situation: one to two weeks.
Application management and support for a project that is 50-70% complete: two to four months to reach a production-ready state, depending on complexity.
Legacy modernization involving re-architecting significant portions of the system: four to eight months.
A full rebuild of a mid-complexity business application: three to six months for an MVP, with additional phases for full feature parity.
These ranges assume an engaged client who can review progress regularly and provide feedback. Projects with a non-responsive or unavailable stakeholder consistently take longer.
What to Look for in a Vendor for This Type of Work
Not every software company handles rescue work well. Some are built for greenfield development — starting from zero — and are uncomfortable with the ambiguity of taking over someone else’s code. Here is how to evaluate whether a vendor is genuinely suited to this type of engagement.
- They insist on a code review before quoting. This is a good sign. It means they are being honest about needing to understand what they are taking on.
- They can explain their process in plain language. If you cannot understand how they describe their approach to a rescue engagement, either they cannot explain it or they do not have one.
- They have verifiable proof of completing similar projects. Ask for Clutch reviews, case studies, or references specifically related to rescue or continuation work — not just new development.
- They communicate regularly and proactively. The failure of most departed developers was a communication breakdown. You need a vendor who will tell you when something is wrong, not after it has become a crisis.
- They separate the stabilization phase from the completion phase. Good vendors will prioritize getting the existing software to a stable, working state before adding new features. Vendors who jump straight to feature development without stabilizing what exists will create new problems.
What Not to Do — Common Mistakes That Make This Worse
There are a few decisions that businesses in this situation routinely make that compound the problem rather than resolving it.
Hiring the First Available Developer Out of Desperation
When a project is stalled and deadline pressure is real, the instinct is to move fast. This is understandable. It also leads to poor hiring decisions. A developer who can start immediately is available because their schedule has openings — which may mean their other clients do not want them full-time, or they are between projects for a reason.
Take two to three weeks to evaluate options properly. The cost of a bad second hire is higher than the cost of two weeks of delay.
Making Changes to the Codebase Before a Review
This was covered earlier but is worth repeating. Even experienced developers who try to make quick fixes to a codebase they do not fully understand frequently break things. The codebase as it exists at the moment of the original developer’s departure is your starting point. Preserve it.
Trying to Finish It with Non-Technical Staff
There is a temptation, especially in very small businesses, to have a technical-adjacent person — maybe a founder who knows some HTML, or an operations manager who has used no-code tools — try to push the project forward while a proper vendor is being found. This rarely works and often creates new problems that cost more to fix than the progress gained.
Not Having a Contract This Time
If the previous engagement ended badly partly because there was no clear contract or statement of work, the response cannot be to move faster and worry about paperwork later. A proper contract covering scope, milestones, IP ownership, payment terms, and what happens if the relationship needs to end is the single most important protection you have.
How to Avoid Being in This Situation Again
The most useful thing to come out of a bad experience with a departed developer is a better process for the next one. Here is what that looks like.
- Milestone-based payment. Do not pay a developer the majority of the fee upfront. Structure payments around deliverables — a working version of the login flow, a functional API integration, a complete data model. Money that has not been paid cannot be lost.
- Version control from day one. Any professional developer uses Git or an equivalent. If a developer you are considering does not use version control, that is a serious red flag. With version control, you always have access to every version of the code, and the codebase does not disappear when the developer does.
- Weekly check-ins with working software. Not status updates — working software. If a developer cannot show you something functioning at least once a week, that is a problem worth addressing immediately, not hoping will resolve itself.
- Code access in your name. From the start, ensure the repository, hosting, and any third-party service accounts are set up under your own accounts. The developer works in your accounts, not theirs. This eliminates the access problem entirely if the relationship ends.
- Documentation as a deliverable. Require the developer to document what they build as they build it. The documentation does not need to be perfect. It needs to exist. A README file, an explanation of the architecture, notes on what each major component does. This costs almost nothing in time and is worth enormously more if you ever need to bring in a new developer.
- A formal handover process, even if you never use it. The contract should specify what a handover involves. If the developer leaves on good terms, a proper handover takes a few hours and provides enormous continuity. Build it into the engagement from the beginning.
Structure payments around working deliverables, not calendar months. Money that has not yet been paid is your leverage. Once it is paid, your leverage is gone.
Frequently Asked Questions
What is ``application rescue`` and how is it different from normal software development?
Application rescue — sometimes called software continuation or application takeover — is the process of a new team taking over a codebase that was built by someone who is no longer involved. Unlike starting a project from zero, rescue work begins with a review of existing code, identifies what is working, what is broken, and what is missing, and then builds a plan to reach a functional end state. It requires different skills than greenfield development, partly because the team has to understand someone else’s decisions and work within or around them, rather than making their own choices from the start.
How long does it take to rescue an unfinished software project?
It depends on how complete the existing work is and how much technical debt exists. A project that is 60-70% complete with clean, well-structured code can often be brought to production within two to four months. A project where the existing code has significant architectural problems can take four to eight months, because some earlier work may need to be rebuilt before the project can move forward. The code review, which typically takes one to two weeks, will give you a much more specific timeline.
Can any software company take over an unfinished project, or do I need a specialist?
In theory, any experienced software development team can take over an existing project. In practice, some are significantly better at it than others. Rescue work requires comfort with ambiguity, experience reading and understanding unfamiliar codebases, and a willingness to have difficult conversations with clients about what is and is not salvageable. Companies that only do greenfield work may find it uncomfortable to tell you that the existing code is not as good as you thought, or that completing it will take twice as long as the original developer estimated. Look specifically for companies with verifiable experience in application management, support, and continuation work.
What is the first thing I should do when my developer stops responding or announces they are leaving?
Secure access. Before anything else, make sure you have the codebase, the repository access, and the credentials for every service the developer set up. This is significantly easier to do while the developer is still technically engaged than after the relationship has fully ended. If the developer is cooperative, ask for a written handover: a list of everything they set up, where the code lives, what is done and what is not, and any passwords or access tokens you will need. If they are not cooperative, begin account recovery processes with each service provider immediately.
How much does it cost to rescue a half-finished software project?
The range is wide because the situation varies so much from project to project. For a project that is mostly complete and just needs the final 20-30% of work done in a clean codebase, costs might be $20,000 to $60,000. For a project with significant technical debt and architectural problems, expect $40,000 to $190,000 or more. If the code is not salvageable and a rebuild is required, you are looking at a fresh development budget — typically $25,000 to $250,000 for a mid-complexity business application. The only way to get an accurate number is a code review, which any responsible vendor will do before quoting.
What documentation do I need to provide to a new vendor?
The most useful things are: the complete codebase (every file, not just the production branch), any requirements documents or feature lists from the original engagement, credentials for hosting and third-party services, design files if they exist, and a plain-language description of what the software is supposed to do and who will use it. More is better. Even informal documentation — email threads, Slack conversations, voice notes where someone described what they wanted — is genuinely useful for a team trying to understand what was planned. Do not worry about presenting everything perfectly. Just gather what exists and share it.
Should I try to hire another freelancer or go with a software company this time?
For a rescue engagement specifically, a software company with a team is almost always a better choice than a single freelancer. Rescue work benefits from having multiple people involved — at minimum, someone reviewing the code and someone doing the actual development. A single freelancer who is also doing the review and the build is more likely to miss things. A company also provides more continuity if one person becomes unavailable. That said, the most important factor is not freelancer versus company — it is whether whoever you engage has specific experience with this type of work and verifiable proof of completing similar engagements.
Is it worth trying to salvage the existing code, or should I start fresh?
In most cases, salvaging is worth attempting. Even a messy codebase typically contains work that would take significant time and cost to reproduce from scratch — UI components, database schemas, integration code, business logic. Starting fresh feels cleaner, but it usually takes longer and costs more than completion work, because you are rebuilding things that already exist. The exception is when the existing code has fundamental architectural problems that make completion more expensive than rebuilding. A proper code review will tell you which situation you are in within a week or two. Do not decide to start fresh before that review is done.
What questions should I ask a potential vendor during evaluation?
The most useful questions: Can you show me examples of similar rescue or continuation projects you have completed? (Ask for Clutch reviews or case studies, not just verbal claims.) What does your code review process look like, and what will you deliver at the end of it? How do you handle a situation where the existing code is worse than expected? What does your client communication look like on a week-to-week basis? And — the question that tells you the most — can you connect me with a reference client from a rescue engagement specifically?
What if my previous developer claims to own the code they built?
This is a real issue and one worth addressing before it happens rather than after. In most jurisdictions, the intellectual property created by a contractor belongs to the contractor by default unless a written agreement says otherwise. If your original contract with the developer included an IP assignment clause specifying that code written under the engagement belongs to you, you are protected. If it did not, the situation is more complicated. Consult a technology lawyer in your jurisdiction before making any decisions. In practice, most developers in this situation do not pursue ownership claims even if they technically could — but you should not rely on their good judgment as your only protection.
Where to Start
The situation is stressful. It is also manageable, and it is far more common than most people realize — which means there are vendors who have done this before and know what they are doing.
The practical starting point is a conversation and a code review, in that order. Before you commit to anything — before you agree to a scope, a timeline, a price, or a new contract — you need someone to look at what exists and tell you honestly what you have. Not an estimate, not an optimistic assessment. An honest one.
That review takes one to two weeks. It costs something, though many reputable vendors will include it as part of an initial discovery phase. It is the only thing that will give you the information you need to make a good decision about what to do next.
If you are in this situation right now and not sure where to start, you are welcome to contact Mind IT Systems. We have handled rescue engagements across healthcare, fintech, logistics, and property technology — for clients in the US, UK, India, UAE, and New Zealand. We will tell you what we find, including if what we find is not what you hoped to hear.
Talk to Mind IT Systems
We have rescued and completed software projects for founders and businesses across the US, UK, India, UAE, and New Zealand. We will review your codebase honestly and tell you exactly what you have — including what it will cost and how long it will take to complete it. No commitment required for the initial conversation. required for the initial conversation.
References
- Harvard Business Review. “Why Your IT Project May Be Riskier Than You Think.” Referenced:largeIT projects run on average 27% over budget. hbr.org
- Beta Breakers, citingZipdo “Essential Software Project Failure Statistics In 2023.” 31.1% of software projects are canceled before completion. betabreakers.com/blog/software-survival-in-2024
- BCG, “Software Projects Don’t Have to Be Late, Costly, and Irrelevant,” June 2024. Reasons for IT failures include misalignment between technology and business sides, unrealistic timelines, and insufficient resources. bcg.com
- Clutch.co. Verified client review —HourHealth, Chicago, Illinois. January 2023. clutch.co/profile/mind-it-systems
- Clutch.co. Verified client review —RxTracked, London, England. January 2024. clutch.co/profile/mind-it-systems
- Clutch.co. Verified client review — Genie Realty, New Delhi, India. May 2026. clutch.co/profile/mind-it-systems
- Stack Overflow Blog. “3 Things That You Should Do When a Developer Resigns.” July 2018.blog
Share this post
About the Author
Shailendra Gupta
(Co-Founder and CEO of Mind IT Systems)
Shailendra Gupta is Co-Founder and CEO of Mind IT Systems, a custom software and AI engineering firm based in New Delhi that has delivered 200+ projects across 14 countries since 2014. He has spent two decades helping businesses — mostly mid-market, frequently in healthcare and fintech — get their technology to actually work the way it was supposed to. A recurring theme across many of those engagements: someone built something halfway, then left. The cleanup is rarely pretty, but it is nearly always fixable.