Freelancer vs Agency vs In-House: Choosing Frontend Help for Your Startup

The actual decision

When a startup needs frontend capacity, the menu is: hire in-house, engage an agency, or contract a senior freelancer. Each is the right answer in a specific situation and an expensive mistake in the others. Having sat on the freelancer side of this for years — often alongside agencies and in-house teams — here is the honest comparison.

In-house: buy when the work is permanent

A full-time hire is the right call when frontend work is continuous, core to the product, and worth the overhead: recruiting time measured in months, salary plus benefits, equipment, and management attention. The in-house developer accumulates product context that no external party matches. The mistake is hiring full-time for a bounded need — a redesign, an MVP, a migration — and carrying the cost after the peak has passed.

Agency: buy bandwidth and coordination

Agencies shine when you need a whole delivery unit at once — design, frontend, backend, PM — and nobody internal can coordinate freelancers. You pay for that: agency rates typically run 2–3× a senior freelancer's for the same hands-on hour, and the senior people who pitch you are rarely the people who build your product. Quality varies less than with random freelancers, but so does flexibility; change requests move at contract speed.

Senior freelancer: buy judgment per hour

A senior freelance engineer fits when the work is primarily frontend, you have someone who can own product direction, and you want senior judgment without agency overhead. You get direct communication with the person writing the code, faster iteration, and rates between junior in-house and agency. The risks are real too: bus factor of one, and quality variance across the freelance market is enormous — which is why screening matters more than rate. I wrote a full guide on that in how to hire a senior React developer remotely.

The comparison in practice

• Speed to start: freelancer (days) → agency (weeks) → in-house (months)
• Cost per senior hour: freelancer ≤ in-house < agency
• Best for: bounded builds and ongoing part-time needs (freelancer) · multi-discipline projects with no internal coordination (agency) · permanent core product work (in-house)
• Main risk: availability and bus factor (freelancer) · indirection and cost (agency) · slow hiring and fixed cost (in-house)

What does each option actually cost in a year?

Hourly rates hide most of the real difference, because they exclude recruitment, employer overhead, and the months before a new hire is productive. The table below models roughly half-time senior frontend capacity — about 80 hours a month — over a first year, in EUR. The in-house column cannot be bought at half-time, so it is shown at its true full-time cost, which is the honest comparison a founder actually faces.

Two honest caveats. The in-house column buys nearly twice the hours, so per-hour it is competitive — around €78 against the freelancer's €60 and the agency's €140. And the agency figure includes project management, QA, and cover for holidays and illness, which the freelancer column does not; whether that overhead is worth 2.3× depends entirely on whether you have someone internal who can direct a contractor.

The number that surprises founders is recruitment plus ramp. Twelve thousand euros and three unproductive months is roughly €33k before the first useful commit — which is why hiring full-time for a six-month need loses money even when the salary looks cheaper than the alternatives.

Which option fits your company stage?

The right answer changes as the company changes, and most expensive mistakes are stage mismatches rather than bad options.

Pre-product-market fit, no technical founder. A senior freelancer or a small agency. You need something in front of users quickly and you cannot yet describe the role a full-time hire would fill for two years. Hiring in-house here means paying a year's salary to learn what you actually needed.

Pre-PMF with a technical founder. A freelancer, almost always. You can direct the work, so you are buying hands and senior judgement without agency coordination overhead. This is the cheapest configuration on the table and the one I most often work in.

Post-PMF, growing, frontend is core. Start hiring in-house, and bridge with a freelancer while you recruit — a three-to-six month search is normal for a genuinely senior frontend engineer. The freelancer who bridges can also help interview, which is a materially better screening loop than a hiring manager who does not write frontend code.

Established team, specialised gap. A freelancer for the specialty — performance, real-time, accessibility, a migration — rather than a permanent hire for a temporary problem. This is most of my retainer work: reinforcement on a specific axis, not general capacity.

Large multi-discipline launch, no internal coordination. An agency. If you need design, frontend, backend, and project management simultaneously and nobody internal can run four contractors, paying for coordination is rational.

