Freelancer vs agency vs in-house: who should build your software?

Once you’ve decided to get software built, the next decision is who — and everyone you ask is selling one of the answers. Freelancers will tell you agencies are bloated. Agencies will tell you freelancers disappear. Recruiters will tell you to hire. We’re a small studio, which is one of the options below, so judge the bias for yourself — but we’ve also inherited projects from all three paths going wrong, and the failure patterns are remarkably consistent.

Here’s the honest version of each option, in 2026 Australian terms.

The options at a glance

	Freelancer	Studio / small agency	Large agency	In-house hire
Cost	$70–$180/hr	$120–$200/hr	$200–$400/hr	$90k–$160k+/yr salary + ~25–30% on-costs
Best for	Small, well-defined projects	Small-to-mid projects, ongoing relationship	Big, complex, compliance-heavy builds	Software is core to the business, constant work
Speed to start	Days	1–3 weeks	4–8 weeks	2–4 months to recruit
Key risk	One person: illness, disappearance, ceiling	Capacity limits	Cost, juniors doing the work	Commitment with no off-ramp

Option 1: a freelancer

The honest pitch. A good senior freelancer is the best value in software — no agency overhead, direct communication with the person doing the work, and for a well-defined small project they’ll often beat everyone on both price and speed.

Where it goes wrong. Every freelancer risk is the same risk wearing different hats: it’s one person. They get sick, get a full-time job, get a bigger client, or simply stop answering — and you own source code nobody else has ever seen. The second failure mode is the skill ceiling: one person is rarely strong at back end, front end, design, and infrastructure, so something gets done at hobby level. Third: quality variance is enormous, and a non-technical buyer can’t tell a $160/hr senior from a confident improviser until the project is late.

Hire a freelancer when: the project is small (under ~$15k), well-defined, and not business-critical infrastructure — or when you have a technical person who can review the work.

Protect yourself by: paying in milestones, requiring code in your repository (GitHub account you own) from day one, getting IP assignment in writing, and asking who they’d recommend if they’re unavailable — good freelancers have an answer; the risky ones are offended by the question.

Option 2: a studio or small agency (2–10 people)

The honest pitch. This is us, so discount accordingly. The case for a small studio: more than one set of eyes on your code, continuity if one person is sick or leaves, a broader skill set across design/build/infrastructure, and — the structural advantage — an entity that plans to exist in five years and maintain what it built. You’re typically still talking to the people doing the work, without a large agency’s account-manager layer.

Where it goes wrong. Capacity: a small studio juggling too many clients gives you the “your project resumes in three weeks” experience. Premiums over a freelancer (often 20–40%) without value if the project is truly tiny and simple. And small studios vary as much as freelancers — some are two overcommitted people with a nice website.

Hire a studio when: the project matters enough that single-person risk is unacceptable, you want one party owning design through deployment, or you want a long-term build-and-maintain relationship (the year-three question below).

Protect yourself by: asking who exactly will work on your project, looking at shipped work that resembles yours in size (this is the kind of work we ship), and asking how many concurrent projects they run.

Option 3: a large agency

The honest pitch. Big agencies exist for big problems: 6–12 month builds, enterprise integrations, formal compliance, projects where the buyer needs process artefacts (detailed documentation, project governance, security sign-offs). The good ones genuinely deliver that.

Where it goes wrong — for small businesses specifically. Three structural mismatches. First, cost floors: many won’t engage under $50k–$100k, so your $15k problem gets reshaped into a $90k solution. Second, the seniority bait-and-switch: the impressive people in the pitch meeting are not the graduates writing your code. Third, you’re a small fish — when a bigger client’s deadline slips, guess whose team gets borrowed.

Hire a large agency when: the project is genuinely large and complex, compliance demands formal process, or a corporate buyer requires a vendor of that scale. For a typical small-business tool or internal system, you’re paying enterprise overhead for a problem that doesn’t have enterprise complexity.

Option 4: hiring in-house

The honest pitch. If software is becoming core to how your business competes — not one project but a continuous stream of them — an in-house developer compounds: they learn your business deeply, they’re there every day, and the marginal cost of “one more improvement” drops toward zero.

The maths everyone underestimates. A mid-level Australian developer is $90k–$130k salary, call it $115k–$165k loaded with super, leave, equipment and overheads. That’s the budget for a lot of studio or freelancer work — roughly 700–1,000 agency hours a year. If you don’t have 700+ hours of genuine software work annually, you’re paying a full-time salary for part-time output, and the developer knows it: good developers leave roles where they’re underused, and then you own systems with no maintainer (the freelancer risk again, with redundancy pay).

There’s also the management problem nobody mentions: a solo in-house developer has no one to review their work, no one to learn from, and a non-technical manager. Some thrive; many drift.

Hire in-house when: you have continuous, genuinely full-time software work, ideally enough for two people eventually — or when software is the product.

The decision in four questions

1. Is this one bounded project under ~$15k, and is someone technical available to sanity-check it? → A good freelancer is the best value, with milestone payments and your own repo.
2. Is it a system your business will depend on daily, with no technical person on your side? → A studio — you’re buying continuity and accountability, not just hours.
3. Is it a 6+ month, compliance-heavy, six-figure build? → A large agency, and budget for proper vendor management.
4. Will you generate full-time software work, every week, indefinitely? → Start the in-house conversation — and until the answer is clearly yes, rent the capability instead of buying it.

A perfectly sensible path many of our clients follow: freelancer or studio for the first project, studio retainer for maintenance and the next few tools, and an in-house hire only if software demand keeps compounding. You don’t have to pick one answer forever.

Questions that expose the wrong choice fast

Whoever you’re evaluating, ask these five — the answers separate professionals from risks faster than any portfolio:

1. “Who owns the code and where does it live?” Right answer: you, in your repository, from week one.
2. “Who maintains this in year three?” Vague answers now are abandonment later.
3. “What happens if you’re unavailable?” Tests the single-point-of-failure honestly.
4. “What would you cut from my brief to reduce the cost?” Professionals subtract; salespeople only add. (Our cost guide shows why scope is the whole game.)
5. “What’s a realistic timeline, and what would blow it out?” Compare against how long these things actually take — anyone quoting half that is quoting the happy path.

The bottom line

Freelancers for small and bounded, studios for important and ongoing, large agencies for big and formal, in-house for continuous and core. The expensive mistakes are mismatches of scale in either direction — a $90k agency engagement for a $12k problem, or a business-critical system resting on one freelancer’s availability.

If your project sounds like studio-sized work, tell us about it — and if it’s honestly a freelancer-sized job or a hire-someone situation, we’ll say so. We’d rather be the people you come back to for the right project than the wrong answer to this one.