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 how each of the usual answers plays 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 actually 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 the shape of the engagement.
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.
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 someone meeting it for the first time, and is resolved 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 I work with.
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 your systems builds them, and the person who built them operates them: monitoring, patching, improving, and answering when something breaks. Continuity is not a support add-on; it is the entire value proposition.
In my practice that looks like real numbers on a real client: a multi-region web platform I have run end to end for years, migrated to dedicated infrastructure with zero downtime, PageSpeed lifted from 63 to 98, thirty-one services moved without a failure. Not because I am heroic, but because I was still there. Every one of those wins happened after launch, in the period the other two models treat as somebody else’s problem.
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 report you receive says, and who answers at 2am. The specificity of the answer tells you whether post-launch ownership is a real service or a reassurance.
What an ordinary month looks like here is documented on the Operate page, and the economics of the three models are in the cost comparison. If your systems are currently in the ownerless period after somebody’s handover, that is exactly the situation a free 45-minute diagnostic call is for.