Two years in, no end in sight?I pick it up and ship it.

I’m DC. I take over ecommerce and software builds that have drifted: the launch date has moved so often nobody quotes it any more, the budget has gone, and the people who started it have left or stopped answering. First I establish what actually exists. Then we agree, in writing, what ships next and what it costs.

Tell me where it stuck Who you would be hiring

Two blocks joined by a glowing orange bridge of cable. AI-generated image.

Stalled

Recognising a stalled build

How a stalled project looks from the outside

Any one of these can happen on a healthy project for a week. When several have been true for months, the project has stalled, whatever the status report says.

The date keeps moving.Each update ends with “two more weeks”, and the list of what is left never gets shorter.
Demos, but no release.Screens look finished in a meeting and fall over when a real customer or real data goes through them.
Fixing one thing breaks another.Every change needs a round of emergency fixes afterwards, so the team slows down to avoid touching anything.
Only one person understands it.And that person has left, gone part-time, or is billing more hours each month.
No straight answers.Nobody can say what has been built, where the code lives, or who holds the hosting and domain logins.

It is rarely one person’s fault: scope that grew one reasonable request at a time, a platform chosen too early, a key developer who left, testing left to the end.

Keep patching, start again, or read it first

	Keep patching	Rebuild from scratch	Read it, then decide
What happens	Each fix keeps the build alive but brings the finish no closer.	A fresh codebase, easier for a new supplier, and months of work repeated.	A written read of the code, hosting and backlog, then a plan for the first release.
When it fits	Almost never, once a project has stalled for months.	When the foundations can’t carry the business: the data fights every feature or the platform is wrong for the job.	Every time. The finding says whether to finish, partly rebuild or rebuild, and shows the reasoning.
What you keep	The same problems, a little older.	Nothing of what was built.	What works, often the catalogue or the customer accounts, with the part that keeps breaking replaced.
Your way out	None, the hours just continue.	Only once the rebuild ships.	After any stage. You pay for that stage and keep everything produced in it, in your own repository.

Work goes into your repository and your hosting from day one, never mine, and progress is released to a staging site you can log into.

What a read finds

Ten plugins, one price

AI-generatedBeforeAfter

Magento · server time

The fix was deleting nine plugins

Each one took the price, did something to it and handed it on. The last one in the chain reset it anyway, so nine were doing work that was thrown away on every page load.

Before

780ms

After

320ms

How a takeover starts

The first weeks, step by step. Nothing is rebuilt or rewritten until you have read what is actually there and chosen a route.

A free call
The project, the stack, what was promised and what exists. I say whether I can take it on.
Access, in one place
Repository, hosting, domain and third-party accounts. Where the old supplier holds some, I list exactly what to ask for.
A read of what is there
Code, database, servers, open tickets and any tests: the backend audit, applied to an unfinished build.
A written finding
What works, what only looks finished, what is missing, the risks, and two or three routes to a first release.
Your decision
Choose a route, or take the finding to someone else. Nothing further is owed.

The backend audit

Project rescue, in detail

Why builds stall, and how a rescue gets them moving

A stalled project rarely lacks effort. It lacks someone willing to say which parts to stop working on.

Jump to a section

It is rarely one person’s fault
Twelve months inside a failing project, then four to rebuild it
Magento project rescue, and every other stack
Taking over from an agency or developer

Why builds stall

It is rarely one person’s fault

The causes I see most are ordinary. The scope grew one reasonable request at a time and the estimate never did. The platform was chosen before anyone knew what the business needed from it. A key developer left and took the knowledge with them. Testing was left to the end, so every late change is a gamble. Or the supplier was paid for time rather than outcomes, which removes any pressure to finish.

Naming the cause decides the fix. A project stalled by scope needs a smaller first release. One stalled by fragile code needs tests before new features. One stalled by missing knowledge needs the system mapped and written down first.

The project I rebuilt

Twelve months inside a failing project, then four to rebuild it

I spent a year working inside a project that had already run for two years without getting over the line. Patching it kept it alive but didn’t bring the finish closer. Once it was clear more fixes wouldn’t ship it, I rebuilt it myself, and the rebuild was done in under four months.

Any stack

Magento project rescue, and every other stack

Ecommerce builds on Magento and Adobe Commerce, Shopify and WooCommerce. Custom applications in PHP, whether Laravel, Symfony or no framework at all, and in Python with Django or FastAPI. Next.js and TypeScript front ends. Magento is where most stalled ecommerce builds I see sit: usually an upgrade or a Hyvä move that was priced as a few weeks, or a custom module that was never finished.

The previous supplier

Taking over from an agency or developer

Sometimes the original team is still around and a handover is friendly and quick. Sometimes it is awkward. I stick to the technical side: listing what is needed, checking what arrives, and saying plainly if something is missing. Disputes about contracts, payment or who owns the code are for a solicitor, and it is worth checking your contract says the code is yours before assuming it.

I can also work alongside an agency that wants a senior pair of hands to get its own stuck project out of the door.

No second lock-in

How you leave a rescue that isn’t working, and the ones I turn down

What it covers

The rescue is split into stages, each priced before it starts, with a written outcome and a point where you can stop
Work goes into your repository and your hosting from day one, never mine
Progress on a staging site you can log into, not described in a weekly email
Stop after a stage and you keep everything produced in it, with notes for whoever picks it up

What it does not

A project that needs a team of ten from the first week
A build where nobody has decided what the product is: that is a direction problem first, for a fractional or interim CTO
A rescue where the honest answer is to stop and spend the money elsewhere, which I’ll say rather than price

What people ask before handing a project over

How does a takeover start?Behind it · You don’t want to commit before you know what you’re dealing with.

A free call first. Then the access is gathered in one place: repository, hosting, domain and third-party accounts. Then a read of what exists, priced before it starts, and a written finding with two or three routes to a first release, each with a cost and a timescale. You choose a route, or take the finding to someone else.

How much does it cost to take over a stalled project?Behind it · The last supplier’s estimate was wrong.

The first stage is priced before it starts. What comes after is quoted from the finding, so the price rests on the real code rather than a description of it.

Will you just tell me to rebuild everything?Behind it · A fresh start suits the supplier more than you.

Only if the finding shows the foundations can’t carry the business, and the reasoning is written down so you can test it. A partial rebuild is more common.

Can you take over a project another agency built?Behind it · The handover might be awkward.

Yes. Most rescues are someone else’s code. I stick to the technical side: listing what is needed, checking what arrives and saying plainly if something is missing. Disputes about contracts or ownership are for a solicitor.

What if the previous developer won’t hand over the code?Behind it · It feels like the end of the road.

Then the first step is finding out what you can get: what sits in accounts you already control, what the contract says, and whether a copy of the live site exists. It limits the options, but it rarely ends them.

Which stacks do you take over?Behind it · Your stack is old or unusual.

Magento and Adobe Commerce, Shopify and WooCommerce; PHP with Laravel, Symfony or no framework; Python with Django or FastAPI; Next.js and TypeScript frontends.