Your team no longer has time to maintain your tools, or your developer has left
Your tools still run, but nobody looks after them any more.
Your team is still there, but it has no time left
This is the most common case. Your developer, or your small technical team, does good work. But all their time goes into new projects and day-to-day requests: an export for accounting, an account to set up, a bug to fix before lunch.
The tools already in place always come second: the quoting tool, the internal application. Updates wait for next quarter, the clean-up of the code never makes it onto the schedule, and one person fights the fires.
Nobody has done a bad job. That is all technical debt is: postponed updates and shortcuts taken to deliver on time, piling up until every change becomes risky.
Or your developer has left
The other case: the tool was built and looked after for years by one person, a freelance developer, an employee, sometimes a relative. Then they left, and the handover took one afternoon, or never happened at all.
The tool still runs, but where the code is, how it is put online, which job runs at night: none of it is written down. And nobody dares touch it any more.
What it is already costing you
As long as it runs, nobody thinks about it. But the bill is already running, in hours nobody counts.
-
The key person
If the person who knows your tool leaves tomorrow, or is off sick the day it breaks, who fixes it, and how long does it take?
-
Interrupted projects
How many times a week does your team drop a new project to patch up an old tool?
-
Requests on hold
How many changes have been waiting for months, for lack of someone to make them?
-
Postponed updates
When were the server and the libraries last updated? Meanwhile, new security flaws keep being disclosed.
Do the sum: the hours spent firefighting each week, times 46 weeks, times what an hour of your team costs. Almost nobody knows that figure. It is the first one we measure.
Secure it this week
Whether your developer is overloaded or gone, these points take a few hours of organisation, not a project.
- A list of your tools. Every in-house tool the business depends on, who knows it best, and the updates your team has been putting off for months (language, framework, server). That list is your technical debt, in writing.
- Two people per login. Application, server, database, third-party services: every administrator login should be known to two people in the company and kept in a shared password manager.
- Source code. In a repository (GitLab, GitHub, Bitbucket) in your company's name, in the version running in production. Not only on a server or a laptop.
- What is not written down. How the tool is put online, the night-time jobs, the backups and how to restore them. An hour spent writing it beats days of digging during an outage.
- Hosting and domain name. Whose name are the accounts in, which card pays for them, when is the domain due for renewal? The holder should be your company, not an employee or a developer.
- If your developer has left. Get in touch while the relationship is good: ask for the logins, the code and an hour for your questions, and offer to pay for that time. Close their personal logins now; credentials the application itself uses should be changed with someone who knows where they are configured, or the tool goes down. And re-read the contract: who owns the code? If in doubt, ask a lawyer.
The full checklist, and why each point matters: taking over an application that nobody maintains any more.
An extra pair of hands for your team, not a replacement
We work alongside your team, on the tools it no longer has time to look after. Your team keeps the new projects.
We take the existing tools off your team's plate: maintenance, security updates and the clean-up of the code (the refactoring), at a fixed price. Every fix comes with its documentation, so the day your team takes a tool back, it is up to date and documented. We ask your team for a short handover, and we keep it informed of what we change.
If your developer has left, we do the same work without them, starting with recovering the access and the code. If they are willing, we are glad to involve them in the handover: they know things no code will tell you.
It is probably not for you if your team has the time to look after its tools and keep them evolving.
First, an outside view
Your team knows the tool from the inside, but has no time to step back. The health check gives you that outside view in two weeks: what the tool costs you, what will break first, and where to start.
Or has your IT provider stopped answering?
Every situation: legacy application takeover.