The day after launch, who wakes up caring whether it still works?
Here is a question that decides more about your technology than any framework choice: the day after launch, who owns the system? Not who has the passwords. Who wakes up caring whether it still works? I have spent twelve years watching each of the usual answers play out, and the pattern is consistent enough to write down.
The freelancer: ownership ends at handover
A good freelancer can build you something excellent. But the freelance model is project-shaped: scope, deliver, invoice, next client. Ownership transfers to you at handover, whether or not anyone in your business can carry it. Six months later the dependency updates have stopped, the plugin that needed patching was not patched, and the person who understood the build is two clients away. None of that is bad faith. It is simply what the shape of the engagement produces.
There is also the single-skill problem. The person who built your site is rarely the person who should be hardening your server or designing your data flows, so ownership fragments across specialists who have never met each other.
The agency: ownership diffuses
Agencies solve the skills problem by having many people, and create a different one: nobody in particular owns your system. The account manager owns the relationship, the developers rotate with the sprint board, and the person who made a critical decision in March may not be there in September. Support exists, but it is ticket-shaped. Your problem enters a queue, is triaged by somebody meeting it for the first time, and is closed against a service-level agreement rather than an understanding of your business.
You can buy real attentiveness from an agency. It tends to sit in retainer tiers priced for businesses much larger than the ones this is written for.
The fractional engineer: ownership is the product
Fractional engineering inverts the question. The engagement does not end at launch, because the engagement is the running of the thing. The person who scoped the systems builds them, and the person who built them operates them: monitoring, patching, improving, and answering when something breaks. Continuity is not an add-on to any of that: it is the entire content of the engagement.
It also works the other way round. Where a system already exists and works well enough, it gets adopted rather than rebuilt, and from a fixed date one person is answerable for it. That route matters here, because most owners asking this question have already paid for a system they intend to keep.
What that looks like on a real engagement
Ampy has been a client since April 2025, starting with a single electrician site that became the pattern for a network of them. The multi-region platform at the centre of it was built from October 2025 and went live in February 2026, so it is one project inside a longer relationship rather than the whole of it. Dedicated Linux servers, DNS and routing, deployments, the caching layers, a custom structured-data engine. Everything since that launch has been operations.
Two problems surfaced there in a single week, and neither of them raised a ticket. The cache purge routine had been calling a method that no longer existed, and swallowing the failure. Every “cache cleared” it reported back was a lie, and a week of measurements had gone against a cache nobody was actually clearing. Separately, the cache directory had gone root-owned, so the preloader wrote zero pages for seven and a half minutes while real visitors were served uncached PHP. Nothing logged a complaint anywhere.
A ticket queue can only ever show you 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.
The visible side of the same engagement is a desktop Lighthouse score of 98 to 99, with largest contentful paint under 1.1 seconds and no measurable layout shift. Those figures come from Cloudflare Observatory, run against three European regions in August 2026. They are worth having, and they are not the interesting part. The interesting part is being able to tell you what they were an hour ago, what moved them, and what is still unfinished. All of that sits in the period after launch, which is exactly the period the other two models treat as somebody else’s problem. The engagement is written up in the case studies.
The question to ask any provider
Whoever you are evaluating, ask them this: walk me through what you do for me in month seven. A freelancer will talk about availability for new projects. An agency will describe the support tiers. A fractional engineer should be able to describe an ordinary month of ownership: what gets monitored, what gets improved, what the monthly note says, and who answers when something fails outside office hours. The specificity of the answer tells you whether ownership after launch is a service or a reassurance.
What an ordinary month contains is documented on the Operate page, and the economics of the three models are in the cost comparison. If your systems are sitting in the ownerless period after somebody’s handover, the route is adoption rather than a rebuild. It starts with the audit: €450, fixed before it starts and credited in full against a build or a retainer if one follows. The document is yours whether anything follows or not. Before the invoice there is a free conversation of about twenty-five minutes, which decides whether the looking is worth doing rather than doing the looking. The contact page sets out what the audit covers.