TL;DR: Hire a freelancer when the work is well defined, one person can own it end to end, and you want speed and a direct line to the person writing the code. Hire an agency when the work needs several disciplines at once (design, backend, mobile, QA) and you need delivery to survive one person getting sick. Hire in-house when the software is the business, the work will never stop, and you can afford to keep a team busy and managed for years. Most early-stage founders I talk to should start with a strong freelancer or a fractional technical lead, and move to in-house only once they know what they are building and that it works. I have been on every side of this: freelancing for clients in Australia and the US, working embedded inside teams at ARCortex, Geonode, Fortell AI and Tested Media, and stepping in as CTO at RAQTS, Nystag Healthcare XR and Bettershop Consulting.
"Should I hire a freelancer, an agency or my own developer?" is usually asked as a cost question. It is really a question about risk, management and how long the work lasts. The hourly rate is the least interesting number in the decision.
This is how I would think about it if I were the founder, based on what I have seen go well and badly from inside each model.
The three models in one paragraph each
Freelancer. One person, paid by the hour, the milestone or a fixed price. You talk to the person doing the work. They bring their own judgement and usually a specialty. The risk is concentrated: if they disappear, get busy or were weaker than their profile suggested, the project stalls.
Agency. A company that assigns a team to your project, usually with a project manager between you and the engineers. You pay a premium for process, multiple disciplines and continuity. The risk is distance: the people you met on the sales call are often not the people building your product.
In-house. You employ the developers. They know your product deeply, carry context forward for years and are aligned with the company's success. You also carry salaries, hiring, management and the cost of being wrong about who you hired, and those costs do not pause when the roadmap does.
When a freelancer is the right call
A freelancer is the best fit when three things are true: the scope is reasonably clear, one skilled person can carry it, and you want short feedback loops.
That describes a lot of real projects. A first AI voice agent for a clinic. A mobile app MVP with a simple backend. A Unity feature added to an existing app. An integration between a voice platform, n8n and a CRM. These are jobs where a senior generalist with the right specialty will often move faster than a team, because there is nobody to coordinate with.
The advantages I see clients actually value:
- Direct access. You describe the problem to the person who will solve it. Nothing is lost in a handoff.
- Judgement, not just output. A good freelancer will tell you when a feature is not worth building. I wrote a whole post on what to cut from an MVP because that conversation saves more money than any rate negotiation.
- Flexibility. You can scale hours up during a build and down to a small retainer after launch.
Where freelancers go wrong
The failure mode is a bus factor of one. If the only person who understands the system leaves, you inherit a codebase nobody can explain, which is the situation I describe in auditing an inherited codebase. Protect yourself from day one:
- The code lives in your repository, under your accounts, from the first commit.
- Every third-party service (hosting, voice platform, app store, CRM) is registered to the company, with the freelancer added as a collaborator.
- There is a written handover at the end: how to deploy, where secrets live, what breaks and how to tell. I do this for every voice agent handover, and it applies to any project.
A freelancer who resists any of those is telling you something important.
When an agency is the right call
An agency earns its premium when the project genuinely needs several specialists at the same time and you do not want to manage them yourself. A consumer app with custom design, iOS and Android, a web dashboard, a backend and real QA is a lot to coordinate across four separate freelancers.
Agencies also make sense when continuity matters more than cost. If a delay of two weeks because one person is ill would hurt you badly, a team with cover is worth paying for.
Questions to ask an agency before signing
- Who exactly will work on my project, and can I meet them? Not the founder, not the salesperson, the engineers.
- How much of the work is subcontracted? Some agencies are a sales layer over freelancers. That can be fine, but you should know.
- What happens when someone on my project leaves? Ask how context is handed over and whether you pay for the ramp-up.
- Do I own the code, accounts and designs throughout, or only at the end? "At the end, after final payment" turns every dispute into leverage against you.
The best agency engagements I have seen look a lot like working with a good freelancer: a named senior engineer you talk to directly, with a team behind them for the parts they do not cover.
When in-house is the right call
Hire in-house when the software is the product, the work is continuous and you know roughly what you are building. Once a product has users, a roadmap measured in years and a stream of fixes, features and releases, the deep context of a permanent team becomes worth more than anything you save by contracting.
What in-house really costs is not just salaries. It is the time to hire well, the cost of a bad hire (usually months before you notice), the management overhead, and the fact that someone senior has to set technical direction. A founder with no technical background who hires two junior developers and no lead often ends up with an expensive team building the wrong thing confidently.
That last gap is why fractional technical leadership exists. At RAQTS I stepped in as CTO to lead work across Unity, React Native and Next.js during a critical phase, and I have done similar roles for other startups, which I wrote up in being a fractional CTO for three startups. Part-time senior direction plus a smaller hands-on team is often the bridge between "a freelancer built our MVP" and "we have a full engineering department".
The comparison that actually matters
| Freelancer | Agency | In-house | |
|---|---|---|---|
| Best for | Clear scope, one owner | Multi-discipline builds | Ongoing core product |
| Speed to start | Days | Weeks | Months to hire |
| Your management load | Medium | Low to medium | High |
| Risk if one person leaves | High | Low | Medium |
| Product context over years | Depends on the person | Usually low | High |
| Cost shape | Hourly, fixed or retainer | Higher rate, bundled | Salaries, ongoing |
If you are unsure how to price any of these, I compared the contract structures in fixed price vs hourly vs retainer.
What I would do at each stage
Idea, not yet validated
Do not hire a team. Work out whether you need a proof of concept, a prototype or an MVP, and get the smallest one built by a strong freelancer. My co-founder and I got LectureNotes AI to around 10k users without a large team, because the hard part was learning what students wanted, not managing headcount.
MVP with early users
A freelancer or a small agency, plus a clear project brief and ownership of every account. If nobody on the founding team is technical, add a few hours a week of senior oversight so someone is checking architecture and security, not only features.
Growing product with revenue
Start hiring in-house for the core, often beginning with one senior engineer or a technical lead before juniors. Keep specialists on contract for work that is deep but occasional: AR and XR features, native plugins, CI/CD pipelines, AI voice agents. At Geonode I built cross-platform SDK work and Unity and Windows CI/CD pipelines, the kind of specialised job a company needs done well once, not staffed forever.
Red flags in any model
These apply whether you are hiring one person or fifty:
- No questions about your users or business. Someone who quotes a full product from one paragraph is guessing.
- Vague ownership. Code, domains, app store accounts and API keys must be yours.
- Only big-bang demos. You should see working progress every week, not at the end. When I work across time zones, a short written update every day is the default.
- No mention of what happens after launch. Bugs, store reviews, OS updates and API changes do not stop on launch day.
- Promises of "fully done" AI with no testing plan. For anything involving LLMs or voice agents, ask how it will be tested before and after launch. My answer is in regression testing voice agents.
The honest bottom line
There is no universally cheapest option. A great freelancer is cheaper than a mediocre agency, a focused agency is cheaper than a badly managed in-house team, and a strong in-house team is cheaper than renting the same context for years. Pick the model that matches how defined the work is, how long it will last and how much management you can actually provide, then protect yourself with ownership, written handovers and weekly visible progress.
I work directly with founders and teams in the US, UK and Europe as a hands-on engineer and fractional CTO, across AI voice agents, web and mobile apps, Unity and AR/XR. If you are deciding how to staff your next build, more about my background here, or book a call and I will give you an honest take on which model fits.