We are a small team, so we sit between the two and have no interest in pretending the choice is obvious. The real differences are continuity, breadth and what happens when something goes wrong, not quality of code.
It is usually framed as cheap versus reliable, which flatters agencies and insults good freelancers. Excellent freelancers exist and expensive agencies fail. What genuinely differs is what happens to your project when one person is unavailable, and how many disciplines the work needs.
One person means one point of failure: illness, a better offer, a life event. It is not a criticism, it is arithmetic, and it matters more the longer the engagement runs.
Projects needing design, development and marketing either get one supplier covering them or you become the integration layer between three.
When a freelance relationship goes wrong there is no second party. With a team there is someone else to raise it with, which occasionally matters a great deal.
Work reviewed by a second pair of eyes catches things solo work does not. Some freelancers arrange this; most do not, and it is worth asking.
Freelance day rates are usually lower and the total is not automatically lower, because co-ordination and rework land on you. Compare delivered outcomes, not rates.
The hardest thing to buy from a freelancer is a small change in eighteen months. Ask both sides what support looks like once the project ends.
This decision is usually made on price and personality, and it should be made on continuity and ownership. These four questions apply equally to us, to any agency, and to any freelancer, and the answers tell you more than a portfolio does.
Not at the end of the project. Today, while work is happening. The answer should be that you do, with the supplier granted access. Any other arrangement means leaving involves a negotiation rather than a decision, and the moment you discover this is invariably the moment you most need it not to be true. This applies to hosting, domain, analytics and app store accounts as much as to code.
A repository is not a handover. What a successor needs is the environment variables documented, the deployment procedure, how to restore a backup, and the reasoning behind the decisions that look odd. Ask to see an example from a finished project. Suppliers who produce this will show you immediately; those who do not will explain why it is unnecessary, which is your answer.
Ask it plainly, of both a freelancer and an agency. A good freelancer has a considered answer involving documentation and possibly a trusted colleague. A poor one is offended by the question. An agency should be able to name who else could pick the work up, and if the honest answer is that only one person there knows your project, you have an agency with a freelancer's risk profile and an agency's price.
This is the question that separates the total cost from the project cost, and almost nobody asks it. Post-launch changes are where projects quietly become expensive: the supplier has moved on, has no incentive to be quick, or has to relearn a codebase they have not touched in a year. Agree the shape of it upfront, even loosely. The answer also tells you whether the supplier expects to still be reachable, which is itself informative.
Usually per day, and not reliably per project. The costs that move the total are rarely the rate: time you spend co-ordinating, rework from a misunderstanding nobody wrote down, and gaps between disciplines where each supplier reasonably believes something was someone else's job. A good freelancer on a well-defined project is frequently the cheapest route by a clear margin. A vague brief split across three freelancers is usually the most expensive thing you can do.
Availability, not competence. One person gets ill, takes a full-time offer, or has a life event, and your project stops for as long as that lasts. On a six-week build this is a manageable risk. On a system your business depends on for the next three years it is a real exposure, and the mitigation is straightforward: insist on documentation and a repository you own from the start, so the work can be picked up by someone else. That is worth asking of us too.
Fair question, and the honest answer is that we sit between the two. You get more than one person, work gets reviewed, and there is someone to escalate to, which are the real agency benefits. You do not get a large bench, an account manager or twenty-four hour coverage, and you should not pay for the impression of them. If your project genuinely needs that scale, a larger agency is the right call and we will say so.
Four things, and the answers are more revealing than any portfolio. Who owns the repository and the infrastructure accounts during and after the work. What documentation exists when the engagement ends. What happens if the person doing the work is unavailable for three weeks. And what a small change costs in a year. Anyone good has clear answers. Vagueness on ownership or handover is the single most useful warning sign available to you.
Yes, and it is often the best value available to you. They know your business and your systems, which is expensive to replace. We take the specialist work outside their scope, review their architecture, or cover an absence. What makes this succeed is an explicit boundary and a shared repository with reviewed changes, so nobody is guessing who owns what.
Scope is agreed in writing before anything is built, which removes most rework. You own the repository and the accounts throughout, so leaving is a normal decision rather than a negotiation. Everything runs asynchronously in writing, which means the decisions are documented as a by-product rather than living in someone's memory. And the handover includes a runbook, because the test of a supplier is how easily you could replace them.
Including whether a freelancer would serve you better, which is sometimes the answer. Written reply within one business day, no call required.
Request a quote →