Freelancer vs Software agency

Any figure here would mislead you, because rates for both vary enormously with market, seniority and specialism, and they move. A senior freelancer in a scarce specialism can charge more per hour than an agency whose blended rate reflects a mostly junior team, and plenty of agencies charge less than the best independents. What is stable is what each rate contains, and that is the comparison worth making.

A freelancer’s rate pays for their time and the costs of running a one-person business: equipment, software, their own training, and the unpaid hours spent finding the next client and covering the gaps between contracts. If you met on a marketplace, a platform fee sits on top or comes out of it, charged to one side or both depending on the platform, and the structure changes, so check the current terms. What the rate does not contain is anyone to plan the work, review it, test it or cover for absence. Those jobs still exist. They move to you. If you have the person to do them, the freelancer is the cheaper route by a wide margin. If you do not, they tend not to get done, and the cost appears later as defects, rework and a system only one person understands.

An agency’s rate pays for engineering plus the structure around it: someone planning and coordinating, a second engineer reviewing, testing, cover when someone is ill, the cost of people between projects, sales, management and premises. Some of that is value delivered to you and some is the cost of being a company. A fair question to put to any agency is which parts of the rate are the parts you are buying.

The comparison that helps is cost per finished, working result, including your own time and an honest price for the risk. Add up the hours you would spend managing, reviewing and testing a freelancer’s work, and ask what it would cost if the work stopped halfway and had to be picked up by someone new. How you pay matters as much as whom you pay. Hourly and fixed-price arrangements are available from both, marketplaces usually support both, and the trade-offs are the ones set out in fixed price versus time and materials. Whichever you use, pay against work that has been delivered and checked rather than against promises.

Engineers use the term bus factor for the number of people who would have to become unavailable before a project stalls. With a freelancer it is one, by definition. That is a structural fact and no reflection on anyone’s character. Freelancers get ill, take holidays, have family emergencies, accept full-time jobs, win a larger client or burn out from carrying several clients at once. Each of those is ordinary life, and on a long enough project one of them will happen.

The absence itself is rarely the expensive part. The expense is the knowledge that leaves with the person: why the system was built the way it was, which service the payments depend on, where the credentials live, how a release actually reaches production. On a two-week job that knowledge is small and mostly in the code. On a system that has been growing for a year, it is substantial and mostly in one head.

You can lower that risk considerably with a freelancer, and it costs very little if it is done from the first day. Keep the repository in your organisation’s account with the freelancer as a collaborator. Put hosting, domains, app store developer accounts and third-party API keys in your name. Ask for a short document explaining how to run, build and deploy the system, and keep it current. Ask for a sentence or two in writing whenever a significant decision is made. Agree in the contract how much notice either side gives and what a handover includes. Then, once in a while, ask someone else to try running the project from that document alone.

An agency’s bus factor is higher only if the agency practises it. A firm where each client project lives with one engineer has a freelancer’s risk profile at an agency’s price. Ask how many of their engineers have worked in your codebase in the last month, who reviews whose changes, and what happens if your main engineer resigns. Agencies also move people between clients, which keeps their own utilisation up and can cost you context, so ask for continuity of named people.

Accountability looks different in practice. A freelancer’s accountability is personal and often sincerely felt, because their reputation is their whole business. Its limit is what one person can absorb: if a project goes badly, getting money back or getting the work finished from an individual who has stopped responding is hard, and harder still across a border. Marketplace dispute processes help with payment disagreements and much less with an unfinished codebase. An agency usually has more to lose from a public failure, and other engineers who can fix what one of them got wrong, which makes it more answerable, though only as answerable as its contract.

The contract points that matter are the same for both. An explicit written assignment of intellectual property in the work. A licence to any pre-existing code the supplier reuses, because freelancers and agencies alike carry their own toolkits from job to job. A list of open-source components and their licences. Confidentiality. Notice periods, and what a handover includes. Liability limits, and insurance if your procurement requires it, bearing in mind that many individuals and some firms carry no professional indemnity cover. If you met on a marketplace, read its terms on ownership of work product and do not rely on the defaults for anything important. Marketplace terms also commonly restrict moving the relationship off the platform for a period, or charge a fee to do so, which is worth knowing before you plan to.

