byldr
ryan@cwynar:~
> cat ./writing/senior-engineering-without-hiring.json

Senior engineering without the hire: the arithmetic

2026-09-10 · 3 min read

There is a decision most founders make once, under pressure, on incomplete information: something important is not getting built, and the options are hire someone, engage an agency, or find a contractor. The comparison usually happens as a gut feeling about cost, which is the least useful axis available.

The useful axes are time-to-first-deploy, who carries the risk, and what you own when it is over.

> the first axis

Start with the calendar, not the rate

Weeks before working code exists
From “we decided” to “it is deployed”
051015Retained operatorContract developerAgency engagementFull-time hire13714
Show the data
RouteWeeks to first deploy
Retained operator1
Contract developer3
Agency engagement7
Full-time hire14
Source: Illustrative, and generous to everyone: the hire assumes a nine-week search plus onboarding, the agency assumes a scoping phase before the build.

The rate per hour is the number everyone compares, and it is the number that matters least. A cheaper hour that starts in fourteen weeks costs you fourteen weeks of the bottleneck, which is the actual bill. Multiply your bottleneck's weekly cost by the delay before you compare any hourly figures at all.

> the honest version

What each option is actually good at

Every one of these is the right answer sometimes. The mistake is picking one for a job it is structurally bad at.

Four routes, honestly compared
Full-time hireAgencyRetained operator
Time to first working codeMonthsWeeksDays
Who carries the risk if it failsYouShared, on paperMostly them
Best forOngoing ownership of a systemLarge scoped buildsA specific bottleneck, fast
Worst forOne bounded problemAnything exploratoryWork needing a team of five
What you own at the endEverything, plus a salaryThe deliverable, sometimes the codeCode in your repo from day one
Cost of being wrongHigh — months and a hard conversationMedium — a contract and a scope fightLow — stop after the week

Note the row people forget: cost of being wrong. A hire that does not work out costs a quarter and a difficult meeting. A week that does not work out costs a week. When you are uncertain about the problem itself — which is most of the time, early — the cheap-to-be-wrong option is worth a premium on the hourly rate.

> against my own interest

The cases where you should just hire

I do retained work, and I will still tell you to hire in four situations:

  • The system is your product and it needs an owner who is still there in three years. Outsourcing the core of the business is a decision you get to make once.
  • You need more than one person's throughput, continuously. A retainer does not scale into a team, and pretending otherwise is how projects go sideways.
  • The work is mostly institutional knowledge — relationships, tribal context, judgement accumulated over years inside your company.
  • You already know exactly what to build and it is eighteen months of work. That is a team's job, not a week's.
> the argument

Why a week is the right size for a first test

Whatever route you eventually take, the first engagement should be small enough to be reversible and long enough to produce something real. A week happens to be both.

What a week actually tests
  1. 01
    Whether the problem is what you think it is.

    About a third of the time, day one reveals the bottleneck is upstream of where everyone was pointing. Finding that out in a week is cheap; finding it out in month three of a build is not.

  2. 02
    Whether you can work with this person.

    Five days of real work tells you more than any number of interviews, and it tells you in both directions.

  3. 03
    Whether the deliverable moves anything.

    Working code in your repo, used by a named person, with a before and after. Not a deck about what could be built.

  4. 04
    What the next month should be.

    You end with either a retainer, a finished thing, or a clear no — all three of which are better than an open question.

The failure mode to avoid at all costs is the six-week discovery phase that ends in a document. Documents do not remove bottlenecks. If a week of the same calendar time can produce something deployed, the document was never the deliverable — it was the hedge.

The senior-architect framing only works if the senior architect is the one writing the code.
The distinction · advisors do not open pull requests

Run the arithmetic on your own situation before you talk to anyone, including me. Weekly cost of the bottleneck, weeks until each route produces working code, cost of being wrong. The right answer is usually obvious once the numbers are on paper, and it is not always the one that sells the most engineering.

Test it with one week

$15,000 of senior engineering against your biggest bottleneck. One agreed deliverable, code in your repo by Friday, no money upfront. Friday we decide retainer, sprint, or handshake.

See how the free week works
More writing