Rescue & Modernization

Who it's for

Owners of a working-but-fragile system: the Access database from 2009, the app the developer who left wrote, the codebase the last agency abandoned mid-project.

The problem

The system works, mostly, which is exactly why it never gets fixed — until the person who understood it leaves, the machine it runs on dies, or the change you need is one nobody can safely make. Fragile software does not announce its deadline.

What you actually get

• —A written assessment first: what the system actually does, where the risk is, and an honest recommendation — sometimes the answer is "leave it alone"
• —The rescue itself: a modernized replacement or a stabilized original, per the statement of work
• —Your data, migrated and verified against the old system
• —Source code in a repository you own, with tests that pin down the behavior that matters
• —A handoff document that ends the bus-factor-of-one problem for good

The process

1. 1.

   Assessment

   Flat-quoted assessment of the existing system: behavior, data, risk. You get the written findings whether or not you continue.

2. 2.

   Statement of work

   Based on the assessment: what gets rebuilt, what gets kept, what the data migration involves. Fixed scope, quoted range, checkpoint payment schedule.

3. 3.

   Build & parallel run

   The new system runs alongside the old one against real data until the outputs match and you trust it.

4. 4.

   Cutover & handoff

   Planned cutover with a rollback path. Repository, docs, and data-verification records handed over.

The build is done by Favur, our autonomous multi-agent software team, directed and reviewed by us. Read exactly how that works.

Timeline

Assessment: about a week. Rescue builds: 2–6 weeks depending on scope, stated precisely in the statement of work.

Price

Assessment $1,500 · rescue builds $8,000 – $30,000 typical range

Rescue pricing depends on how much behavior must be preserved exactly, the state of the data, and whether the old system can be read or must be reverse-engineered from its outputs. Rescues of this size are paid about 20% up front with the rest at agreed checkpoints, and the final number is settled at delivery from the compute the rescue actually consumed. The assessment exists so the quote is grounded in evidence, not hope.

More on how pricing works on the pricing page.

Explicitly out of scope

• ✕Pretending a rescue is cheap — if the honest assessment says the rebuild is large, we will say so and quote it honestly
• ✕Rescuing systems we cannot legally access (software licensed to a defunct vendor without source)
• ✕Maintaining the old system indefinitely as-is — we stabilize or replace; we do not become the new bus factor

What we need from you

• —Access to the running system and whatever source, backups, or documentation exists (even partial)
• —The people who use it daily — an hour of their honesty is worth a week of code reading
• —A tolerance for the assessment finding things you did not want to know

Common questions

The last developer left no documentation. Is that fatal?

No — it is normal. Most rescues start from a running system, a database, and the memories of the people who use it. The assessment phase exists to establish what is recoverable before you commit to a rebuild price.

Can you just make one small change to the old system instead?

Sometimes, and when that is the honest answer the assessment will say so. We would rather quote you a $2,000 stabilization than a $20,000 rebuild you did not need — that is what the flat-price assessment is for.

What happens to our data?

It is migrated with verification: the new system’s outputs are compared against the old system’s during the parallel run, and the comparison records are part of the handoff. Your data never leaves accounts you control.