Why do you charge for the audit before quoting?

Because the alternative is guessing at the price of something nobody has looked at, and the guess is always wrong in the same direction. The audit is a small, fixed piece of paid work that produces a written answer — what state the code is in, what is actually causing the fault, roughly how much work it is, and whether it can be fixed at all. You own that document. If you take it to somebody else, it still works.

Can you just give me a fixed price?

Not before the audit, and usually not after either. Rescue work is priced hourly because the unknowns sit inside code we did not write. After the audit we can give you a realistic range and a cap you can set, so you are never surprised — but a fixed price on inherited code is a number invented to win the job, and it gets paid for later in corners cut.

My old developer has disappeared and I do not have the passwords. Is that fatal?

Usually not, but it changes the first day of work. Hosting control panel or registrar access is normally enough to recover the rest. What we need at minimum is somewhere the site actually lives that you can prove you own. If the code exists only on a machine belonging to somebody who is not answering, say so at the start — that is a different conversation about rebuilding, not repairing.

Is it cheaper to fix this or start again?

That is one of the questions the audit answers, and sometimes the answer is start again. Code that has no version history, was edited directly on the live server, and duplicates the same logic in several places can cost more to make safe than to replace. We would rather tell you that in the first two hours than discover it in the third week of your money.

Do you charge more for emergencies?

Yes, when it is genuinely out of hours or requires dropping other work, and it is said before anything starts rather than added to the invoice afterwards. A live store that is down is the most urgent and most expensive category of this work. A bug that has been there for six months is not an emergency, and should not be priced as one.

What if you cannot fix it?

Then you are told, with the reason, and you have paid for hours rather than a promise. That outcome is rare but it is real — some failures live in a third-party service, an expired licence, or a dependency whose author has vanished. Knowing precisely where the wall is has value, because it lets you make the next decision with facts.

Web Development & Engineering

Bug fixing and rescue projects

Picking up somebody else's half-finished or broken build — starting with a paid audit, because nobody can price code they have not opened.

From: $40–$90/hr
Typical time: 1–14 days
Usually bought by: Frustrated owners

What this actually solves

You are not shopping. You are stuck. Somebody built something for you and then stopped answering, or delivered something that does not work, or left halfway with your money and a folder of files you cannot open. There is often a date attached — a launch, a campaign, a client of your own who is waiting — which is why this conversation feels different from every other conversation about a website.

The specific pain is usually one of three shapes. Something that used to work has stopped, and the person who built it is gone. Something was never finished and the last developer left no explanation of where they got to. Or, worst of all, something works intermittently — the booking form submits and nothing happens, except sometimes it does, and nobody can make it fail on demand. That third shape is the one that eats weeks, because it cannot be fixed until it can be reproduced, and it cannot be reproduced until you understand the conditions that trigger it.

What makes this work different from building is that the hard part is not writing code, it is reading somebody else's. Inherited projects arrive with no documentation, no version history, no local development setup, and frequently no explanation of how the thing was ever deployed. Understanding what is there is the job. The fix, once the diagnosis is right, is often small.

What we do, and in what order

Everything below the first step depends on the first step. Skipping it is how rescue projects become the most expensive work in the trade for everyone involved.

A paid audit, before any estimate exists. One to two hours of paid time reading the code, the error logs, the hosting setup and the database, and then a written answer — what state it is in, what is causing the fault, what it will take, and whether it is worth repairing at all. Nothing is promised before this, because a price given without opening the code is a guess dressed up as a quote. One to two hours.
Take a copy and get it under version control. Every file and a database dump pulled down and committed before a single character changes, because inherited projects frequently have no version history at all and are being edited directly on the live server. This creates the thing that does not currently exist — a point you can return to when a fix makes things worse. Two to four hours.
Get it running somewhere that is not production. Reproducing the environment locally or on a staging server is regularly a full day on its own, and it is not optional. Debugging on a live site means every experiment is visible to customers and every mistake is a real outage. Old dependency versions, missing configuration and hard-coded paths are the usual obstacles here. Half a day to a day.
Reproduce the fault before touching it. A bug that cannot be made to happen on demand cannot be verified as fixed. For intermittent faults this means finding the condition that triggers it — a particular input, a race between two requests, a scheduled task, a specific browser, a timeout under load. Chrome DevTools and the server's error log do most of this; an error tracker like Sentry earns its place when the fault only appears for real users. Two hours to two days, depending on the fault.
Fix, verify, and hand back something maintainable. The fix is applied to the root cause rather than the symptom, tested against the reproduction from the previous step, and then deployed. You are given the repository, a note of what was actually wrong, and an honest list of the other problems found along the way, marked as urgent or not. Hours to several days.

