Software Rescue

Your software works. Mostly. I make it reliable.

I rescue unfinished and broken software projects, whether built by AI, freelancers or previous developers.

Built with Lovable, Bolt, Replit, Cursor, Claude Code or a custom stack? I can help you understand what is broken, preserve what works and move the product forward.

One engineer · Direct communication · No rewrite by default

production.log

Symptoms

Does this sound familiar?

If more than two of these are true, the product lacks a reliable foundation, and it already has users waiting.

  • The app works until you change something.
  • AI fixes one bug and creates another.
  • Authentication works only for some users.
  • Payments fail randomly.
  • Roles and permissions are inconsistent.
  • Production deployment is unstable.
  • You do not know whether secrets are exposed.
  • The database has no reliable constraints.
  • There are no useful logs.
  • The previous developer disappeared.
  • You are afraid to invite real users.

Scope

What I fix

The failures that keep a product out of production are usually the same ones, in a different order.

authentication authorization roles and permissions payment flows webhooks API failures database design data integrity deployment environment configuration security secrets management logging monitoring queues background jobs frontend/backend integration production readiness architecture bottlenecks

The promise

A rewrite is not the default answer

I don't automatically propose a rewrite.

Roman Golovanov

I first understand what you already have, preserve what works and fix what actually blocks the product. Starting from zero is easy to sell and expensive to live with: it throws away the working parts you already paid for, and it resets the clock on every user you were about to invite.

Service formats

Four ways to start

An agency usually starts with a scoped project in the thousands of dollars. Here you work with one senior engineer and can start with a single problem. Prices are starting points, not quotes: the real number depends on what the diagnostic finds.

Fix a specific problem

From USD 150

A focused issue such as authentication, payment, API, deployment or data inconsistency.

What you get

  • The failure reproduced first, not guessed at
  • The fix, checked for regressions before it ships

Result. The fix in your repository and a written account of what was changed.

Typically 1–3 working days once I have access.

Start with this

Production readiness review

From USD 250

A structured review before inviting real users or starting paid acquisition.

What you get

  • All sixteen points of the checklist below, from secrets and payments to backups and rollback
  • Which failures reach a person and which only reach a log file

Result. A written report: what is broken, what is risky, what is fine and what can wait.

Written report within 3–5 working days.

Start with this

Ongoing technical support

Monthly agreement

Continued maintenance and technical ownership after stabilization.

What you get

  • Maintenance and fixes by the engineer who stabilized the system
  • Written communication and progress reports, asynchronous if you prefer

Result. Progress reports in writing. The code, servers and accounts stay in your name.

Replies within one working day.

Start with this

Process

How a rescue runs

Nothing is touched before it is understood. You always know what I am doing and why.

  1. Step 01

    Send URL, repository and a short description

    What the product does, what is broken and what you are afraid of. No technical specification required.

  2. Step 02

    Initial fit check

    I tell you whether this is something I can help with. If it isn't, I say so.

  3. Step 03

    Focused diagnostic or paid review

    I read the code, the data model and the deployment, and reproduce the failures instead of guessing at them.

  4. Step 04

    Clear repair plan

    What is broken, what is risky, what is fine, what it costs to fix and what can wait.

  5. Step 05

    Fixes in prioritized order

    Things that lose money or leak data first. Cosmetic issues last.

  6. Step 06

    Regression testing

    A fix that breaks something else is not a fix. Behaviour is verified before anything ships.

  7. Step 07

    Handover and recommendations

    You get a working system, a written account of what was changed and what I would do next.

Checklist

Production readiness checklist

The sixteen things I check before an application is allowed to meet real users. A production readiness review walks through every one of them.

  • secrets
  • auth
  • access control
  • payments
  • webhooks
  • database constraints
  • error handling
  • logging
  • monitoring
  • backups
  • deployment
  • rollback
  • rate limits
  • data deletion
  • privacy
  • dependency risks

How we work together

The terms, before you have to ask

You work directly with the engineer who reads and writes the code. No account managers, no juniors in between.

01

The code is yours from day one

Repositories, servers and accounts stay in your name. I work with the access you grant, so nothing depends on me holding the keys.

02

NDA on request

If the project needs one, send your NDA and I sign it before we go into details.

03

Work in steps, estimated in writing

Each step starts with a written estimate of what it covers and what it costs. After each one you decide whether to continue.

04

Prices and invoices in USD

Every estimate and every invoice is in US dollars.

05

UTC−3

My working hours overlap with business hours in both the US and Europe.

06

A reply within one working day

Every request gets an answer within one working day, including the ones where the answer is that I am not the right person.

FAQ

Questions I get before we start

Only if the existing system is objectively more expensive or dangerous to repair. A rewrite is not the default recommendation.

Yes. The source of the code matters less than whether the product can be understood, tested and made reliable.

Usually yes, but the first conversation can begin with a URL and problem description.

Yes. The process can be organized through written communication, repository access and progress reports.

Case studies

Two failures that stayed invisible

Anonymized, structured as situation, risk, decision and result. Client names stay confidential; the point is the reasoning, not the logo.

Send your app URL, repository and a short description of what is broken.

You don't need a diagnosis. That is my job. A few sentences about what fails and when is enough to start, and I'll tell you whether I'm the right person for it.