Automation Thesis

Outsourcing was always about latency, not cost

We told ourselves we outsourced to save money. We actually outsourced to buy capacity we couldn't hire fast enough, and when the wait for capacity drops to zero, the whole logic of what you keep in-house flips.

ASR

Apollo Space Research

Apollo Space

· 10 min read

A company decides it needs a thing built, a campaign, a data pipeline, a month of overflow support, and it does not have the people. So it signs a contract with someone who does. We call that decision a cost decision, because the invoice is the part we see. It was never a cost decision. It was a decision about time.

You didn’t outsource because the outside was cheaper. You outsourced because the outside was already staffed. The capacity existed somewhere else, today, and yours wouldn’t exist for three months. Outsourcing was always about latency, not cost, and the moment the wait for capacity drops to zero, every reason you had to send work outside changes its shape.

This post is about that flip: why we mislabeled the whole arrangement, what actually drove it, and what you keep in-house once the constraint it was solving for disappears.

The story we told ourselves

Ask anyone why their company outsources and the answer comes back in dollars. It’s cheaper. The agency has scale we don’t. Their labor market is lower-cost than ours. Why would we pay to keep a specialist on payroll fifty weeks a year for eight weeks of work?

All of that is true, and all of it is a cover story. The cost framing survives because it’s the part that shows up on a spreadsheet, and spreadsheets are where we go to feel rational. But it explains the wrong thing. It explains why, once you’d decided to send work outside, you picked this vendor over that one. It does not explain why you sent the work outside in the first place.

Run the test. Imagine the outside vendor cost exactly what an internal hire would cost, same all-in price, to the dollar. Would you stop outsourcing? Mostly, no. You’d still send the overflow out, still call the agency for the launch, still spin up a contract team for the migration. Because the thing you were buying was never the lower price. It was the fact that you could start on Monday instead of after a hiring cycle.

You didn’t outsource to save money. You outsourced to skip the wait.

The cost was the tiebreaker. The latency was the reason.

What you were actually buying

Here’s the naive model of why work goes outside, the one most org charts are quietly built on: some work is non-core, so we hand it to someone whose core it is. Support isn’t our craft; let a support firm do it. Content isn’t our craft; let an agency do it. Clean, tidy, and mostly wrong about the mechanism.

The reason it’s wrong is that “core vs. non-core” doesn’t predict what actually gets outsourced. Companies outsource things that are absolutely core all the time, a startup outsources its entire early engineering because it can’t hire engineers fast enough, not because engineering is non-core. And companies keep deeply non-core things in-house for years because someone happened to already be sitting there. The core/non-core story is a justification we apply after the decision, not the thing that drove it.

What drove it was a gap between two clocks. The work needed to start now. The internal capacity to do it would arrive later, after the req was approved, the role was posted, the candidates were screened, the offer was signed, the notice was served, the onboarding was survived. Call that gap the staffing latency. It’s measured in months, and the business rarely has months. So you reach outside, where the staffing already happened, on someone else’s clock, before you needed it.

Outsourcing was always about latency, not cost. The vendor’s real product was never their labor. It was their standing capacity, people already hired, already ramped, already idle enough to take your work today. You weren’t renting skill. You were renting the months you didn’t have.

A company needs work done now but its own capacity arrives only after a long hiring cycle of req, posting, screening, offer, and onboarding, so it reaches across the gap to an outside vendor whose people were already hired and ramped on someone else's clock, buying not cheaper labor but the months it did not have.

And once you see it as a latency purchase, the costs you were actually paying come into focus. You paid them, you just didn’t put them on the invoice.

The bill the spreadsheet didn’t show

The vendor’s price was the small bill. The big one was everything that came with sending work across the boundary.

Every piece of outsourced work has to be specified hard enough that a stranger can do it without you in the room, and writing a spec that survives contact with an outsider is genuinely expensive. Then it has to be handed off, and the handoff is where context goes to die: the thing you knew and didn’t write down is exactly the thing that comes back wrong. Then it has to be reviewed, because you can’t trust output from a clock you don’t control, so you read it all anyway. Then the context lives outside your walls, the campaign history, the support patterns, the tribal knowledge of how your migration actually went, and when the contract ends, it leaves with the vendor.

The naive accounting says outsourcing trades a higher internal cost for a lower external one. The real accounting is uglier: you traded a capacity problem for a coordination problem. You solved “I can’t staff this in time” by buying “now I have to spec it, hand it off, chase it, review it, and watch the knowledge walk out the door.” For a lot of work, that trade was still worth it, because the staffing latency was the harder constraint. But nobody should pretend the coordination tax was free. It was the price of borrowing a clock you didn’t own.

