Your developer used to ship. Requests took days. Now the same requests take weeks, or they get promised and quietly slip. You have started prefacing asks with “I know you’re busy, but.”
You are probably wondering whether they have checked out, or whether they were ever as good as you thought.
Usually neither is true. What has changed is the ratio between two kinds of work, and only one kind is visible from where you sit.
The work you see, and the work you don’t
The work you see is features. A new report, a change to the checkout, a field added to a form. You ask, it appears, you can point at it.
The work you do not see is everything that keeps the system able to accept those changes at all. Security updates. Server upkeep. Fixing the thing that broke because a payment provider changed how their system talks to yours. Untangling a piece of code that has been patched eleven times and now resists a twelfth.
In a healthy system that second category is maybe a fifth of the time. In a system that has been running for eight or ten years without a serious overhaul, it grows until it is most of the week. Your developer is working just as hard as before. Almost none of it surfaces as something you can see.
Why it accelerates
Three things compound.
Every shortcut charges interest. Somebody needed something urgently in 2021, so it got done the fast way with a note to clean it up later. Later never came, because the next urgent thing arrived. Do that a hundred times over eight years and the system is a lattice of temporary decisions holding each other up. Every new change has to be threaded through all of them.
The ground underneath keeps moving. The language your system is written in gets a new version. The pieces of other people’s code inside it get updated, and the new versions do not match the old ones. Your payment provider changes their rules. None of this is your developer’s doing and all of it lands on their desk.
There is no safety net, so everything is done slowly and by hand. This is the big one. If there is no test copy of the system, every change has to be made carefully on the live one. If backups have never been restored, nobody is confident they work, so changes get made even more carefully. Careful is slow. A developer without a safety net does an hour of work in a day, and it is the correct decision on their part.
What to check before you conclude anything
You can establish the shape of this yourself, without technical knowledge. Ask your developer four questions and listen for specificity, not confidence:
- If the server died tonight, how long until we are running again, and when did we last test that? “We have backups” is not an answer. “I restored one in March, it took ninety minutes” is.
- Is there a copy of the system where you can try things without customers seeing? If the answer is no, that alone explains most of the slowdown.
- How do we find out something is broken — do we get told, or does a customer tell us?
- What version of the underlying software are we on, and does it still get security fixes?
None of these are gotchas. A developer with the situation in hand answers all four in a minute. If the answers are vague, that is not an indictment of the person. It is a description of a system nobody has had the time or the mandate to look after.
You can get an independent read on question four without going through your developer at all. Ask the hosting company which versions the account runs and when support for them ends. It is a support ticket rather than a favour, and the answer comes back in writing.
What actually helps
The instinct is to hire another developer. Hold off. Adding a person to a system with no documentation and no test environment costs the existing developer months of explaining, and you get two people moving slowly instead of one.
What helps, in order:
Give them a safety net. Backups that have actually been restored. A copy of the system where changes can be tried without customers seeing them. Alarms that report problems before customers do. Most businesses in this position have none of the three. Putting them in place takes two to three weeks and it is the change your developer will feel immediately, because it converts careful-and-slow work back into normal work.
Move the system somewhere modern. A lot of the invisible time goes into fighting an old server. Getting off it removes an entire category of work permanently. Your web addresses stay exactly as they are, so nothing you have built up in search is affected.
Take the maintenance off their plate for good. Security patches, version updates, the old bugs everyone has learned to work around. This is the part that never fits into a week that also contains feature requests, and it is the part that grows if ignored.
That leaves your developer doing the work you can see — which is the work you hired them for, and the work they are good at.
What this costs
Reading the system properly is $2,400 and five business days. You get a written report, in plain language, that you own. Making a system safe to touch runs from $6,000 and takes two to three weeks. Ongoing maintenance is monthly and you can cancel any month. The full price list is here, including the parts that are free.
We do not take over your product backlog and we do not want your developer’s job. That narrowness is deliberate. Your developer knows your business; we know how to stop the ground moving underneath them.