It works, mostly. Nobody can say why.
Someone built it, and for a while that was enough. Then they moved on. Now the system sits in the middle of how the business runs: orders, billing, scheduling, the sync between two platforms. Nobody left on the team has read the code, and the documentation is a folder of screenshots or nothing at all.
So it stays untouched, because touching it feels dangerous. A small request gets quoted at three times what it should cost. A vendor asks for a deposit before they will even look. And somewhere in the back of your mind is the question you can't answer: if this stopped tonight, who would we call?
That is not a failure of your team. It is what happens when a system outlives the people who understood it. It is also fixable, and the first step is smaller than most people expect: find out what you actually have. Our guide to what to do when your developer leaves walks through the first month.
Six situations we are called into
The causes differ. The first move is the same: read what is there before deciding anything.
The developer left
One person built and maintained it. They are gone, or they are a contractor who has gone quiet. Nobody has the passwords, the deployment steps, or a clear picture of what runs where.
The agency or offshore team stopped
The contract ended, the team was reassigned, or communication dried up. What you received may build and run, but no one on your side can say how well it was made.
The vendor delivered something that doesn't hold up
It was signed off, and then real data arrived. Screens are slow, numbers don't reconcile, and every fix creates a new problem.
The integration fails without telling anyone
Two systems are supposed to stay in step. Sometimes they don't, and you find out when a customer or an auditor does. There is no log anyone trusts. See our integration services.
The platform moved underneath it
Microsoft set November 10, 2026 as the end of support for .NET 8, .NET 9 and the in-process model of Azure Functions. A Dynamics 365 release wave can break a plugin the same way. The system didn't change. Its surroundings did. The free .NET end-of-support checker dates each runtime.
Every change breaks something
Speed got it launched. Now there are no tests, no separate environment, and each edit goes straight to the live system with fingers crossed.
The common thread isn't bad code. It's that the people who understood the system are no longer there, and the business still depends on it.
We start by reading, not by changing
The Rescue Assessment is read-only. Nothing in your production environment is touched until you have the report and have chosen what to do. You work directly with the senior engineer doing the review, remotely, in US Central time.
Access, kept narrow
You give us the repository (or a zip of it), the database schema and a read-only view of the deployment. We don't ask for production credentials to read the code. If shared passwords or keys turn up along the way, we tell you which to change.
Build it, run it, trace it
We get it to build on a clean machine, which alone tells you a lot. Then we follow the paths the business depends on, check each dependency and its support status, look at how secrets, backups and deployments are handled, and note what only one person could have known.
A written report in one to two weeks
Plain language first, technical detail underneath: what the system does, what is wrong ranked by how much it matters, what is risky, what is fine, and a recommendation to repair, replace in stages or leave alone, each with a fixed price.
You decide. The report is yours.
Hand it to your team, take it to another firm, or build with us. If you build with us, the assessment fee comes off the price.
What the report contains
- A map. What the system is made of, where each piece runs and how data moves between them, in one diagram a non-developer can follow.
- A ranked list of problems. Each item says what it is, what it costs you if it stays, and how long it takes to fix.
- A risk page. Single points of failure, unsupported components, exposed secrets, missing backups, and anything that would hurt if the one person who knows it were unavailable.
- A support-status check. Every runtime and major dependency against its published end-of-support date.
- A recommendation. Repair, replace in stages, or leave alone, with the reasoning, so you can disagree with it intelligently.
- Fixed prices. For the fixes we recommend, so you approve a number, not an open-ended estimate.
Sometimes the right answer is to leave it alone
A rescue is not always the answer, and we say so. Before you spend anything:
- It works and nothing around it is changing. An ugly system that does one job reliably costs less to keep than to fix. We would document it, and tell you what would make it urgent.
- The fix is a few targeted changes. An assessment often shows the code is rougher than it is broken. Three focused repairs cost far less than a rewrite.
- A rewrite really does cost less. Occasionally the honest finding is that the foundation is too weak to repair economically. We say that too, with the number, and show you where the break-even sits.
- It's a function app on the in-process model. That is a known job with a fixed price. See the Azure Functions isolated worker migration.
- It's a Power App that outgrew the platform. That is a different path. See rebuilding a Power App as custom software.
The assessment exists to tell you which of these you are in. You keep the report either way.
What we take over: the Microsoft stack and what sits around it
- .NET web apps, APIs and services, including .NET Framework applications and the move to a supported runtime
- Azure: App Service, Functions (including the move from the in-process model to the isolated worker), Logic Apps, API Management and Azure SQL. .NET applications hosted on AWS on request.
- Dynamics 365 and Business Central: plugins, workflows, extensions and customizations
- Power Platform apps and flows, as part of a wider system
- Integrations between ERP, CRM and e-commerce systems, including ones that fail silently
- React and Angular front ends, .NET MAUI mobile apps and SQL Server databases
If the system is built on a stack outside this list, we say so on the call and tell you who to talk to instead. For new work rather than a takeover, see custom software development.
What a rescue costs
Three steps, each with a price you can see before you talk to anyone.
A free call or written review
$0 · 30 minutes
A call with a senior engineer: you describe what you have and what is wrong, and we tell you whether an assessment makes sense. Prefer it in writing? Describe the system and get a reply by email within two business days.
Request a free written reviewRescue Assessment
$2,500 fixed · 1–2 weeks
A read-only review of one application with its database and deployment, and a written report with ranked findings and fixed prices. Larger systems, or several applications, get a fixed price on the call. The report is yours whatever you decide, and the full $2,500 comes off any fix or build you commission from us.
Stabilization sprint
From $12,000 · 2–4 weeks
The fixes the assessment ranked highest: security, deployment, the failing paths, documentation, and tests around what matters. The price is fixed after the assessment, and you approve it before work starts.
In the Rescue Assessment
- Read-only review of the source, data schema and deployment setup
- A build and run on a clean environment
- The written report: map, ranked problems, risk page and support-status check
- A recommendation with fixed prices
- A 60-minute walkthrough of the report with your team
Not included, priced separately
- Changes to production before you have approved the report
- Rewriting or replacing the system
- Penetration testing or a formal security audit (we flag exposure; we do not certify)
- Ongoing support or hosting
- Systems outside the stack listed above
- Data recovery from a failed or lost database
After stabilization, bigger work (a staged replacement, an upgrade, a rebuild) is scoped from the report, priced separately, and optional. If the assessment says leave it alone, we will say so.
What we have done with systems like yours
For a Texas professional services firm running its projects and billing in Business Central, we built a timesheet, overtime and expense app that sends only approved entries into Business Central. Billing close went from 7–10 days to 3–4. Read the Business Central timesheet app case study.
That was a new build, not a takeover. The skill a rescue needs is the same one: learning how a business actually runs a process, finding the part that matters, and changing it without breaking what works.
Why an assessment with us is worth two weeks
The report is yours, whatever you decide
It is a document you can take to another firm. We would rather earn the build than hold the information back.
It runs in your tenant, on your code
Fixes deploy to your own Azure or Dynamics 365 environment, with the repository handed over. Nothing about the result ties you to us.
Fixed prices, not hourly
The assessment is a number. The fixes it recommends are numbers. You approve each one before work starts.
20+ years combined in the Microsoft stack
Dynamics 365, Business Central, Azure and .NET, as a Microsoft Partner. Senior engineers read the code, in US Central time.
Tell us what you inherited
Describe it in a few lines: what it is, what it's built on, what is going wrong and how urgent it is. A senior Craftware engineer replies by email within two business days (US Central) with whether an assessment makes sense. It's free, needs a work email, and no sales call is required.
Request a free written reviewSoftware project rescue: FAQs
-
Our system is down right now. Can you help?
Call (832) 308-0063 and say it's down. If we can help, getting it running comes first, and the assessment comes after.
-
Do you need access to production?
Not to read the code. The assessment works from the source, the database schema and a read-only look at how it is deployed. If we need to see production behavior, we ask first and agree what to look at.
-
What if there is no documentation at all?
That is the usual case. Writing down what the system is, where it runs and how it deploys is part of what the report does.
-
We don't have the source code. Can you still help?
Sometimes. If the application is deployed, a lot can be recovered from what is running, and we will tell you plainly what is and isn't possible. Start with the free call.
-
How big a system does the $2,500 cover?
One application with its database and deployment, reviewed in one to two weeks. Larger systems, or several applications, get a fixed price on the free call before anything starts.
-
What if the assessment shows the code is bad?
We say so, in writing, with the cost of fixing it and the cost of replacing it side by side. You get what you need to decide, including "don't spend money here" when that is the answer.
-
Is the assessment fee refundable if we don't go ahead?
No, but the report is yours: the map, the ranked findings and the fixed prices can go to any firm. If you build with us, the full $2,500 comes off the price.
-
Will you take over maintenance afterward?
If you want that, yes, priced separately once we know what we are maintaining. It is optional. The report and the repository are yours either way.
-
Can you review code that was written with AI tools?
Yes. Where the code came from doesn't change the method: we build it, run it, trace the paths the business depends on, and report what we find.
-
Do you work outside Houston?
Yes. The work is remote. We are based in Sugar Land, Texas, and work with clients across the United States.
-
Can we have you sign an NDA first?
Yes. Send yours, or we will send ours.
Not sure it's a rescue?
That's fine. A free 30-minute call with a senior Craftware engineer, or a free written review if you'd rather not meet.