So the real question was never “internal or external is cheaper.” It was “which is worse, the wait, or the handoff?” And for forty years the wait usually won, so the work went out.

What happens when the wait goes to zero

Now change the one variable everything hung on.

Suppose the standing capacity is no longer something only a vendor has. Suppose your own company can stand up a unit of capacity, a worker that reads your inbox, drafts the campaign, runs the migration, handles the overflow, in the time it takes to describe the job, not the time it takes to hire for it. The staffing latency that sent work outside for four decades doesn’t shrink. It collapses.

Watch what that does to the trade. The reason to outsource was: the outside is already staffed and I’m not. But if you can be staffed on demand, the outside’s one real advantage, its standing capacity, stops being scarce. You no longer have to borrow someone else’s clock, because your clock now runs at the same speed. The latency that made outsourcing rational is the exact thing that just went to zero.

When you can staff capacity on demand, the reason to send it outside disappears, and the reason to keep it inside comes back.

And here’s the part that surprises people: the coordination tax doesn’t just shrink, it nearly inverts. The whole reason the handoff was so expensive was that the outsider had none of your context. An in-house worker that can read your company’s own memory, the campaign history, the support patterns, the way your last migration actually went, doesn’t need the spec written to survive a stranger, because it isn’t a stranger. The context that used to walk out the door at contract-end never leaves the building. You stop paying to ship knowledge outside and re-import the results.

This is not “AI makes outsourcing cheaper.” That would be missing it entirely. It’s that the constraint outsourcing existed to solve, staffing latency, is the constraint that’s evaporating. When the reason for a structure disappears, the structure doesn’t get optimized. It gets reconsidered from scratch.

Two ways to get work done when you lack the people. On the left, the old path: write a hard spec, hand it across the boundary to an outside vendor's standing capacity, review the result, and watch the context leave when the contract ends. On the right, the new path: describe the job to in-house capacity that reads your company's own memory, executes against your real context, and keeps the knowledge inside the building.

So what do you actually keep in-house?

If latency was the reason work went out, and latency is gone, the lazy conclusion is “bring everything back.” That’s as wrong as the cost framing was. The right move is to re-ask the only question that ever mattered, now that the answer has changed.

For decades the question was can I staff this in time? and the answer was usually no, so the work left. Now the answer to “can I staff this in time” is yes for an enormous amount of routine, specifiable, high-volume work, the overflow support, the first-draft content, the data plumbing, the standing operations that were outsourced precisely because they were predictable enough to hand off. That work has no reason to live outside anymore. Its defining trait, that it was specifiable enough for a stranger, is exactly what makes it easy to bring back in.

What stays genuinely outside is a much shorter list than your current vendor roster: the things you outsource for a reason other than latency. Real outside judgment you don’t want to be neutral on, the auditor whose value is independence, the lawyer whose value is being adversarial to your own optimism. Specialized physical capacity. Regulated work where an outside party’s signature is the product. Those were never latency purchases. They survive.

Everything else, the long middle of your vendor list, the work you sent out because you couldn’t staff it fast enough, comes home. Not because in-house is suddenly cheaper. Because the one thing that made outside worth the coordination tax just stopped being scarce.

The turn: the boundary was never where you thought it was

Step back from the agents and the invoices and there’s a plainer thing underneath.

For most of business history, the wall between “inside the company” and “outside the company” was drawn by a single constraint: how fast you could turn money into working people. Slow. Always slow. That slowness is what made the company a building of people you hired ahead of need, and it’s what made everything you couldn’t hire ahead of need into someone else’s job. The org chart, the vendor list, the whole shape of who-does-what, all of it was a workaround for one stubborn latency.

When that latency goes to zero, the wall doesn’t move a little. It stops being load-bearing. The question changes from who can I get to do this in time to what do I actually want done, and to what standard. That’s a better question to be the person answering. It’s the one only you can answer, what the company is for, what “good” means here, which work is worth doing at all. You spent decades managing the gap between needing capacity and having it. The gap is closing. What’s left is the part that was always the real job.


That’s what we’re building at Apollo Space, not a cheaper outside vendor, but an operating system that gives your own company standing capacity it can read its own memory and execute against your real context, so the work you used to send out because you couldn’t staff it in time can simply come home. If you’ve ever signed a contract because you needed it done Monday and couldn’t hire by then, you already knew, somewhere, that it was never about the price. It was about the wait.

Apollo runs your company's repetitive ops so your team doesn't.

Join the waitlist for early access, founding-user pricing, and a front-row seat as we ship.

Join the waitlist