Who owns your systems after launch, and where each model lets go

Most of the owners who call me are in the same position. Their site launched a year or two ago, the invoice was paid, and the people who built it moved on. Somewhere after that, a question was settled without anyone asking it: who owns this now? Not who holds the passwords. Who notices when it quietly stops working. That is the real freelancer vs agency question, and price is not part of it.

When an owner asks me to take over a system, I have rarely met the people who built it. By the time an owner calls, the builder has usually been gone a couple of years. Nobody was negligent. The way the work was bought simply kept nobody attached to it once it was finished.

I have done this work since 2014, inside each of the usual answers. I freelanced for years, I have been the engineer inside a business, and I spent four months inside an agency. Now I run businesses’ systems on a monthly retainer, the arrangement the market calls fractional engineering. So I can describe where each model lets go of your system without guessing, including the parts that argue against hiring me.

Ownership is whoever is looking when nobody has asked

Ownership after launch is not the name on the contract. It is the person responsible for the system between your requests: the one who checks that last night’s backup would restore, notices when a scheduled job stops, and knows why the server is set up the way it is.

Most businesses have never written that name down. When I ask an owner to, it comes back blank, or names someone who left. That blank is the real gap, whichever way you bought the build.

Systems fail in month seven, not on the day they are built

Launch day is the most watched day a system will ever have, and anything visibly broken is fixed within the hour. Systems fail in month seven, quietly, when nobody is watching.

A scheduled job stops. An integration starts dropping one record in twenty. A security update waits, because the person who would apply it is on another project. The cost is rarely an outage. It is months of something slightly broken while everyone assumes it is fine, usually found by a customer.

What separates the four ways of buying engineering is what each does in month seven. For two of them, the honest answer is nothing, by design.

A freelancer’s ownership ends the week the invoice clears

Much of the best work on the web is built by one person on a contract, and I was that person for a long time. The trouble is one moment the model has no answer for. About a week after launch, the relationship changes quietly from “someone is working on your system” to “someone will help if you ask and they are free”.

Nothing goes wrong that week. It goes wrong in month four, when your email gets a reply five days later because they are deep in another client’s project, and in month nine, when the reply says they have moved on and can recommend a friend. By then the system has run unattended for most of a year. If the replies have stopped altogether, what to do when your developer stops replying sets out what to secure first.

The contract rarely helps. Every freelance contract I have seen is precise about delivery and vague about afterwards, so the afterwards becomes an understanding, and understandings decay at the speed the freelancer’s calendar fills.

Backups ran every night for two years, into a folder anyone could download

A site I inherited had been backed up every night for two years. The plugin was configured correctly and the dashboard was green. Every backup had been written to a directory the web server would hand to anyone who asked, so anyone could have downloaded the whole database, and every customer record in it.

Nobody had done anything wrong. Taking backups is a task. Thinking about where they land is an ongoing responsibility, and only one of those was in scope. A freelancer sells you a finished thing. A retainer sells you an ongoing state. The gap between the two is where most systems quietly rot.

Even so, a freelancer is often the right hire: for finite work that needs no tending (a campaign landing page, an integration built to a specification, a design job), for a system simple enough to survive inattention when budget binds, or for one hard problem that needs a specialist. A retainer you cannot comfortably afford is worse than a good freelancer you can.

If you hire one, negotiate the afterwards before the final invoice, while you have leverage. Ask for the runbook: how to restore the site, rotate the credentials and check that the scheduled jobs ran. Ask for the credentials, and the licence keys for anything paid for, in accounts you control (a site with no keys to hand over may be running pirated plugins). And ask for a written answer to what happens if you email in six months.

At an agency, ownership spreads across a team until nobody holds it

I spent four months inside an agency: long enough to understand the economics, short enough to know I did not want to stay. The people and the process were competent. The model is simply built to finish: scope, staff, deliver, close, move the team on. Support after that is shaped like a ticket.

Your problem enters a queue, is triaged against a scope written before anyone knew what would break, and goes to whoever is free, often not whoever built the thing. They read themselves in, make the change and move to the next account. That is how a business serving forty clients has to work. But four people have now touched your system and none of them owns it, and nobody has held the whole of it in their head since the day it was built.

When I take over a platform like that, I lose the first few days working out what is load-bearing: which plugin matters, which scheduled job matters, which clever thing from 2023 everything quietly depends on.