What moves the price

The range is $40–$90/hr, most jobs run 1–14 days end to end, and where a job sits inside that comes down to three things.

How critical the failure is. A live store that cannot take payment sits at the top of the range, because it requires dropping everything and because the cost of being wrong is immediate. A cosmetic fault on a page nobody visits sits at the bottom. The urgency is priced honestly and stated up front, not applied quietly at invoice time.

What it is built in. A familiar stack is faster to read, and reading is most of the work. Rescue work in a framework nobody on the job knows well is slower for you and riskier for you, which is why we would rather decline it than charge you for the learning curve.

The state it arrives in. No version history, no local setup, direct edits on production and the same logic copied into three files all add hours before any fixing begins. This is also the factor the audit exists to measure, so you find out about it in hour two rather than week three.

What usually goes wrong

A fixed price is given on the strength of a description. You say it is a small bug, half an hour of work. A number gets agreed on the phone. Inside, the code turns out to be scattered across three files that each half-implement the same feature, there is no version history, the live server has been edited by hand, and the single bug has three separate causes. Now three days are being delivered for the price of one, and both sides resent it. The audit exists precisely to prevent this, and it is why we will not put a number on a codebase nobody has read — a fixed price on unseen work asks one side to carry a risk neither side has measured.

Code gets changed before there is a way back. Inherited projects often have no version history and no backup, and the first instinct is to start fixing. Then a change makes things worse, and there is no earlier state to return to because the earlier state was overwritten on a live server. Committing everything untouched, before anything is attempted, costs an hour and is the difference between a bad afternoon and a destroyed site.

An intermittent bug is declared fixed because it did not happen once. This is the signature failure of rescue work. Something is changed, the form is submitted, it works, everyone celebrates, and the fault returns four days later — now with a bill attached and your confidence in the fix gone. A fault that occurs sometimes must be made to occur on demand before it is touched, and the same trigger must be run afterwards. Anything else is hoping in public.

See where the site stands before you brief anyone.

If the site is already live, start from what it scores rather than from a guess. The audit reports what it checked, what it found, and — the part most tools leave out — what it could not check, and why.

See the website audit Talk about this work

Questions people ask before they commit.

Why do you charge for the audit before quoting?: Because the alternative is guessing at the price of something nobody has looked at, and the guess is always wrong in the same direction. The audit is a small, fixed piece of paid work that produces a written answer — what state the code is in, what is actually causing the fault, roughly how much work it is, and whether it can be fixed at all. You own that document. If you take it to somebody else, it still works.
Can you just give me a fixed price?: Not before the audit, and usually not after either. Rescue work is priced hourly because the unknowns sit inside code we did not write. After the audit we can give you a realistic range and a cap you can set, so you are never surprised — but a fixed price on inherited code is a number invented to win the job, and it gets paid for later in corners cut.
My old developer has disappeared and I do not have the passwords. Is that fatal?: Usually not, but it changes the first day of work. Hosting control panel or registrar access is normally enough to recover the rest. What we need at minimum is somewhere the site actually lives that you can prove you own. If the code exists only on a machine belonging to somebody who is not answering, say so at the start — that is a different conversation about rebuilding, not repairing.
Is it cheaper to fix this or start again?: That is one of the questions the audit answers, and sometimes the answer is start again. Code that has no version history, was edited directly on the live server, and duplicates the same logic in several places can cost more to make safe than to replace. We would rather tell you that in the first two hours than discover it in the third week of your money.
Do you charge more for emergencies?: Yes, when it is genuinely out of hours or requires dropping other work, and it is said before anything starts rather than added to the invoice afterwards. A live store that is down is the most urgent and most expensive category of this work. A bug that has been there for six months is not an emergency, and should not be priced as one.
What if you cannot fix it?: Then you are told, with the reason, and you have paid for hours rather than a promise. That outcome is rare but it is real — some failures live in a third-party service, an expired licence, or a dependency whose author has vanished. Knowing precisely where the wall is has value, because it lets you make the next decision with facts.

Often taken together.

Start with the brief, not the invoice.

Send what you are trying to achieve. You get a written scope, a price and a date — or an honest “this is not the right service for that”.

Talk about Bug fixing & rescue projects All Web Development & Engineering services