The software your business runs on, and the person who built it
If your booking or job tracking system has no maintainer, you are running the business on something nobody understands. Here is what to gather before it becomes urgent.
The booking system works. It has worked for four years. Every appointment the business takes goes through it, and the person who built it took a full time job somewhere else in 2023 and stopped answering emails in 2024.
Nobody has touched it since. Nobody knows where the code is. Nobody has ever logged into the server it runs on. There is a login for the admin screen and that is the extent of anyone's access.
It works, so nobody worries about it. And that is the problem, because the day it stops working, the business stops taking bookings and there is nobody to call.
This is more common than people assume, and it is much more serious than an abandoned website. A website going down costs you enquiries. A booking or job tracking system going down stops the business running.
The warning signs
You probably have this problem if more than one of these is true.
- Nobody at the business knows where the source code is
- Nobody has logged into the hosting or the server, only the application itself
- You do not know who pays for the hosting, or which card it is on
- Nothing has been updated in over a year
- Small changes are impossible, so you have stopped asking
- There is no written description of what the system does
- Backups exist in theory and nobody has ever restored one to check
That last point is worth dwelling on. An untested backup is not a backup. It is a hope.
What you should have and probably do not
Five things. If you have all five, you are in good shape regardless of who built it.
Access to the code. Wherever it lives, usually a code hosting service, you or the business should have an account with access. Not the developer's personal account.
Access to the hosting and the database. The account the system runs on, in the business name, with billing on a business card.
Backups you have tested. Both the database and the code. Tested means somebody has actually restored one somewhere and confirmed it worked.
A written description of what it does. Not technical documentation. Two pages in plain English covering what the system is for, what the main screens do, what happens automatically, and what it connects to.
A list of dependencies. What other services it relies on. Payment processing, email delivery, text messaging, any external tools. Each one is a subscription that can lapse and a service that can change and break things.
Gather this before you need it
If the person who built it is still reachable, even barely, this is the moment to ask. A polite request for access and a short handover document is a very different conversation from an urgent one after something has broken.
Send them a list. Code access, hosting access, database access, a description of what it does, and what it connects to. Offer to pay for the couple of hours it takes them to write it up. It is the cheapest insurance available.
If they are genuinely unreachable, work backwards. Look at old invoices to identify the hosting company. Check the business bank statements for recurring charges you cannot account for. Those charges are your systems, and each one is a company whose support team can help you recover an account with the right documentation.
What a review actually looks for
If you bring someone in to take over a system, expect them to want to look at it properly before quoting anything. Anyone who quotes a monthly figure without seeing the code is guessing, and the guess will be either too high for them to win the work or too low for them to keep doing it.
A review should tell you:
- What it is built on, and whether that is current or long out of support
- What is out of date and what that risks
- Where the security problems are, especially anything touching customer data or payments
- Whether the backups are real
- How hard it will be to change
- Whether it should be maintained or replaced
That last one matters. Sometimes the honest answer is that a system has reached the end of its life, and continuing to patch it costs more over three years than replacing it. Anyone who will not tell you that is not being straight with you.
What we will not take on
Worth saying plainly, because it saves everybody time.
We will not take over a system where we cannot get full access to the code and the hosting. Being responsible for something we cannot fully see is a bad deal for both sides, and the first emergency is when everybody finds out.
We will not take on systems built on technology we do not work with. Somebody else will do a better job of it and you should have that person.
Where to start
If you are reading this and recognising your own situation, do one thing this week. Write down every system the business depends on that somebody else built, and next to each one, write down whether you could get into it without help.
Whatever is on that list with a no beside it is your exposure. It is usually shorter than people expect, and it is always better to know.
If you want a second opinion on a system you have inherited, we start with a short call to see what you have got. If it looks like something we can support, we do a technical review and give you a written summary and a monthly quote. The price depends entirely on what is under the hood, so we do not guess at it before we have looked.
Call +1 506-801-9970 or email info@qhike.ca. We serve Fredericton, Moncton, Saint John and all of New Brunswick.