In-House, Freelancer, or Squad: Three Ways to Hire Developers (and When Each One Is Wrong)

The person signing the cheque almost never has a hiring problem. They have a workload problem that's been mistranslated into a hiring problem, and by the time it reaches us it's already been framed as a two-way fight: build a team or hire an agency. That framing skips the option most mid-sized companies actually need to weigh.

There's a third choice most people don't put on the list until someone else makes them. A contractor for a single job. An in-house hire for the long haul. Or a squad that does the design, the build, and the cloud work without you having to become a software employer to get it. The trigger is usually the same: the spreadsheet everyone secretly runs the business on has finally broken something expensive, and the off-the-shelf tool bought to replace it doesn't fit how the business actually works.

Which one actually fits your project

Match the hire to the shape of the work, not to your budget or whoever pitched you last.

A single well-defined task suits a contractor. You know exactly what needs building, you can write the spec in a page, and you don't need it touched again in six months. A one-off integration, a script, a report nobody else understands. Hire a contractor, get it done, part ways. Running an ongoing product this way just means re-explaining your business to a new person every few months.

Ongoing core product work suits an in-house hire. If the thing you're building is the product — the software your customers actually touch, the system your revenue depends on — you want someone who accumulates context and stays. That's a hiring decision, not a project decision. It comes with a hiring decision's timeline and cost: headcount, benefits, the whole apparatus.

A project that needs design plus build plus cloud, without four separate hires to get it, suits a squad engagement. This is the shape most of our clients are actually in: a company that needs a dispatch tool built, hosted, and kept running, but has no interest in becoming a software employer to get there. They don't want to hire a designer for six months and a DevOps person forever. They want the thing built and looked after.

None of these is the right answer in the abstract. A five-person freight company patching together a quoting workflow needs a contractor for a weekend, not a squad. A 400-person manufacturer replacing its core ERP probably needs both an in-house owner of that system long-term and a squad to build it. The mistake is picking based on which vendor called first.

What a dedicated squad actually looks like

Strip away the pitch and a dedicated squad is a specific, countable thing: one designer, two engineers, one lead. Not a rotating cast. Not "access to our bench." From $18k a month, billed monthly in advance, on rolling three-month terms.

Compare that against building the equivalent team yourself, and you're not just comparing two monthly numbers. You're comparing our monthly number against recruiting, onboarding, and managing four full hires — before anyone has written a line of code.

The part that actually matters isn't the composition. It's who stays. The named lead stays on the project from the scoping call through launch. No handoff to a junior team once the contract's signed. No new face on month four asking you to re-explain the business.

Three-month rolling terms also mean you're not locked into a year because a sales rep needed the contract value to look bigger. If the work dries up or priorities shift, the term ends on a sprint boundary, not a legal negotiation.

Who owns the code — no matter which one you pick

"You own the code" is easy to write into an agreement. What it actually means, mechanically, is where the repository lives and whose cloud account the app runs in. If the code sits in the vendor's GitHub organisation and the app runs in the vendor's AWS account, you don't own the code. You own a promise about the code.

We build in the client's organisation from day one. Repos live there. Infrastructure runs in the client's own cloud account, not ours. No exceptions, and no separate tier where this becomes true only if you ask for it.

If a vendor tells you that you'll own everything but can't explain where the repository and the infrastructure sit today, ask again before you sign anything. That's the whole question.

How we bill, and how the estimate stays honest

The honest version of "how much will this cost" starts with admitting nobody can price a project accurately before they understand it. So we don't try to.

A discovery week comes first: a flat $4,800, credited back in full if you continue into the project. It ends in a written scope, an architecture sketch, and a fixed estimate. Not a range. Not a "roughly." A number, because by that point we've actually looked at what you're asking us to build.

From there, a fixed-scope project is billed on milestones. Typically 30% at kickoff, then payments tied to phase acceptance, so you're never paying for work you haven't seen. Every project includes 30 days of post-launch fixes. Billing runs Net 14.

The "what if the estimate is wrong" fear is fair. The honest answer: scope changes get priced before the work starts, not billed as a surprise after. If something changes mid-project, you get a number for the change before anyone touches it — not a bigger invoice at the end explaining why.

No, we don't take equity or defer payment

This gets asked, and the answer is no. It muddies the relationship, and it has never once made the software better. We'd rather keep it simple: cash, milestones, clear scope. You know what you owe and when. We know what we're accountable for.

Sometimes the answer is: don't hire a studio

We turn down projects a specialist would build better, or that an existing off-the-shelf product already solves for a tenth of the price. You'll hear that in the first call, not the third.

A niche compliance workflow that three vendors already sell as a subscription doesn't need a custom build. It needs a purchase order. A single automation that a no-code tool handles fine doesn't need engineers at all. And plenty of work genuinely is a one-person, single-skill job that a contractor will do faster and cheaper than a four-person squad standing around a problem sized for one.

Not every project needs a squad. Sometimes a contractor, sometimes an in-house hire, sometimes nothing more than a better-configured version of the tool you already bought. That's the honest answer, and it costs us a sale often enough that we've stopped pretending otherwise.

Start with discovery week, not a hiring decision

You don't have to know which of the three you need before you talk to us. That's what discovery week is for. We work under NDA by default and complete vendor security questionnaires as part of onboarding, so buyers in regulated industries don't have to raise it separately.

Figure out the shape of the work first. The hiring decision follows from that, not the other way around.