Fractional engineer vs agency: who actually owns your systems

I have never met the people who built most of the systems I run.

That is not a complaint about agencies. It is a description of how they are shaped. By the time someone calls me, the agency that built their site has usually been gone a couple of years, the account manager has moved on twice, and the developer who actually wrote the thing left before the final invoice cleared. Nobody was negligent. The structure just does not keep anyone attached to your system once the project closes.

I spent four months working inside one, which was long enough to understand the economics and short enough to know I did not want to work inside them. So this is not a view from the outside, and it is not a hit piece either. The people were competent and the process was competent. The model simply optimises for something other than what happens to your system afterwards.

That is the real difference between an agency and a fractional engineer, and it is not price. It is whether a specific human being is still holding your system a year later.

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

Systems do not fail on the day they are built. They fail in month seven, quietly, in a way nobody is watching for.

An agency is excellent at building the thing. That is what the model is optimised for: scope it, staff it, deliver it, close it. What it is not built to do is notice, eleven months later, that a scheduled job stopped running or that an integration is silently dropping records. Not because anyone is careless, but because by then your project is closed, the team is on someone else’s build, and nothing in the arrangement pays anyone to keep looking.

The cost of that gap is never a dramatic outage. It is months of a thing being slightly broken while everyone assumes it is fine.

Agency and fractional, side by side

What you are comparing	Agency	Fractional engineer
What you are buying	Delivery of a defined project	Ongoing responsibility for a system
Who does the work	A team, assigned and reassigned	The same senior engineer throughout
Who you talk to	An account manager, usually	The person doing the work
Knowledge of your system	Resets when staff rotate	Compounds month over month
After launch	A support contract, or nothing	The point of the engagement
Capacity	Large, can parallelise	One person, hard limits
Range of disciplines	Specialists per area	One generalist across four
Right when	The work is big, defined and finite	The system is ongoing and matters commercially

Where agency ownership actually goes

It diffuses. Not through anyone’s fault, through structure.

Your problem enters a queue. The queue is triaged by someone who is not technical, against a scope written before anyone knew what would break. It is assigned to whoever is free, which is often not whoever built it. That person reads themselves in, does the change, closes the ticket, and moves to the next account. None of that is bad practice. It is competent process, and it is exactly how a business serving forty clients has to work.

But notice what has happened to responsibility. Four people touched your system and none of them owns it. Ask “why did this break?” and every honest answer is partial, because no single person has held the whole thing in their head since the day it was built.

I see the result of that most weeks. When I inherit a platform, I lose the first few days simply working out what is load-bearing: which plugin is doing something important, which cron job matters, which clever thing someone did in 2023 everything now quietly depends on. That archaeology is not billed to anyone. It is just the cost of a system nobody has been holding.

There is a second, quieter version of the same problem, and it is the one that made me leave. A great deal of agency delivery is a commercial template, adjusted and handed over as a bespoke build. That is not fraud and mostly nobody frames it as deception: it is what the margin requires when you are staffing a pipeline and quoting against firms doing the same. But it has a consequence that shows up years later on my desk. If nobody on the delivery team wrote the thing, nobody on the delivery team can explain it either. The knowledge was never theirs to lose. You did not buy a system somebody understands, 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 different page builders, and takes a moment to settle on screen was assembled rather than built. None of that makes it a bad site. It does tell you what you are actually going to own.

That is what I mean about ownership. Nobody had done anything wrong. Every individual interaction with that system was competent. It still went years doing nothing, because checking whether a thing is actually happening is not a task anyone gets assigned. It is something you only do if the system is yours.

What the fractional model actually changes

Three things, and the third is the one that compounds.

One person, and it is always the same person. When I have run a platform for a year, I do not need to read myself in. 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 not talent, it is continuity, and no rotation can manufacture it.

The scope is the outcome, not the ticket. Nobody has to decide whether your problem falls inside a statement of work. If it sits between a customer and the thing you sell, it is mine.

The knowledge compounds instead of resetting. This is the part people underestimate. Every month I run a system I know it better, so work gets cheaper in time rather than more expensive. Under a rotating team the opposite happens: each new person pays the orientation cost again, and you pay for it again, forever.

“

An agency is optimised to finish. A fractional engineer is optimised to still be here. Those are different products, and most businesses discover which one they needed in month seven.

When an agency is genuinely the right call

Often, and I would rather be straight about it than pretend the answer is always me.

Hire an agency when the work is large, well defined and finite. A brand redesign with a deadline. A migration that needs six people working in parallel for eight weeks. A campaign site that exists for one quarter and then does not matter. Those are jobs where capacity is the constraint, and one person cannot buy you capacity at any price. I cannot parallelise. If you need four workstreams running at once, you need a team, and I will tell you so on the call.

Hire an agency, too, when you need specialists deeper than a generalist goes. If the job is genuinely a data engineering problem or genuinely a brand problem, hire someone who does only that.

What an agency cannot sell you, at any price, is one person who still cares in month seven. Not because they are unwilling. Because nobody there is structurally attached to your system, and everybody there is attached to the next project.

Ask who will remember why

Ask any provider one question and listen to the shape of the answer.

“In eighteen months, who will know why this was built the way it was?”

An honest agency will describe a process: documentation, handover notes, an account team. That is a real answer, and for a defined project it is enough.

If the honest answer is a process rather than a person, and your system is something that has to keep working rather than something that has to get finished, you are buying the wrong shape of thing.

That is the whole distinction. Everything else is capacity and price.