Freelancer vs Agency vs In-House: Cost, Speed and Risk

A product can need one person for a month and three people for three years, so hiring the same way for both is an expensive category error, and I have been the one person: on a UK property inventory platform, I replaced the meaningful parts of a legacy integration service, built the operations workspace and client portal, handled the migration and kept daily work running, and the system now holds over 25,000 properties, more than 60,000 inspections, nearly 7 million observations and more than 4 TB of media; one senior engineer can own a lot when the work has a clear centre and decisions do not travel through five people first.

Freelancer vs agency vs in-house is not a rate comparison - it is about how much work exists, how often direction changes, who carries absence risk, and whether you need a system of people or one person who can get on with it; at 600 EUR a day, I am not the low-rate option, but I can be the lower-cost option for a defined job because the billable team is small and coordination direct, while an agency can be lower risk because it has coverage I cannot offer, and an employee can be right even when the first year costs more because the product is the company and the work will not stop.

A freelancer sells concentrated judgement, not cheap labour

A solo contractor is useful when you need someone who can turn an uncertain brief into decisions and shipped work without a project manager translating every conversation, because you talk to the person writing the code and a decision at 10am can be running in staging that afternoon, while a founder often has one real workflow, a half-formed second one and features copied from competitors, so the job is to find the workflow that can carry a product; a senior freelancer can make product, technical and delivery decisions together because, early on, the gaps between those jobs cost more than the work itself.

An iPhone image editor had to turn a tapped photo subject into a movable layer, stay responsive and export a full-resolution composite, so I capped input analysis at a 3,072-pixel longest edge and the preview at 1,600 pixels; it needed image memory, Apple APIs, the purchase flow and the path from photo to export, not a backend team, analytics project and two-week discovery phase, while a one-screen sound meter had a similar constraint - what can an iPhone microphone reading honestly claim? It processes 2,048-frame audio buffers locally, applies A-weighting, presents an estimate rather than lab-grade sound pressure, and stores no recording, which makes it a small product where privacy and accuracy still need product judgement.

For 40 days at 600 EUR a day, delivery costs 24,000 EUR before separately agreed design, research or specialist work, and you pay for days worked with no payroll burden, bench, account manager, delivery director or internal handoff; a freelancer is costly when the scope needs specialists in parallel, the organisation needs a committee for every decision, or the contractor waits three days for each answer, and there is also an absence problem: I take holidays, get ill and can be booked, so if support cannot pause for a day, one person is not enough coverage.

An agency buys coverage and coordination on purpose

Treating agencies as slow by definition is lazy, because a good agency offers disciplines at once, cover for illness or holiday, an existing delivery process and capacity when work suddenly widens, which matters when you need discovery with users, brand and interface design, a web application, a native app, QA across devices, a security review and a production release in a fixed window, because asking one freelancer to do all that is a gamble while a capable agency can use the specialists required and keep moving when someone leaves.

Agency continuity is insurance: a well-run agency has shared repositories, delivery notes, code review and more than one person who understands the account, so if the lead developer is ill for a week or leaves, work need not stop while the client restarts hiring; you pay for account handling, recruitment, management, sales, quality controls, time between projects and a team assignable quickly, which is the operating model rather than automatically waste, although it is waste when all you need is a strong builder and a founder who can answer questions.

Handoffs add specialist scrutiny or waste time because people doing the work cannot speak directly, and on the property platform, property histories, inspection reports, invoice documents, a live operations surface and risky integrations needed direct access to people who knew what an inspection record meant and what could not be lost; a delivery layer would have slowed important decisions, whereas an agency would have been stronger for a simultaneous broad public launch: research, visual identity, a content site, several app clients, formal test coverage across a device matrix and a staffed support channel.

Meet the delivery lead and senior engineer, then ask who writes and reviews the code, who covers an absence, how much of the team is committed, and which decisions they need from you each week; keep asking if the answer is polished process language.

In-house is right when software is the daily work

Contractors are a mistake once your product is the business, the roadmap is full for the next two years, customer feedback arrives every day, and the work needs ongoing ownership across product, engineering and operations, so build an in-house team rather than keep renting the centre of your company because recruiting is harder; an in-house engineer sees the support ticket exposing a bad assumption, the sales call changing onboarding and the release that confuses customers, and that context compounds into knowledge of customers, codebase and internal work.