There is a quieter version, and it is the one that made me leave. Much agency delivery is a commercial template, adjusted and handed over as a bespoke build, less from deception than because the margin requires it. If nobody on the delivery team wrote the thing, nobody there can explain it. You bought a configuration of somebody else’s.

You can usually tell from the outside. A page that ships half a megabyte of markup, carries the fingerprints of two page builders and takes a moment to settle was assembled rather than built. If it also feels slow, the guide to a slow site has a ten-minute check.

Scheduled jobs that had never once run, on a screen that said they were scheduled

On a platform I took over, a set of scheduled jobs had never run. Not failed, not errored: never run, not once, since the day they were configured. WordPress fires its scheduled tasks from page loads, and the site was too quiet to trigger them. The settings screen showed them as scheduled the whole time, and several people had looked at it and moved on.

Every interaction with that system was competent. It still did nothing for years, because checking that a thing actually happens is not a task anyone is assigned. You only do it if the system is yours.

An agency is still the right call when the work is large, defined and finite: a brand redesign with a deadline, a migration that needs six people in parallel for eight weeks, a campaign site for one quarter. One person cannot buy you that capacity at any price. For a defined project, an agency’s process (documentation, handover notes, an account team) fairly answers who will know why it was built that way. For a system that has to keep working, a process is not a person.

An in-house hire owns everything, in one head and one discipline

Sometimes hiring is right. But the figure on a job advert is not the cost of an engineer.

A developer on a €90,000 salary in Germany costs €110,000 to €115,000 a year fully loaded, roughly €9,200 to €9,600 a month, once employer taxes and contributions, pension, equipment, licences, recruitment fees and management time are counted. And a senior hire usually takes months to find before they write a line.

That buys one person in one discipline. A backend engineer is rarely also your server, data and automation person. That is three or four salaries, which almost no business under fifty staff carries, and the gaps between those specialities are where systems fail.

Then there is utilisation, the cost nobody prices in. Most established businesses outside software do not have forty hours a week of engineering work. They have bursts: a build, a migration, a bad week. In between, a full-time engineer is idle, inventing work or drifting into projects nobody needed.

Ownership under a hire is real while it lasts. The failure mode is concentration: everything lives in one head, and that head can resign, taking every compounded year with it. Hire when technology is what you sell, when there are genuinely forty hours of engineering every week, or when you need someone in the office daily.

On a retainer, running the system is the whole engagement

Here the engagement does not end at launch, because the engagement is the running of the thing: the person who built the system monitors it, patches it, improves it and answers when it breaks.

It works for a system somebody else built, too. Where one already exists and works well enough, it is adopted as it stands, and from a fixed date one person is answerable for it. Most owners asking this question have already paid for a system they intend to keep.

What changes is the shape of the arrangement:

• It is always the same person. After a year on a platform I know which part is fragile, what was deliberately left simple, and which decision from eighteen months ago is about to become a problem. That is continuity, not talent, and no rotation can manufacture it.
• The scope is the outcome, not the ticket. If a problem sits between a customer and the thing you sell, it is mine. Small things get fixed at fifteen minutes instead of growing into two-hour problems, because the fee is fixed each month, not a bank of hours.
• Somebody is watching between your requests. A freelancer responds to what you notice. A retainer includes noticing on your behalf.
• Knowledge compounds instead of resetting. Each month I know the system better, so changes get cheaper. Under a rotating team, each new person pays the orientation cost again, and so do you.
• Leaving is designed for. The documentation is written as the work happens, so someone else could take over. The domain, the DNS and the code repository sit in your own accounts from the first week, and so does the server unless you choose to host with BespokeForge, and a build’s finished work goes into them at handover, once it is paid for.

The failure mode is capacity. I am one engineer, with no account managers and no juniors, and I take no more than three of these engagements at a time. I cannot parallelise: if you need four things built at once, I am the wrong answer, and I will say so on the first call.

What a retainer covers is on the Operate page, and how a retainer month differs from a maintenance plan is in maintenance plan or retainer.

An agency is optimised to finish. A retainer is optimised to still be here. Most businesses discover which one they needed in month seven.

Two faults in one week, and neither would ever have become a ticket

On a platform I run, two problems surfaced in a single week, and neither raised a ticket.

The routine that clears the cache had been calling a method that no longer existed and swallowing the failure. Every “cache cleared” it reported was false, and a week of my own measurements had been taken against a cache nobody was clearing.