With an agency, ask about the chain behind the signature. A firm can only assign to you what its own engineers and subcontractors have assigned to it, and many agencies use freelancers for overflow work. There is nothing wrong with that in itself, but you should know who is writing your code and that the paperwork behind them is in order.

One more point for long freelance arrangements. In many jurisdictions, an arrangement in which one freelancer works full time for one client, under that client’s direction and on its equipment, can raise questions about employment status. The rules vary, so take local advice if a freelance arrangement starts to look like a job.

Every engineer, however good, writes mistakes they cannot see in their own code, for the same reason writers struggle to proofread their own drafts. Review by a second engineer catches misunderstood requirements, security holes, missing edge cases and, most valuably over time, code that only its author can follow. Without it, problems do not announce themselves. They accumulate as technical debt and surface months later as changes that take three times as long as they should.

A freelancer has no reviewer unless you provide one, and this is the largest quality difference between the two options. If you have an experienced engineer on staff, the fix is simple: the freelancer opens pull requests and your engineer reviews them before anything merges. If you do not, you can pay an independent senior engineer to review the work periodically, which costs a few hours a month and is very good value on anything that will run in production. At minimum, require automated tests and a build that runs them on every change, so that some checking happens even when nobody is reading.

At an agency, internal review is one of the main things the higher rate is meant to buy, so verify that it happens. Ask for read access to the repository early in the engagement and look at the pull requests. Substantive comments, questions and requested changes indicate real review. Instant approvals with no comments, or engineers approving their own work, indicate a process that exists mainly on paper.

If you cannot read code yourself, there are still signals you can check. Work should arrive in small, frequent changes rather than occasional large drops. The system should deploy without its author in the room. Fixed bugs should stay fixed. And when you ask why something was built a particular way, you should get an answer that makes sense to you.

The freelancer’s strongest advantage is communication. You talk to the person who writes the code, and nothing is relayed, summarised or softened on the way. For work where the details shift daily, that matters, and it is hard for any firm to match fully. The weakness is availability. You are one client among several, and your work gets whatever share of one calendar your contract and their other commitments leave. Agree working hours, response times and overlap with your own day in writing, and ask how many other clients they are carrying.

An agency adds structure, which cuts both ways. A project manager or lead who plans the work and handles coordination saves you time, and a good one makes the engineers more productive. A poor one becomes a filter between you and the people building your software, and a question that a direct conversation would settle in five minutes takes a day. Ask whether you will be able to talk to the engineers directly, and treat a firm that keeps you away from them with some caution.

Scaling is where the difference is starkest. A freelancer’s capacity is one person. If your needs grow, either you hire more freelancers and become the coordinator between them, or the freelancer subcontracts part of the work, sometimes without mentioning it, to people you never vetted. Ask directly whether anyone else will touch your project. An agency can add engineers who share its process and its review, with notice. And three good freelancers on three parts of one product, each reporting separately to you, do not make a team: somebody has to decide how the parts fit together and own the whole, and if you have not appointed that person, it is you.

Agency covers an enormous range, and the differences inside it matter as much as the difference between agencies and freelancers. Many large agencies run on a pyramid: a small number of senior people who win the work, design it and supervise it, and a larger number of junior and mid-level engineers who build most of it. That ratio is how the business model works, and it is not dishonest in itself, since juniors learn on supervised work everywhere. But the people in the pitch are often not the people in the code, and you should know which ones you are paying for.

Large agencies have real strengths. They can staff a big programme quickly, bring many specialisms under one contract, satisfy demanding procurement and security processes, and absorb the loss of any individual without your noticing. If you need fifteen engineers across five disciplines by next quarter, a small firm cannot give you that and should tell you so.

A small senior agency is a different trade. The people who sell the work are the people who build it, there is little management layer to pay for, and the seniority you meet is the seniority in your repository. Its limits are just as structural. Capacity is finite, so a sudden need for many more engineers may mean waiting or bringing in partners. The range of in-house specialisms is narrower. And key-person exposure, while far lower than with a single freelancer, is higher than at a large firm. That is the shape Yarqat is, and those are our limits as well as our strengths.

To find out which kind of firm you are talking to, ask who will write the code, by name, and whether you can meet them before signing. If the answers come back as roles rather than people, you have learned something. Once you have chosen a firm, the remaining question is the shape of the engagement, which staff augmentation versus a dedicated team covers in detail.

