Software Project Rescue
The build is late, the budget is spent, and the people who wrote the code have stopped answering. I start by finding out what actually works, what can be saved, and what has to go — before anyone writes another line.
Software project rescue means taking over a build that has stalled, run past its budget, or lost the team that made it, and getting it back to something you can ship. Oleg Sotnikov opens every rescue with triage: a few days spent reading the code, the infrastructure, and the delivery history to decide what is salvageable and what has to be replaced. The work only starts after that verdict — production gets stabilized first, then delivery restarts with a small AI-augmented team. He has 25+ years in IT and more than 1,000 projects behind him.
What a Rescue Covers
Six areas that usually need attention. Triage decides which of them apply to you.
Stabilize production first
If the product is live and breaking, that gets fixed before anything else: error visibility, alerting, working backups, and the failures that wake people up at night. No recovery plan matters while users are losing data.
Take-over from an agency or a departed developer
Repositories, cloud accounts, domains, API keys, deploy pipelines. I inventory what exists, get you real ownership of it, and document the gaps while the previous team is still reachable.
Architecture recovery vs. rewrite
The expensive decision, made with evidence. What the code actually does, how much of it carries load, and whether the shortest path is repair, partial replacement, or a clean rebuild of the parts that matter.
Security and data integrity review
Committed credentials, endpoints with no authorization, a database whose backup has never been restored. Rescued projects tend to carry several of these, and they get closed early rather than after an incident.
Delivery restart with a lean AI-augmented team
A small team using AI coding agents moves faster than the one that stalled, at a fraction of the payroll. I set up the workflow, the review gates, and the weekly cadence, then hand them over.
Documentation and bus-factor repair
The reason the project died the first time. Architecture notes, runbooks, environment setup, and deploy steps written down so the next departure is an inconvenience instead of a crisis.
Rescuing Vibe-Coded Apps
You shipped something real with Cursor, Claude Code, Lovable, or v0. It works, people use it, and it took weeks instead of a year. That was a good call. The product exists because you built it that way, and no rescue starts by arguing with a working product.
The wall you hit later has a specific shape. There are no tests, so nothing can be changed with confidence. The architecture grew one prompt at a time, which is why the same logic lives in four places. Authentication and data access were generated rather than designed. Every new feature breaks two old ones, and the codebase has outgrown what any model can hold in context at once.
None of that means throwing the product away. Real users are the expensive thing to acquire, and you already have them. My job is to make what you built maintainable — so a year from now it is still cheap to change, and the AI tooling that got you here keeps working at the size you are now.
- A test harness around the behavior that already works, so you can verify the next change instead of hoping
- Data model and authorization reviewed by hand — the two things generated code gets wrong most often, and the two that cost the most to fix late
- The tangled parts untangled in the order that unblocks the most work, a few at a time rather than as one rewrite
- CI, error tracking, and restore-tested backups wired up, so a bad deploy becomes a rollback rather than an incident
How a Rescue Runs
Triage
Days, not weeks. I read the code, the infrastructure, the tickets, and the commit history, then give you a written verdict: what is salvageable, what has to be replaced, and what each option costs. Sometimes the verdict is to stop spending on it, and you get that in writing too.
Stabilize
Stop the bleeding. Crashes, data-loss risk, exposed credentials, deploys that fail half the time. This is usually the shortest phase and the one that changes how the week feels for everyone involved.
Restart
Delivery gets a cadence again: a small team, a scoped roadmap, something shipped every week, and a review process that holds. I stay on as fractional CTO for as long as it takes that to run without me.
Why Me
- 25+ years in IT, 1,000+ projects, and 9 startups founded — I have seen most of the ways a build goes wrong, usually more than once
- Shaped the architecture of a production ERP system for QueueStone and stayed involved through delivery (quote below)
- Run AppMaster's platform — 99.99% uptime, users in 190+ countries — after taking that team from 25 people down to 2
“Oleg Sotnikov was a great support to our team as Fractional CTO. He helped us shape the architecture of an ERP system for a mental health clinic and stayed involved throughout the development process, helping us make better and more efficient decisions. We truly appreciate his contribution.”
Frequently Asked Questions
Is my project salvageable, or should we rewrite it?
Triage answers that, and the honest answer is usually mixed. Most failed software projects die from process and people rather than from unsalvageable code: if the data model holds up and the product does something users value, repair costs less than a rewrite even when the code looks bad. A rewrite earns its price when the core abstraction is wrong, when the stack blocks the roadmap you need, or when nobody left can explain what the system does. You get the reasoning, not just the verdict.
How do you take over from our agency or contractor?
Access and inventory first: repositories, cloud accounts, domain and DNS, API keys, deployment pipelines, and any environment that only exists on somebody's laptop. I run that handover while the previous team is still reachable, because the same questions get expensive once they are gone. Contracts and IP ownership are yours to settle with them; my part is making sure the technical assets end up genuinely in your hands.
Can you rescue an app built with AI tools like Cursor or Lovable?
Yes, and it is a growing share of this work. Vibe coding gets products to market fast, and a vibe-coded product with real users has already proven the hard part, which is that someone wants it. What it usually lacks is a test harness, a coherent data model, and a security review, and all three can be added to a running product without starting over. The goal is to make it maintainable, not to rebuild it as a lesson.
What does a project rescue cost?
It gets scoped after triage, because that is what tells either of us how much work is actually there. Ongoing rescue work runs as a fractional CTO engagement at $5,000–10,000 per month, month to month, or as advisory from $3,000 per month — the rates are published on my pricing page. If you want a fixed-price starting point instead, the Team & AI Audit is $5,000 for five business days.
Will you work with our existing team?
Usually yes, and that is the better outcome. The people who have lived in the code know things no review surfaces, and they are often the ones who raised the alarm in the first place. Where the team is too small or too junior for what is left to do, I say so directly and we bring in help. I do not quietly replace people to sell headcount.
Get a Verdict on Your Project
A triage call costs nothing and usually tells both of us, inside an hour, whether this is fixable and what the first move should be.
English or Russian, US Pacific hours, async-first. NDA on request.
Related reading
Delivery, architecture, and what actually goes wrong on software projects.
