Every founder who's about to spend real money on software eventually hits the same three-way fork: hire a freelancer, hire an agency, or hire an in-house developer. The internet is full of hot takes about which is "best." Most of them are written by someone selling one of the three.
The honest answer is: none of them is best in general. Each is right for a specific situation, and wrong for the others. The wrong choice for your stage will cost you either money, momentum, or control — sometimes all three.
Here's the framework I use with founders. It's not a scorecard; it's a decision tree. If you answer the first question honestly, the rest is almost mechanical.
The three options — what each actually is
Before comparing, get precise about what you're actually buying. Most bad decisions here come from apples-to-oranges comparisons.
Freelancer. One person, hourly or project rate, no company overhead. Cheapest per hour. Fastest to start. Highest key-person risk (they get sick, they take a bigger job, they ghost). No layers of process — for better and worse. Best used for well-scoped chunks with clear success criteria.
Agency. A company. Multiple people can rotate onto your project. They have a sales process, an account manager, defined engagements, and a delivery methodology. Highest per-hour cost (~2-3x freelancer for equivalent seniority) because you're paying for the layer. Lowest key-person risk. Best for complex projects where continuity matters more than cost.
In-house developer. A salaried employee. Highest total commitment (salary + benefits + equipment + management overhead). Deepest context — they live inside your product every day. Slowest to hire well (2-4 months to find, 3-6 months to onboard). Best when the work is ongoing and product-specific enough that context is a real asset.
The question isn't which is "best." It's which fits your specific situation.
Question 1: How long is the work?
This single question eliminates two of the three options in most cases.
Under 3 months of work. Freelancer or agency. In-house is off the table — you can't hire, onboard, and productively deploy someone in under 3 months, and firing them when the project ends is expensive and often illegal (depending on your jurisdiction).
3–12 months of work. All three are viable, but the calculation gets complex — see Questions 2–4 below.
12+ months of ongoing work. In-house or agency. A freelancer is a real risk here — you'll lose them at some point over that window (they always have another client competing for their time), and re-explaining a year of context to their replacement is punishing.
If you're not sure how long the work is, be honest: is this a project (has an end) or an ongoing product (has no end)? A landing page is a project. A SaaS product is not. The mistake is treating an ongoing product like a series of freelancer projects — you end up with 4 different code styles, 4 sets of undocumented decisions, and 4 people who all say the previous person's code is bad.
Question 2: How well-scoped is the work?
Well-scoped: you can write down exactly what "done" looks like in a document a non-developer could read. Clear inputs, clear outputs, clear acceptance criteria.
Not well-scoped: the deliverable is a phrase like "an app for restaurant ordering" or "improve our product." You'd know the answer when you see it, but you can't write it down in advance.
- Well-scoped → freelancer wins on cost. A senior freelancer with a clear brief will out-deliver an agency at half the price, because they're not paying for the account manager, sales process, and PM layer you don't need.
- Not well-scoped → agency or in-house. Loose briefs require someone who will push back, refine, and iterate on scope with you. Freelancers can do this but most will just build what you asked for, and you'll discover the scope was wrong when you're two weeks in.
The unspoken cost of a bad scope: with a freelancer, you'll pay for the wrong thing and then pay again for the right thing. With an agency, you'll pay for the discovery process upfront but usually get a better result. With in-house, they'll refine the scope as they go, which is either the best or worst version depending on your management ability.
Question 3: How much of your time can you spend managing them?
Every one of these three requires management. Anyone who tells you they don't is selling.
Freelancer: you're the project manager, the QA, the requirements author, and the reviewer. Realistic time commitment: 4-8 hours a week for a small project, more for a larger one. If you don't have this time, the freelancer will make decisions in your absence — some good, some not — and you'll be stuck with them.
Agency: their account manager is your first line, but you still need to be available for weekly meetings, review deliverables, and answer questions. Realistic time commitment: 2-4 hours a week. Less than a freelancer, but not zero — the biggest agency failures I see are founders who thought "I hired an agency so I don't have to think about it" and disengaged.
In-house developer: you're their manager. This is a 5-10 hour a week commitment when it's working well, and 20+ hours a week when it isn't. If you've never managed a developer before, this is a real skill and you'll be bad at it for the first six months. The best thing you can do is admit that and get help — a fractional CTO, a technical advisor, or someone experienced who will do the 1:1s and reviews with your developer.
The uncomfortable truth: if you have zero time to manage the developer, none of these three options works. What you actually need is a productized service (Fiverr, template services) or a no-code tool. Any real custom software requires your attention.
Question 4: What's your risk profile?
Every option has a failure mode. Pick the one whose failure mode you can survive.
Freelancer risks:
- They disappear mid-project. It happens more than agencies admit. Mitigation: pay in milestones, own the code from day one, keep credentials in your name.
- Their code is stylistically "theirs" and hard to hand off. Mitigation: require documentation and tests as part of the deliverable, not as an add-on.
- They take a bigger client and your work stalls. Mitigation: written commitment on hours per week; add a kill switch clause if they miss two weeks in a row.
Agency risks:
- You get sold to by the A-team and delivered by the B-team. Very common. Mitigation: contract specifies who's actually working on your project; you have veto over replacements.
- They optimize for their process rather than your outcome. Mitigation: fixed-price or milestone contracts, not time-and-materials.
- Scope creep gets billed as extra. Mitigation: define scope precisely upfront and be willing to say no to your own new ideas mid-project.
In-house developer risks:
- You hire the wrong person and now they're a payroll liability. Mitigation: 90-day probation, clear performance criteria, be willing to end it fast if it's not working.
- They become a single point of failure — you can't fire them because they're the only one who understands the code. Mitigation: require documentation from day one, do code reviews (even if you have to hire someone external to review), never let one person be irreplaceable.
- They stagnate because there's no senior person to learn from. Mitigation: budget for a fractional CTO or advisor if you can't afford a senior + junior.
The decision tree
Put all of that together:
Is the work under 3 months?
├── YES → Is it well-scoped?
│ ├── YES → Freelancer
│ └── NO → Small agency (avoid big ones — overhead eats the budget)
│
└── NO → Is it more than 12 months of ongoing product work?
├── YES → Can you afford $80k-$180k/year in total employment cost?
│ ├── YES → In-house developer (senior)
│ └── NO → Agency on a retainer OR long-term freelancer
│ with a written commitment
│
└── NO (3-12 months) → Do you have >4 hrs/week to manage?
├── YES → Freelancer (if well-scoped) or agency
│ (if not)
└── NO → Agency (they'll manage themselves;
you'll pay for it)The rare fourth option: fractional CTO + junior team
Most founders don't know this exists. If you're in the 3-12 month zone and the work is not well-scoped, sometimes the highest-ROI structure is:
One fractional CTO (senior, part-time, $150-$250/hour, 10-20 hours a month) plus one or two juniors (in-house or freelance).
The fractional CTO does architecture, code review, hiring, and mentors the juniors. You pay senior rates for the 20% of hours where seniority actually matters. The juniors do the 80% of the work that's mostly execution.
Total cost: often lower than one senior in-house developer. Total quality: often higher, because the seniority is concentrated where it matters. Total risk: lower, because losing any one person doesn't kill the project.
This structure isn't advertised because nobody sells it as a package. You have to assemble it yourself. Most founders don't know it's an option, which is exactly why it's still an edge.
A specific example
I worked with a founder who was about to hire a $110k/year in-house senior developer to build the first version of her SaaS product. Total year-one cost with benefits and equipment: ~$150k.
Running the framework:
- Length of work: unclear — she was building an MVP with no idea how long it would take (real answer: 4-6 months to first version, then ongoing).
- Scope: not well-defined. She had a rough shape, not a spec.
- Management time: she had ~3 hours a week and was already stretched.
- Risk profile: could not afford to fire and rehire if the developer was wrong.
The honest answer was: agency for the initial build (fixed-price, 4 months, well-scoped after a 2-week discovery phase), then transition to a fractional CTO plus a junior once the product was in market and the ongoing scope was clearer.
Total cost through month 12: about $95k. Result: MVP shipped on time, first 50 paying customers acquired, then she hired her first in-house engineer with a specific role (integrations) once she knew what the ongoing work actually looked like.
The lesson isn't "always start with an agency." The lesson is: the right structure changes as you learn more about the work. Locking into the wrong structure early — usually because someone convinced you it was "the way to do it" — costs the most.
What to do this week
- Answer the four questions above about your specific situation. Write down the answers. Don't estimate — be honest about scope clarity, management time, and risk tolerance.
- Interview at least one person from each of the three categories even if you think you already know. The interviews themselves will teach you what questions to ask, and the pricing you hear will calibrate your budget.
- Before you sign anything, read the 12 questions to ask before hiring a developer — the questions apply to all three types.
- If your first instinct is "I need a rewrite" or "I need to start from scratch," read the refactor vs rewrite framework first. The right hire depends heavily on what work is actually needed, and most founders overestimate the "rewrite" side of that.
The founders who make this call well aren't the ones with the most technical knowledge. They're the ones who match the structure to the actual work — not to what sounds impressive to say at a networking event.
---
If you'd like a second opinion on your specific structure before you commit — either on the choice itself or on the shortlist you've already built — that's what an independent consultation is for. Reach out via the contact page with a paragraph about your situation and I'll tell you honestly what I'd do in your position.