Freelancer or Agency: Where the Risk Sits

The risk is not the same in each arrangement

Buyers tend to treat these three options as three points on a price line: freelancer cheap, agency in the middle, in-house expensive. That framing hides the useful part. What differs between them is not primarily the cost but the shape of the exposure — what you lose when things go wrong, and how long it takes to get back to normal.

A freelancer’s exposure is concentrated in one person. An agency’s is spread across a small number of people you have not worked with. An in-house team’s is owned by the organisation, which also means the organisation carries the management burden. Work out which risk you are actually buying against before you compare prices.

Failure modes specific to each

A freelancer’s project fails in recognisable ways. The work stops when the person is ill, on another project, or gone, and there is no second pair of hands. Knowledge does not leave the organisation because it was never written down. Scope disagreement has nowhere to go, because there is one person and one client, and the pressure to keep the relationship pleasant sits directly against the pressure to be rigorous about it. Communication runs through a single channel, which means a disagreement about what was agreed is also a relationship problem.

An agency’s failure mode is different: the work does not stop, but accountability does. A junior developer changes something on a Friday, a senior developer leaves the company six weeks later, and the person you would have spoken to about it has moved to another account. Context lives in the agency, not with you. When the account team changes, you repeat the same explanations, and some earlier decisions quietly reverse themselves without anyone deciding to reverse them.

An in-house team’s failure mode is familiarity. People who have worked on the same system for years stop seeing the parts they have never understood. There is no fresh pair of eyes, and a wrong architectural decision compounds quietly instead of surfacing in a sprint review.

None of this makes one option worse. It means the thing being bought differs. With a freelancer you are buying availability and skill. With an agency you are buying continuity plus a review layer. With an internal team you are buying ownership, and paying for the management that ownership requires. Buyers who price these as if they were the same product get surprised, usually by a clause they had not thought to negotiate.

The handover, where most of the risk actually lands

Whatever the arrangement, there is a moment when someone other than the builder needs to run the thing. That moment is where risk concentrates, and it is the part most agreements treat as an afterthought.

Useful documentation is small and specific: how to run it locally, how to deploy it, what the environment variables mean, which external services it talks to, which credentials live where, and what the known limitations are. The last one is the most valuable and the most frequently omitted. A system handed over with an honest list of its rough edges can be planned for. A system presented as finished will be trusted until the first surprise, and the surprise will be expensive because nobody knows whether it is a defect or a design decision.

Two smaller things matter more than they look. A working staging environment means the next person can test a change without touching production. And a single documented path to each third-party service — the payment gateway, the messaging provider, the domain registrar — prevents the situation where the original builder knew a login that was never written anywhere, and that login is now the only route to a service the business depends on.

SmartEdge IT Solutions puts this in writing at the end of every engagement rather than leaving it to good intentions, because good intentions are the part that reliably disappears first. It also means the handover conversation can be short: the receiving party reads a document, runs one procedure, and asks about the things the document does not cover. Anything longer than that usually indicates the document was not written properly in the first place.

The variables that should decide it

Duration is the one most often used as a proxy for everything else, and it works reasonably well. A task of two weeks does not need a team, a contract and a handover plan. A commitment that runs for years needs all three, because the risk of a person becoming unavailable goes from trivial to near-certain.

Blast radius is the second, and it deserves more thought than it gets. The cost of a freelancer being unavailable is usually a delay. The cost of your payments integration being unavailable is different in kind. For work where a mistake touches money, health data or reputation, the availability of the person matters less than the ability to review the work — and that ability has to exist somewhere other than inside the person who wrote it.

Third, can the requirements be understood by someone outside the business? If they can be written in a document a competent developer can act on, a freelancer is viable. If they emerge from a decade of undocumented practice, that person needs context, and context is the expensive part.

Fourth, how reversible is it? A landing page can be wrong cheaply. A data model that becomes load-bearing everywhere is expensive to change once code depends on it.

What a contract actually needs to contain

People assume the important clauses are the familiar ones. In practice the clauses that decide whether a project succeeds are boring:

• Who owns the code, and in what state it is handed over. Source, build scripts, infrastructure definitions, credential rotation.
• Who owns the repositories, the cloud accounts and the domains. Too often: the freelancer.
• Response times and channels for the first two weeks after handover, when the questions are always the same.
• What happens to access when the relationship ends, and on what timescale.
• Who may talk to the client’s customers or staff, and what they are permitted to promise.
• For data: where it is stored, who can read it, and what happens to it on exit.

Two practical notes. Put the repository and the cloud accounts in your organisation’s name from day one rather than after a dispute. And ask for the handover in writing before the work starts, because it is very hard to obtain at the end when everyone is tired and the invoice is still open.

If the arrangement involves access to personal or sensitive data, the handling terms matter as much as the code. Where you do not hold the regulatory obligations yourself, the provider should say plainly what they do with data, on which infrastructure, and who else can reach it. That conversation is more productive than a marketing page full of badges. Our developer engagement options set out how these terms are typically structured.

Where the middle option is genuinely better

There is a real argument for the middle of the market, and it is not only about risk pools. An agency of a sensible size can hold a designer, a developer and someone who handles infrastructure, which means a small feature does not require hiring three contractors. They can absorb the client contact going on leave. They can put a different person on a problem, which is a genuine form of review. A team with some turnover and little institutional knowledge is occasionally the least biased reviewer of its own recent work.

None of that is automatic. It depends entirely on whether the account is treated as a long relationship or as a sequence of tickets. Ask directly how long the named team has worked together, whether the same people stay on the account, and what happens when one of them leaves. Those answers are more informative than any portfolio.

SmartEdge IT Solutions takes this seriously enough that we would rather lose a bid to an internal hire than win one against the wrong criteria. It is not unusual for us to say during scoping that a client does not need a supplier for the first phase, and that the first phase is better spent making the requirement explicit. Those conversations cost us revenue, and they are the reason clients come back.

When the cheap option is the right one

Small, bounded, low-blast-radius work is genuinely a freelancer’s territory, and pretending otherwise just pushes cost into places it does not need to be. Fixing a defect. Adding a well-specified field to an existing form. A script that generates a report from an existing database. Proof-of-concept work intended to be discarded, where nobody has pretended it will survive contact with production.

The condition is that the organisation can absorb the loss if it goes wrong. If the work can be reviewed, is written down, and would still be useful if the person disappeared next month, the exposure is small and the arithmetic works.

The trap is where a small piece of freelance work becomes load-bearing — a data pipeline, an integration nobody documented — and the money that was saved has quietly turned into a dependency nobody planned. On work that touches systems the business cannot pause, the conversation should be about review and documentation, and the budget should reflect that. Where release practice is the real problem, our DevOps consulting engagements usually start with an inventory of what already runs.

Comparing the options without a spreadsheet

Four questions, asked identically of each option, produce a clearer answer than any cost model:

1. Who can review this work, and are they independent of the person who wrote it?
2. If this person or team became unavailable on Monday, when would you notice, and how long to restore normal service?
3. What do we own at the end, and can we prove it?
4. Where does the data live, who else can reach it, and what happens to it when we stop working together?

If a candidate cannot answer the second question without hedging, that is the finding. Cost matters, and it should be part of the decision. But the price is the visible part of a choice whose hidden part is who is left holding the problem when the timeline moves and nobody is available to pick up the phone.

Where you want the technical detail behind that judgement rather than a view from the outside, ask for a scoping conversation before a quote. How we approach application consulting and strategy involves writing down who owns each decision and what happens if it turns out to be wrong, which is the same exercise as asking these four questions of a supplier.