Most vetting fails because it checks things that are easy to polish: portfolios, proposals and confident interviews. Three checks are much harder to fake, and they apply equally to individuals and firms.

References, spoken to rather than read. Ask what was built, what went wrong and how it was handled, whether the person or firm stayed reachable after the work ended, and whether the referee would hire them again for the same kind of work. Ask for at least one reference from an engagement that has finished, because finished clients know how the handover went. On marketplaces, treat ratings with care: they tend to cluster near the top of the scale and record satisfaction at the moment of payment, which says little about the condition of the code a year later. The written feedback, read for specifics, is more useful than the score.

Code they actually wrote. A portfolio of screenshots tells you about the design and almost nothing about the engineering. Ask for a public repository, or a sample shared under a confidentiality agreement, and look at whether it is readable, whether it has tests, whether the commit history tells a coherent story and whether there is a README someone else could follow. If you cannot judge code, pay an experienced engineer for an hour to read it. That hour is cheap next to what it can save.

A paid trial task. Choose a small piece of real work, a few days at most, with a clear brief and a definite outcome, and pay the normal rate for it. Watch the questions asked before work starts, how close the estimate lands, how they communicate when stuck, and whether what arrives works in your environment as well as theirs. Never ask for unpaid work as a test, because good people decline it. For an agency, the equivalent is a short paid discovery or a first sprint with a defined deliverable, run by the named engineers who will do the rest of the work.

Treating this as a binary choice suits a comparison page better than it suits most buyers. Several of the best arrangements combine the two, and what makes them work is the same each time: one owner for each piece of work, one review standard for everyone, and everything kept in your accounts.

A freelancer under your own lead, with periodic outside review, is the cheapest route to senior-quality work if you already have the lead. The freelancer supplies capacity, your lead supplies direction and day-to-day review, and an independent senior engineer looks at the architecture every month or two to catch what someone close to the work misses.

An agency on the core product, with freelancers on bounded pieces, suits a product that needs continuity in the centre and specialist help at the edges. A dedicated development team carries the main system, and a freelancer builds a specific integration or a self-contained tool to an agreed interface, with the agency or your lead reviewing what comes in. The boundary has to be written down, or the two sides will make different assumptions about the same code.

A freelance prototype followed by a production build suits early ideas. One person can produce a proof of concept quickly and cheaply, and the prototype then serves as a working specification for the version built properly. The mistake is promoting prototype code into production unreviewed because it already works. It was written to answer a question, and carrying customers is a different job.

An agency build followed by freelance maintenance suits a system that is finished and stable. The agency builds, documents and hands over, and a freelancer who knows the stack handles small changes at a lower cost. This works when the documentation is real, the accounts are yours and the system is small enough for one person to hold. When it grows past that, the arrangement has to grow with it.

Moves in both directions are common, and most of the cost of either is decided by what was set up at the start. Work that lives in your repository, deploys from your accounts and comes with a written explanation of how to run it changes hands in days. Work that lives on someone’s laptop takes weeks, and some of it never fully comes back.

Moving from a freelancer to an agency usually happens because the work has outgrown one person or because the freelancer has become unavailable. Start with an audit before any new feature work: can the system be built and deployed from what you hold, which credentials and accounts are in whose name, what is tested and what is not, and which parts only the original author understood. If the freelancer is still reachable and the parting is friendly, paying for a few hours of handover conversation is one of the best purchases in the whole process. Expect the receiving team to find things they want to change, and ask them to separate what is genuinely risky from what is merely not how they would have written it.

Moving from an agency to a freelancer usually happens when a system is built and stable and the remaining work is small. It goes well when the agency hands over properly: documentation of the architecture and the deployment, a walkthrough with the freelancer, every account already in your name, and a short period in which the agency remains reachable for questions. Be realistic about what one person can maintain. A system with a web application, a mobile app and its own infrastructure is a lot for a single maintainer, and you may be choosing a slower pace of change along with the lower cost.

In both directions, transfer the accounts before the people. Repositories, hosting, domains, app store listings, payment providers, email services and analytics should all belong to your organisation, with outside engineers added as users and removed when they leave. Arranging that at the start costs an afternoon. Untangling it after a relationship has ended can cost weeks, and occasionally a domain or an app listing you cannot get back.