Solutions / Small business
Most small businesses do not need an IT department. They need one competent team who knows their systems, answers the phone, and does the unglamorous work that prevents the expensive week.
Someone accountable for the systems the business runs on. In practice that means the website works and can be updated, the server behind it is patched and backed up, the obvious security exposure is closed, and someone answers when something breaks. Most small business technology problems are ownership problems rather than complexity problems.
The situation
The website was built a few years ago by someone who is no longer available. It still works. Nobody is entirely sure how, and small changes have become a project.
The hosting arrangement is whatever was chosen at the time. Someone has the login. The backups may be running. Nobody has ever restored one.
Security is not ignored so much as unowned. Updates get postponed because something broke once. There is a general sense that this is probably fine, held with more hope than evidence.
None of this is negligence. It is what happens when technology is a means to running a business rather than the business itself, and there is nobody whose job it is to look after it.
Where the time goes
It is usually several small ones that each look tolerable in isolation and are expensive together.
Updating a price, adding a page or changing a phone number requires finding a developer. So it does not happen, and the site drifts further from what the business actually does.
A backup exists somewhere. Whether it contains everything, and how long a restore would take, is unknown until the day it matters.
The original builder has moved on or stopped responding. There is no handover, no documentation and no obvious replacement who understands the setup.
An update broke something once, so updates stopped. Every month the gap grows and the next update becomes riskier, which justifies deferring it further.
It exists and it describes the business in general terms. It does not answer the questions a customer actually searches for, so it is a brochure rather than a channel.
How the four disciplines apply here
Not every engagement covers all four. Which ones matter, and in what order, is the useful part of the conversation.
01 / Build
Fast, straightforward to update by a non-technical person, and structured around what customers ask rather than around a template. Frequently the improvement is a rebuild of the structure rather than the design.
02 / Run
Patching, monitoring, certificate renewal and backups that have been restored at least once. This is the boring work that prevents almost every avoidable outage.
03 / Protect
Close what is exposed, protect the accounts that matter, keep the software current, and be able to recover. This covers the overwhelming majority of what actually happens to small businesses.
04 / Grow
Not a content programme. A small number of pages that answer the questions your customers actually ask, on a site that is technically capable of ranking for them.
Where the site is hosted, who has access, what is running, whether the backups work. A surprising number of businesses do not have this written down anywhere.
Expiring certificates, failed backups, unpatched software, exposed services. This first pass is usually where most of the risk is removed.
Either repairs to the existing one or a rebuild, depending on which is genuinely cheaper. We will tell you honestly which.
Patching, monitoring and backup verification on a schedule, so the situation does not quietly return to where it started.
Performance, content and search work added where there is a commercial reason, not as a standing monthly fee for its own sake.
Honesty about fit
A mismatch discovered in month three costs both of us more than a direct answer now.
Probably not. The work scales down more easily than people expect, because a small business usually has one site and one server rather than a complicated estate. What matters is whether the systems genuinely matter to the business, not the size of the company.
Usually yes. We start by documenting what exists, which is the step that was skipped originally. Occasionally we find something built in a way that makes a rebuild cheaper than maintaining it, and we will show you the reasoning rather than just recommending the bigger project.
Not automatically. If the current hosting is adequate and someone can be responsible for it, staying is cheaper and less risky. We recommend moving when the hosting is genuinely the constraint, and we will explain specifically why rather than asserting it.
Less than most providers will propose, and more than nothing. A useful frame is what a week of downtime or a compromised site would cost you, and then spending a fraction of that on prevention. For most small businesses the ongoing figure is modest once the initial backlog is cleared.
Yes. Call rather than email if the site is down or you suspect a compromise. Response is faster when we already know your systems, which is one of the practical arguments for an ongoing arrangement rather than calling us cold.
A short technical conversation is usually enough to tell whether we are the right people and what the first useful piece of work would be.