Pick up a stalled software project
When the money runs out or the developer moves on, a build is often left half finished. Other times it was put together with an AI tool and nobody is sure what is in it. We take over what is there, find out what works and carry on from where it stopped.
How a project ends up needing rescue
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.
It was written with AI
It came together quickly and people already depend on it. Some of it works, some only looks finished and nobody can say which part is which.
Four steps, in this order
Each step is finished before the next one starts, so nothing gets changed before it is understood.
Review
We read the code, get it running and work out how it was deployed. We also find where the data lives, look for passwords and keys left in the code and test that the backups restore.
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.
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.
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 moves onto a care plan or goes back to your own people.
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 care plans workWhat 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.
It was built with an AI tool. Do you need the prompts?
No. The code is what we review. If you still have the conversations with the tool they can help explain why something was done that way. Plenty of rescues start with nothing but the code and a login.
Does it matter what language it is written in?
Less than it used to. What we need is the code, access to where it runs and somebody who knows what the business needs from it.
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. Looking after it afterwards is a care plan at a monthly amount.
What usually comes next
Problem solving
Brought in for one business problem with software in the middle of it, and the fix that goes with it.
Problem solvingManaged cloud hosting
Hosting we set up, run and keep patched, in a cloud account opened in your name.
Managed cloud hostingCare plans
Support and hosting under one monthly arrangement once the system is stable.
How care plans workTell 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.