Five signs you have outgrown your web vendor, and what to change

None of the owners I have worked with decided one morning that their business had outgrown its web vendor. It arrives in pieces, usually during a bad week. The site goes down on a Thursday and the first reply comes from a stranger. Two suppliers each say the problem belongs to the other. Somebody on your team spends Friday afternoon copying orders from one tool into another. By the time the pattern is too plain to ignore, you have already paid for it in downtime, workarounds and hours your staff should never have spent. Many owners then reach for a fractional CTO, or start outsourcing web development to someone new, and most of them need an engineer first.

I have built and run business systems since 2014, and the pieces are much the same from one business to the next. Below are the five that matter, what they have in common, and what to do about them: whether you need an adviser or an engineer, how to change without paying twice for a system you already own, and how to test the replacement before you trust it.

Five signs the arrangement no longer fits

Read these against the last six months. One of them on its own is a bad week. Three or more is a pattern, and the pattern is already costing you something.

Every problem starts from zero in a ticket queue

When something breaks, you fill in a form. Somebody you have never spoken to triages it. The person who eventually replies asks questions that show they are meeting your setup for the first time. That is not poor service. A ticket system is how support has to work for a provider with hundreds of clients, and that is exactly the problem: at that size nobody knows your business, so every incident starts from the beginning and you pay for the reading-in each time.

The gaps between suppliers belong to nobody

The hosting company says it is a site problem. The developer says it is a hosting problem. The person who set up the integrations left the agency last year. When the infrastructure, the website, the data and the automations come from four different suppliers, each one answers for its own piece and nobody answers for the joins. The joins are where business systems actually fail: the email that stopped arriving after a DNS change, the plugin that did not survive a server update, the form whose entries never reached the CRM.

Your team has become the integration layer

Somebody copies data from one tool into another by hand, every week, because nothing connects. Orders get retyped. The monthly report is put together in a spreadsheet from three exports. When people do repetitive transfer work between systems, your staff have become the middleware, and you are paying salaries for work that software should be doing quietly in the background. It also fails the way people fail: in holiday weeks, under pressure, and without an error message.

Every small improvement costs a round of quotes

Small fixes never happen, because each one needs a scoping call, a proposal and an invoice large enough to justify the overhead. So the site drifts. The content goes stale, the pages get slower (why a site slows down is its own guide), and the form nobody fixed stays broken. A healthy system improves in small steps, all the time. An arrangement where every step costs a procurement cycle guarantees decay, because small problems never clear the bar for a quote. They pile up instead.

The people who built it have moved on

This is the most common of the five. The build was fine, but the builders left. The freelancer is on other projects, the agency team has rotated, and the final payment marked the end of anyone caring what happened next. Your business now depends on a system that nobody you can reach fully understands. That is not a criticism of the builders. It is what an engagement shaped like a project produces by design, and who owns your systems after launch goes into it properly. If the developer has stopped answering altogether, start with what to do when your developer stops replying.

The shape of the arrangement is wrong, not the vendor

Look at the five again. None of them is really about a bad supplier. Most describe a competent provider doing exactly what its model is built to do. A support desk with hundreds of clients has to run a queue. A project team has to move on when the project closes. A specialist has to stop at the edge of their speciality. The trouble starts when those shapes are applied to a business that needs something else: continuous, accountable ownership of the systems it earns its money through.

That is why swapping one vendor for another of the same kind rarely helps. It moves the next bad week onto a different invoice. It does not remove it. What removes it is a different arrangement, and its parts line up with the signs almost one for one:

• One person who already knows your setup, so an incident starts from what they know rather than from a form.
• Infrastructure, website, data and automation held as one connected system, so the joins belong to someone and there is nobody left to point at.
• Integrations built properly, so your staff stop being the middleware.
• A fixed monthly fee instead of counted hours, so that a small improvement within the agreed scope joins a queue rather than waiting for a proposal.
• The same person running the system next year as this year, with the documentation written as the work happens rather than in a rush at the end.

