Software project rescue

Pick up a stalled software project

When the money runs out or the developer moves on, a build is often left half finished. We take over what is there, find out what works and carry on from where it stopped.

Sounds familiar

How a project ends up half finished

Nobody sets out to leave a build part way through. It tends to happen one reasonable decision at a time, and then the code sits.

The developer moved on

The one person who understood it has left without writing down how it works. The code is still there, but the reasons behind it are gone.

Nothing runs

There is no documentation, no environment that works and no record of how it was ever deployed. Getting it running again is the first job.

Nobody is sure what is finished

Some of it works, some was started and abandoned and some was never begun. From the outside it is hard to tell which part is which.

How a rescue goes

Four steps, in this order

Each step is finished before the next one starts, so nothing gets changed before it is understood.

1

Review

We read the code, get it running and work out how it was deployed. We also find where the data lives and test that the backups restore.

2

An honest read

A written summary in plain language of what works and what does not. Then whether the code is worth carrying forward or whether some part of it is better rewritten.

3

Make it safe to change

We put in what the project was missing so changes are safe. Usually that means source control, a repeatable build, a place to test and proper logging.

4

Carry on

Development picks back up from where it stalled, in small pieces you can log in and use. Once the system is stable it settles into ordinary support, or it goes back to your own people.

What you get

An honest answer on what to keep

Sometimes the honest read is that most of the code is sound and only needs finishing. Sometimes it is that part of it should be written again. We tell you which, with the reasons, before any of the larger work is agreed. You get that answer even when it means less work for us.

How ongoing support works
Questions about rescue

What people ask first

Do we have to carry on with you after the review?

No. The review stands on its own. Some people use it to decide what to do next or to make the case for a budget. Nothing is conditional on continuing with us.

There is no documentation. Can you still work with it?

That is the usual starting point. Code with no documentation and nobody left to ask is most of what a rescue is. We work out what is there by reading it and running it, and we write it down as we go so the next person does not have to.

What if it is written in a language you do not use?

We work in C#, .NET, JavaScript and Node.js, on SQL Server and MongoDB. We do not work in C, C++ or Rust. If the project is written in one of those, we say so in our first reply.

How do you charge for a rescue?

There is no rate card, because no two stalled projects are in the same state. We agree the review first, then price the rest once we both know what it involves.

Tell us where it stalled

A few lines is enough. What the project was meant to do, what state it is in and who built it, if you know. We will come back with questions and an honest first read.

Get in touch Or email sales@tektology.com directly.