Separately, the cache directory had changed owner, so the preloader, which builds cached pages before visitors ask for them, could not write to it. Nothing logged a complaint.

A ticket queue only shows what a person noticed and thought to report, and nobody noticed either of these. I found them because I was still there, not because I am heroic.

A dashboard of scores is worth having. The interesting part is knowing what they were an hour ago, what moved them and what is still unfinished, and all of that happens after launch.

Each model lets go at a different moment

The rows that decide it are the last three.

What you are comparing	In-house hire	Agency	Freelancer	Engineer on retainer
What you are buying	A person’s whole working week	Delivery of a defined project	A finished piece of work	Ongoing responsibility for a system
Who holds it after launch	The hire, while they stay	Nobody in particular, once the project closes	You, from handover	The person who built or adopted it
Monthly cost	€9,200 to €9,600 loaded	€1,500 to €19,500 on retainer	Per project	A fixed monthly fee
Disciplines covered	Usually one	Several, through specialists	Usually one	Four, through one generalist
Knowledge over time	Compounds, then leaves with them	Resets as staff rotate	Leaves at handover	Compounds
Fails when	They resign	The project closes	Their calendar fills	You need several things built at once
Right when	Technology is what you sell	The work is big, defined and finite	The job has a real edge and finishes	The system has to keep working

Choosing wrong is not a disaster, it is a slow tax

Most businesses do not choose between these four. They fall into the one they used last time and spend two years finding out what it does not cover. If you suspect you are in the wrong one already, the signs you have outgrown your web vendor are a quick count.

Choosing wrong is rarely a disaster. An early hire carries a salary through the quiet months. An agency on ongoing work charges for delivery capacity you stop needing the week after launch. A freelancer on a system that must keep running leaves it with you by month nine. A retainer on a simple brochure site buys attention nothing needs: a good maintenance plan fits there, or Upkeep if the site was built or rebuilt here, and a site that barely changes may not need to be a WordPress site at all. Every model works. They fail in different directions, and most businesses pick by habit rather than by which failure they can afford.

For established businesses outside technology, the sequence that works is boring and rarely followed. Build with whoever suits the size of the job. Put someone on running it the day it launches, not the month it breaks. Hire in-house when you can say what that person will do every day for a year without inventing tasks.

The common mistake is skipping the middle step, so the system runs unattended until something breaks badly enough to notice, which is the most expensive moment to find out. If you already pay someone monthly and are not sure what for, how much website maintenance should cost has six questions to put to them.

Three questions settle it, and price is not one of them

Answer them in order. The first you can answer honestly decides it.

Is technology what you sell? If it is, hire in-house and stop here.

Does this work end? If it does and it is big, hire an agency. If it does and it is contained, hire a freelancer.

Once it is live, whose job is it to look at it when nobody has asked? If that question is uncomfortable, the problem is not who builds it. Nobody owns it, and another build will not fix that.

Everything else, price included, follows from those three.

One fault in month seven, four different endings

Take an ordinary fault. In month seven, the nightly job that copies new orders into your accounting tool stops. Nothing errors. Every page still loads.

With a freelancer, you find out when your bookkeeper asks why the month does not reconcile, and your email gets a quote five days later.

With an agency, someone meeting your system for the first time restarts the job and closes the ticket inside the service level. Why it stopped is not part of the ticket, so it can stop again.

With an in-house hire, it is fixed the day someone mentions it, if the job sits in their discipline and they are still with you. If they left in month five, you get the freelancer’s ending without the freelancer.

On a retainer, the check that the job ran fails before your bookkeeper notices. The job is put right, the cause is fixed, and the monthly note says in two sentences what happened.

Only one of those endings involves anyone looking before you asked. So put the same test to any provider, including me: walk me through what you do for me in month seven. A freelancer will talk about new projects and an agency about support tiers. Someone who owns the system will describe an ordinary month: what gets monitored, what gets improved, what the monthly note says, and who answers out of hours. How specific the answer is tells you whether ownership after launch is a service or a reassurance.

If your systems sit in the ownerless stretch after somebody’s handover, the route here is adoption, not a rebuild. It starts with a free conversation of about twenty-five minutes, which decides whether the looking is worth doing. The looking is the paid audit: it ends in a written document you keep whatever you decide, and its fee is credited in full against a build or a retainer that follows. The fee is on the pricing page, the four disciplines are on the services page, who you would be dealing with is on the About page, and the audit’s own page sets out what it covers.