What the market calls fractional engineering is a version of this arrangement. You have probably met the pattern in other departments: a finance director for two days a month, a marketing lead without a director’s salary. The engineering version is capability shared across a small number of businesses instead of employed by one. The sharing describes the allocation and the cost. It does not describe the accountability, which cannot be divided: one engineer stays with you on a monthly retainer and answers for building and running your systems. The label matters less than the shape.

The arrangement exists because of a gap most established businesses fall into, somewhere between “my nephew builds websites” and “we hired a CTO”. Your site, your servers, your customer data and the automations that hold your week together all matter commercially. They do not add up to forty hours of engineering every week. Hire full time and you pay for the idle hours along with the busy ones (the cost of a full-time hire against the other options is set out in the guide to ownership after launch). Hire nobody and nobody owns the systems, which is how most businesses come to recognise the list above.

The difference from a support contract is ownership. A support desk resolves tickets against a system nobody there has met. An engineer on a retainer runs a system they built or audited themselves, which changes the speed and the quality of every decision made about it. What an ordinary month contains, and how it differs from a maintenance plan, is in maintenance plan or retainer; what each of BespokeForge’s retainers covers is on the Operate page.

You probably need an engineer before you need a CTO

Once owners see the shape of the problem, many reach for a bigger title. Search for a part-time CTO (the usual term is a fractional CTO) and you will find hundreds of consultants offering strategy days, architecture reviews and roadmap sessions. It is useful work. But when an owner tells me they are thinking about one, my first question is always the same: who is going to do the engineering?

A part-time CTO is an adviser. They help you make technology decisions: build or buy, how to structure a team, whether the architecture will hold as the business grows, what to ask your vendors. They work in sessions and documents. The good ones earn their fee when you face a question that is genuinely strategic: an acquisition, a decision to rebuild, a hiring plan for a product team.

What they do not do is patch your server on a Tuesday night, rebuild the automation that silently stopped running, or notice that the database has been getting slower for three weeks. Advice does not keep systems up. Every one of the five signs above is a delivery problem, and a strategy document does not solve a delivery problem.

An ordinary Tuesday tells you which one you need

Strip the titles away and ask what the business needs on an ordinary Tuesday. If the answer is decisions, board-level guidance and a technology strategy your investors will read, you want the adviser. If the answer is that the site should be fast, the backups should be real, the integrations should not fail silently and somebody competent should own all of it, you want the engineer.

A rough sizing rule, and it is a rule of thumb rather than a finding: businesses under about fifty people almost always need the engineer first. The strategy questions they face are real but occasional. An engineer who runs your systems answers them as part of the work, with opinions grounded in your actual setup rather than in a slide deck.

Larger businesses can have both, in the right order

Above a certain size, both is a sensible pairing: an adviser setting direction and an engineer delivering it. The order matters, because strategy applied to systems nobody maintains is decoration. If you can only pay for one, pay for the one that keeps the lights on, then buy the thinking once there is something stable to think about. And if the honest answer for your business is that you need a CTO rather than me, you will hear that on the first call.

Changing the arrangement does not mean rebuilding

The fear that keeps most owners with a vendor they have outgrown is the rebuild. They have already paid for a system, it mostly works, and changing supplier sounds like paying for it a second time. Usually it is not.

There are two ways in. The first is build and run: the system is built here, and the same person runs it afterwards. The second is adopt and run: the system you have works well enough, it is taken on as it stands, and from a fixed date one person is answerable for it. Nothing gets built twice. A business that has outgrown its vendor has generally already paid for something it means to keep, so adoption is the usual route at this stage.

What I do not take on is salvage, meaning a system somebody else broke, handed over to be rescued. That is a different job with a different failure rate, and being plain about the line is what keeps adoption honest. Telling the two apart is part of what the audit is for. A system with dated code and thin documentation can still be sound. A system running nulled plugins needs a much closer look before anyone takes responsibility for it (how to check yours). Sometimes the finding is that the platform itself no longer fits what the business does, and then a rebuild is a decision made on evidence rather than a reflex (when a website should not be WordPress covers the usual reasons).

