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.
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.
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 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 settles into ordinary support, or it 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 ongoing support worksWhat 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.
What usually comes next
C# and .NET support
Keeping older C# and .NET systems patched and moving them off versions that have fallen out of support.
C# and .NET supportManaged cloud hosting
Hosting we set up, run and keep patched, in a cloud account opened in your name.
Managed cloud hostingOngoing support
What looking after a system involves once it is stable, and what the first review covers.
How support worksTell 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.