What are the switching costs?

Every one of these decisions is reversible, but not at the same price. Worth knowing before you commit.

• Freelancer → in-house. Cheapest transition, if the contract allowed it. Budget four to eight weeks of overlap for handover, and make documentation a deliverable rather than a favour. Some agencies charge a conversion fee for placed contractors; independent freelancers usually do not, but check.
• Agency → in-house or freelancer. The expensive one. Code you did not write, conventions nobody internal chose, and occasionally infrastructure in the agency's accounts. Ask at signing who owns the repository, the deployment accounts, and the design files — the answer matters enormously eighteen months later.
• In-house → freelancer. Usually happens after a departure, at the worst possible moment. The mitigation is not contractual, it is documentation discipline while the person is still there.
• Any → any, mid-project. Reckon on losing two to four weeks of momentum to context transfer regardless of direction. That cost alone justifies spending an extra week on the initial decision.

The general rule: the switching cost is proportional to how much context lives only in someone's head. Written decisions, documented conventions, and a readable commit history are what make any of these arrangements reversible — which is a good argument for demanding them from whoever you engage.

Hybrid patterns that work

The setups I see succeed most often: a freelancer building the MVP, then helping hire and onboard the in-house team that takes over; an in-house team using a retainer freelancer as senior reinforcement for architecture and review; an agency handling a launch while a freelancer owns one specialized area like performance or real-time features. The models combine better than the sales pitches suggest.

Three of these are worth describing in more detail, because they are the ones that repeatedly work.

Build-then-transfer. A senior freelancer builds the first version and, from month four or so, shifts to helping recruit and onboard the permanent team. The handover is the deliverable, not an afterthought — documented conventions, a readable history, and two months of overlap. The freelancer sitting in on interviews is the underrated part: they can assess candidates against the actual codebase rather than a job description.

Retainer reinforcement. An in-house team of two or three mid-level developers with a senior freelancer on a small monthly retainer for architecture decisions, code review, and the hard problems. Roughly 20 to 40 hours a month buys most of the value of a senior hire at a fraction of the cost, and the in-house developers grow faster with someone to review against. This is the most common shape of my own retainer work.

Specialist alongside generalists. The team owns the product; the freelancer owns one axis — Core Web Vitals, a real-time feature, an accessibility audit, a framework migration. Bounded, measurable, and it does not compete with the team's ownership, which is the failure mode when you add a generalist contractor to a functioning team.

What these share is that the external person has a defined edge rather than being extra hands. Adding undifferentiated capacity to a team that already has conventions usually costs more in review than it returns in throughput — the mistake I described in how to hire a senior React developer remotely.

What went wrong: the cheapest option that cost the most

The most expensive engagement I have been asked to rescue was a marketplace MVP built by the lowest bidder at roughly $18 an hour. The client had compared hourly rates across three proposals and taken the smallest number.

What arrived after five months: no tests, no TypeScript, business logic in component files, credentials committed to the repository, and a bundle that took eleven seconds to load on mobile. It technically demonstrated the product, which is why it had kept getting approved month to month. The rebuild took four months at a senior rate. Total spend was roughly 2.4× what starting with a senior engineer would have cost, and the real loss was the nine months of market timing.

The mistake was not choosing a cheap freelancer — plenty of excellent engineers charge modestly, particularly outside Western Europe. The mistake was evaluating on rate rather than on evidence, with no code review at any point in five months. Nobody looked at the repository until it was time to hand it over.

What I would do differently as a buyer: commission a paid two-week milestone first and have someone technical review the actual code before extending. If nobody internal can do that review, paying a senior engineer for two hours to read the repository is the highest-return money in the whole engagement. The screening checklist in the hiring guide exists precisely because rate tells you nothing and code tells you almost everything.

Making the retainer math concrete

For ongoing needs below a full-time load, a monthly retainer — fixed capacity, fixed price, one backlog — usually beats both ad-hoc hourly billing and a premature full-time hire. The mechanics and the questions to ask before signing are in retainer vs project hiring, and my own retainer terms are on the services page.