Get the accounts into your own name before you move

Whoever you move to, the move is easier if you already hold the keys. Unless a client chooses hosting here, the client holds the server, the domain, the DNS and the repository in their own accounts from the first week, and a build’s finished work goes into those accounts at handover, once it is paid for. A vendor that holds any of them in its own name turns changing supplier into negotiating with one, so that is the first thing to fix, whatever you decide about the vendor.

Nor should the replacement lock you in. A retainer here runs for a minimum of three months, the time it takes to reach a steady state, then month to month with thirty days notice either way. The only good reason to keep paying is that leaving someone who already understands your systems makes no sense.

A thinly spread engineer is a ticket queue with one name on it

This arrangement has its own failure mode, and you should test any provider for it, me included: over-subscription. An engineer serving fifteen businesses is not sharing their time carefully. They are spread thin, and you will feel it the first time two of those businesses have a bad day at once. At that point you are back in a queue. It is shorter, and it has one name on it, but it is still a queue.

Ask how many businesses they carry at once. Three is my number, because three is where every system still fits in one head. BespokeForge is one engineer, working remotely across Europe and Africa, with no account managers and no juniors, so the limit is not a sales line. It is what one person can hold. The defined products, SearchOps and Upkeep (the lighter routine for a system built or rebuilt here), take no place in that count, because they are built to need almost none of the attention the limit exists to protect. Whatever a provider’s number is, it should exist, it should be stated, and it should be small.

The other limit is capacity. One person cannot run several builds in parallel. If you need a product team shipping every day, or a large amount of new work delivered at once, you need a team, and a single engineer is the wrong answer however good they are.

It fits when revenue runs through systems nobody owns

The arrangement fits if most of these are true. Your revenue depends on the site and the systems behind it working. Things have broken before, and nobody could say whose job it was. You are past the cheapest-option stage and nowhere near justifying a full-time engineering salary. You want one accountable person rather than a rotation of strangers. And you either have a system you intend to keep, or a clear reason to build a new one.

Beyond the capacity limit above, it does not fit in two cases. If technology is what you sell, hire in-house, because you need that person there every day. If your systems do not yet matter to revenue, a good maintenance plan is the right purchase, and a retainer would be money spent on attention nothing needs. What website maintenance should cost sets out what that plan should look like.

And sometimes the vendor is fine. The signs came from one bad quarter, or from a gap that a single direct conversation with the current supplier would close. That is a good answer, and cheaper than any change.

Four things to do before you talk to anyone

None of this needs a provider yet. Each of these makes the next decision easier, whoever you end up working with.

1. Count the signs. Go through the five against the last six months and write down which ones you recognised, with the incident that proved each one.
2. List the last three things that broke. For each one, note who noticed, how long it took to fix, who fixed it and what it cost in staff time. The answers show where the gaps between your suppliers are.
3. Check whose name is on the domain, the DNS, the server and the repository. If any of them sits in a vendor’s name, ask for it to be moved to yours now, while the relationship is still friendly.
4. Count the manual work. Every task where someone copies data between tools by hand is an integration that does not exist yet, and a rough count of the hours tells you what that missing layer costs each month.

If you counted three or more signs, the next step is to find out what the pattern is costing and what changing it would involve. With BespokeForge that starts with a free conversation of about twenty-five minutes, which establishes whether this is a problem I can solve and which of the two routes applies. It is shallow on purpose: it decides whether to look, and it is not the looking. If your current vendor is fine, you will hear that too.

The looking is the audit. It is paid, its fee is fixed before it starts (the pricing page lists it), and it ends in a written document you keep whether anything follows or not. If a build or a retainer does follow, the fee is credited against it in full. The four disciplines BespokeForge works across are on the services page, who does the work is on the about page, and the audit’s own page sets out what it covers.