Do the hourly math honestly and it says hire. When a studio is still worth buying

Per hour, a studio costs more than your employee. Do the math honestly and it says hire. We sell outside builds, and we still think that answer is right for year-round work.

The only studio worth buying is a bounded build: an acceptance test written before the estimate, an end date, and a handover to someone on your side who agrees to own the result. In our view, anything open-ended is capacity rented at a premium.

This is episode two of Build, buy or hire. Episode one covered companies that cancelled a software purchase because they could build it themselves (McKinsey, August 2026). This one takes the next question: if you build, who does the building?

The math, done against us

KORE1's 2026 guide to hiring AI engineers compares a full-time senior engineer with a contractor. Here is its worked example:

Full-time senior AI engineer
  base salary              $185,000 – $260,000
  loaded cost              $235,000 – $330,000

Contractor
  hourly rate              $160
  full-year hours          × 1,800
  annual total             $288,000
  payroll tax, benefits    not included

KORE1's conclusion: "And it's still more than the employee once you do the comparison honestly."

We don't dispute it. If the job is a year of steady engineering, hire.

Where the comparison flips: duration

The same guide prices two more things, and they point the other way.

time to first commit
  new hire                 4–8 weeks
  outside help             days to 2 weeks

defined-scope build        ~4 months, ~$100,000

The guide's own reading is that the build is not what loses the comparison. The wrong duration is. We agree: a contractor on a rolling year loses to the employee, while the same outside help on a scoped build starts sooner and has an end.

What the spreadsheet leaves out

Two costs rarely make it into a build-or-hire table.

The first attempt that failed. Stanford's Digital Economy Lab studied successful enterprise AI deployments and still found that "61% of successful projects included at least one prior failure, whose costs never appear in the final ROI." Two thirds of the companies it investigated had significant failed attempts before they reached value. And 77% of the hardest challenges were invisible costs: change management, data quality, process redesign. None of those show up on an engineering invoice, ours included.

Owning it afterwards. One story keeps coming up this year: the in-house build that boomerangs. As it is usually told, the reason is not that building was hard. It is that nobody agreed to own the result: security, compliance, uptime, support, a roadmap. We have seen this argued in a couple of small-audience videos, not measured, so treat it as a pattern to watch rather than a rate.

Our read: both costs argue for the same shape of work. A bounded build names the invisible work up front and ends with a named owner. An open-ended engagement puts off both questions.

What makes a build bounded

Three things, each written down before work starts.

1. An acceptance test before the estimate

For every task that matters, write a work contract: what goes in, what comes out, and what counts as a good result. Without one, quality control comes down to a person reading the output and deciding it sounds clever. That is not a test. The framing comes from a widely shared talk on scoping AI agents. The example below is our version of it.

task         brief a salesperson on a company before a meeting

inputs       company name and website
             the person being met
             what we sell

outputs      overview, recent news, decision-makers
             fit, risks, questions to ask
             sources, confidence level

good result  every claim traces to a source
             nothing invented
             unknowns stated as unknowns
             recommendations match what we actually sell

In our view, the estimate should hang off the "good result" lines, not off a feeling about the task. If a proposal has no such lines, nobody can say when the work is done.

2. An end date

Our view: a date turns duration from a running cost into a decision you can revisit. Without one, the proposal quietly becomes the annual contractor line in the first table.

3. A handover someone on your side can own

The deliverable is not only the code. It is whatever lets someone who did not write the code run it. On one recent engagement, the handover was six documents:

handover/
  admin-guide
  runbook
  costs
  intake-checklist
  security-notes
  known-issues

If nobody on your side will put their name on the runbook, the build is not bounded. We'd call it the boomerang from the previous section, just delayed.

Our example: count before you design

That same engagement (the client stays anonymous) started with a brief and a folder of media rather than a specification. Before any design, we read every post the client had published over ten months, all 64 of them, and counted.

posts read                             64, over ten months
two services named in the brief        2 posts between them
two other services                     40 and 49 posts
posts in a single language             62 of 64
posts asking people to book            29
ways to actually book from them        none

The brief did not survive the count, and the count became the scope. That reading produced 1,917 lines of research across twelve documents before the first line of application code. The work closed with the six-document handover above.

The sentence we kept from it: if you cannot state what your client sells in units of their own content, what you are about to design is their opinion of themselves.

That is an acceptance test the size of a whole project. The scope was checked against something countable before anyone priced it.

When to hire instead

Our rule of thumb:

• The work has no natural end, like a product you will keep developing every week.
• You need the same skills for a year or more. Then KORE1's arithmetic applies in full.
• Nobody on your side could own a handover yet. Hire the owner first.

What would change our mind

If a new hire could start as fast as outside help, the bounded build would lose its clearest edge over hiring. If that happens, we'll say so here.

FAQ

Isn't a studio always the expensive option? Per hour, yes. KORE1's comparison says so, and we agree. For a bounded build, the useful comparison is the cost of a finished, dated outcome, not an hourly rate stretched across a year.

How can I tell if a proposal is bounded? Look for three things in writing: acceptance criteria for each task, an end date, and a handover with a named owner on your side. If the proposal reads like an hourly rate times a year, compare it with a hire, because that is what it is.

We already built something in-house and nobody owns it. Now what? In our view, what's missing is an owner, not another build. Start with a runbook and a known-issues list, and see who is willing to sign them.

Why write the acceptance test before the estimate? Because an estimate without one prices a guess. Once the inputs, outputs and good result are written down, the estimate has something to be checked against, and so does the finished work.

Bounded is about a written end, not a small scope. For what depth looks like on a longer engagement, see the RE Intelligence case: half a year of study, polishing and implementation on top of Dubai's property registry. The short version of this argument, with the arithmetic, is here.