The property platform has more than 17 million attachments, booked inspections, data imports, private documents, authentication, webhooks, queues, accounting state and daily users, so it needs an owner after migration who can tell a one-off correction from a missing tool or product change; that can begin with a contractor, but a business depending on it should eventually have internal technical ownership, and although employee cost is bigger than salary - employer cost, equipment, recruitment, onboarding, management, benefits, leave and colleagues' time - in return, you get availability directed at your priorities and someone present for accumulated decisions, when there is enough work to fill the role.

In-house is not automatically fast, because recruiting and ramp-up can take months, while one junior engineer without technical leadership has merely moved the risk inside and still needs someone who can set direction, review changes and decide what not to build; a fractional technical lead or experienced contractor can bridge that gap while you hire, and in-house also has its own bus factor: one employee with production credentials and all deployment knowledge is not safer than one contractor in the same position, because employment status does not create shared understanding - practices do.

The bus factor is a delivery problem, not a contract type

The reasonable objection to a solo contractor is what happens if they disappear, but ask it of a freelancer, agency and employee, because the answer should be visible in the work rather than promised in a sales call; for a solo contractor, use common tools another competent engineer can run, document local setup, deployment, data boundaries, external systems and routine operations, and ensure credentials and production access use company-controlled accounts; create a handover path while the person is available, not after they leave.

On the property platform, source snapshots stayed alongside local records, and integrity work produced a per-property manifest for content and image status, finding missing cover images and meter photos from an earlier download path; the source set stayed while an actions backfill remained incomplete, so a replacement engineer can inspect what was fetched, projected, failed and blocked instead of reverse-engineering one laptop's import script, while readable code lets an engineer trace an invoice PDF from portal request, through the access check, to the cached document source without guessing which of twelve services matters, and documentation must cover restoring a backup, integration retries, failed jobs, replaying them and an API response change; old diagrams in docs are not coverage.

An agency reduces the bus factor with two people who understand the account, while an in-house team uses pairing, on-call rotation and written operational knowledge, and a freelancer uses explicit handover milestones and a small maintenance arrangement with a named backup; none removes risk, but each makes the dependency manageable, so do not hire a committee because you fear one person, because five people who do not know the system are not five times safer and are often five times harder to coordinate.

Speed is mostly a decision path

Speed is how a decision reaches the person doing the work, not story points, velocity charts or staffing counts, and a freelancer is fast when the founder is available and the outcome clear enough for trade-offs - a short call, written decision and deployed change - which suits a time-boxed prototype or focused MVP.

An agency is fast when work splits without a dependency pile, as design progresses while backend foundations are built, QA prepares scenarios and a project lead protects specialist time, but it slows when details circle through roles or the team is larger than the problem, while in-house starts slow with recruiting, onboarding and shared context, then can react to customers without procurement, new statements of work or supplier handover, which is why it is right for an established product organisation.

As sole engineer, I built a child-health log with a nine-entity record model, CloudKit-ready private and shared stores, a separate WidgetKit data path, local notifications, exports and StoreKit access control; it was tractable because it records parent-entered health information, does not diagnose, and has a widget that reads a small atomic snapshot rather than the full database, but if it had needed an Android client, clinical review, 24-hour support, international privacy work and hospital-system integrations, it would no longer have been a one-person product.

Buy the arrangement that can fail safely

For a freelancer, ask about a two-week absence, company-controlled access, handover documentation and who can take over, then ask for systems they owned after launch rather than screenshots; if support has a hard promise, budget for backup, and for an agency, ask for named people rather than role labels, check whether the seller makes technical calls, how many concurrent accounts the lead has, how knowledge is shared and what happens if the team changes, then get the change process in writing; it should protect decisions, not invoices.

For in-house, ask whether there is a durable queue of product work and someone able to manage it, then hire when the system needs daily ownership and your company can support a team; until then, a senior contractor can define the role, make the first hire less risky and leave a codebase worth inheriting, and in every model, decide from day one who owns architecture, production access, data, documentation and the backlog, because the work worth inheriting has a clear repository, company-controlled accounts, a current runbook, a visible deployment path and someone who can explain the last difficult decision, making departure an inconvenience rather than an emergency.

If you are comparing the build budget as well as the team shape, read what actually drives MVP development cost; I take on focused product and platform work at 600 EUR a day, and my background, rates and contact details are on my CV.