Software Rescue & Takeover in New Zealand

Why nobody will quote a fixed price

It feels evasive and it is not. Rescue work is the one category where a firm number up front is a warning sign.

A developer looking at software they have not read cannot know whether the problem is a configuration error found in an hour or a structural fault that takes six weeks. Quoting anyway means padding heavily to cover the bad case — you overpay — or quoting optimistically and arriving in week three with awkward news. Neither is what you want.

The professional shape is a short paid assessment: a few days reading the code, running the system, checking hosting and dependencies, and reporting what is actually there. $3,000 to $10,000, and it ends with a report you own and a real quote you can compare against others.

Collect your assets before you collect quotes

Before talking to anyone, find out what you actually control:

• Source code. In a repository you can access, ideally not only on someone's laptop.
• Hosting. The account the servers are billed to, and the login.
• The domain. Which registrar, in whose name. This is the urgent one — if it lapses, everything stops at once.
• The database. Access, and a backup you have downloaded yourself.
• Third-party accounts. Payment gateway, email, SMS, maps, anything with an API key.

Missing pieces are usually recoverable, but each one adds delay and cost. It is also the cheapest work in the project and you can do it yourself this week.

Fix or rebuild?

Rebuilding is more expensive and more disruptive than it looks, because working software encodes hundreds of decisions nobody wrote down — the odd rule for that one customer, the workaround for the annual audit, the reason a field allows a value that looks wrong. A rebuild rediscovers all of it, in production, with your staff finding the gaps.

Fix when the system does the right things badly: slow, awkward, ugly, but correct.

Rebuild when it does the wrong things, when it runs on technology that no longer gets security updates, when nobody can change it safely, or when the assessment finds the data model cannot support where the business is going.

Get that judgement from someone who is not bidding for the rebuild, or get a second opinion from someone who is not.

Stabilise first, improve later

The instinct with inherited software is to fix everything. Resist it.

Ask for the most urgent risk and the cost of addressing just that. Usually it is a small list: unpatched software with known vulnerabilities, backups that have never been restored, credentials shared by five people, or a single server with no way to rebuild it if it fails.

Fix those, then decide about the rest with a clear head. Software that has run for four years can usually run for another six months while you think.

Half-finished is a special case

An abandoned build is the hardest thing on this page to price, and sometimes the honest answer is that it is worth less than nothing — inheriting someone else's half-made decisions can cost more than starting cleanly.

The assessment matters most here. What works end to end, what is scaffolding, and how much of the remaining work the existing code actually saves. Be prepared for the answer to be "keep the database design and start again", and be suspicious of anyone who reaches that conclusion before reading it.

When the previous developer will not hand over

Start with a polite, specific written request: what you need, where to send it, by when. Most cases are disorganisation, not obstruction, and a clear list resolves them.

If that fails, your position depends on your contract and on who owns the accounts — which is exactly why domains and hosting should be in your name from day one. Where money is in dispute, get advice before escalating: attempts to recover access through the back door tend to make everything slower and more expensive.

Meanwhile, assume nothing will arrive and ask your new developer what they can reconstruct without it. Often more than you would expect.

Give the new developer time to read

Unfamiliar code takes time. A small tidy system: a week or two before someone can change it confidently. A large undocumented one: six to eight weeks.

That reading time is not padding, and pressure to skip it is how a rescue becomes a second rescue. Anyone claiming to be productive on day two of a codebase they have never seen is either exceptional or about to break something.

What to compare across quotes

• The assessment. What it costs, how long, and what you get at the end.
• The urgent list, separated from the wish list.
• Fix versus rebuild, with reasoning — and note who benefits from the answer.
• Time to safe changes. How long before they can work confidently.
• Handover. What documentation you get so the next transition is easier.
• Rescue experience. Ask about one they inherited and still maintain.

Describe what you have, honestly

You do not need to know what is wrong. Say what the software does, what has broken, what you can and cannot access, and what happens to the business if it stops. Developers who take over systems regularly will tell you which parts are urgent, what an assessment would reveal, and whether keeping it is the right call at all.