JA

Why do you have to outsource work your own team could finish quickly?

Here is what this post covers:

Introduction

“We could finish this ourselves in two weeks…”

Have you been thinking that a lot lately? I feel it even more now that AI and IaC have made writing code so much easier.

Writing the code takes less time than it used to, but the process around it has not changed: request a quote, get approval, sign a contract, wait for the vendor to start, receive the delivery, sign off on it. The faster the work itself gets, the more the steps around it stand out.

Some background for readers outside Japan. In Japan, it is common for a company to have its systems built and maintained by an outside IT vendor, often called an SIer (system integrator), rather than by its own engineers. About 72% of Japanese IT professionals work at IT vendors and only about 28% at the companies that use the systems. In the US the split is roughly the reverse, at about 35% and 65%. So when a Japanese company wants to change its own system, the default path is usually to ask the vendor that built it, and that is where the process above comes from.

Bringing work in-house means building the ability to handle development, operations, and improvements with your own people instead of contracting them out. In this post I sort out situations where you could technically do the work in-house but end up outsourcing it anyway, and how to think about getting out of them.

The examples for each situation are my own summary, based on publicly available articles and common patterns in the field.

What changes between in-house and outsourced work

In-house work goes notice, fix, release. Outsourced work adds request and quote, approval and contract, and waiting before the fix, and acceptance after it. The fix itself is the same In-house Notice Fix Release Outsourced Notice Request Approval Wait Fix Acceptance Release Waiting from request to start Sign-off

The dashed boxes are the steps added on top of the fix itself. The fix takes the same effort either way, but outsourcing adds the wait from request to start, plus acceptance at the end. The faster AI makes the fix, the larger the share of the total that waiting takes up.

Outsourcing lets specialists deliver reliably, but every small change needs a new request, and the knowledge tends not to stay inside the company.

Seven situations that force you to outsource

#SituationIn-houseOutsourced
1Contract limits (maintenance scope, copyright, exclusive operation)You fix it yourselvesOnly the vendor can touch it
2Environment and access walls (no access to production, source, or the DB)Look directly and fixStarts with an investigation request
3Black box (no record of design intent, no spec)Understood in-houseOnly the vendor knows
4Procurement and approval rules (heavy approval even for small amounts)Start right awayWeeks of quotes and contracts
5Security and audit requirements (separation of duties, approved contractors)Handled by internal controlsSometimes easier to clear with an outside party
6Staffing limits (people exist but have no capacity)Possible in principleNo choice but to send it out
7Accountability (wanting the contract to split responsibility for incidents)Your company’s responsibilityMade explicit in the contract

1–3: Lock-in and hollowed-out knowledge

The system runs, but nobody in the company can explain why it was designed the way it was. Every spec change becomes a request to the vendor, which costs both money and time.

A loop: handing everything off leaves design intent outside the company, so every change goes to the vendor, switching becomes impossible, leverage on price and schedule drops, and you end up handing off even more Hand everything off Design intentstays outside Every change goesto the vendor Cannot switcheven if you want to Less leverage onprice and schedule back to handing off

4–7: Organizational and institutional causes

  • Approval and purchasing rules are built on the assumption that work will be outsourced
  • In-house engineers are fully booked with their main work and have no time for improvements
  • There is no setup for maintaining what gets built in-house (avoiding single points of knowledge, keeping quality up)
  • An organizational culture that feels safer when a contract names who is responsible

None of these change when AI lets you write code faster. How many approval steps there are and how responsibility is split are organizational decisions, not technical ones.

When outsourcing makes sense

Bringing everything in-house is not the answer. It is more realistic to draw the line between in-house and outsourced work area by area than to apply one rule across the company.

CriterionSuits in-houseSuits outsourcing
Link to competitive advantageSource of differentiationRoutine work common to the industry
How often it changesChanges oftenRarely changes
ExpertiseCore skills you should build upHighly specialized and inefficient to train for
Demand patternOngoingA temporary need for lots of development capacity
Know-howYou want to keep the design intentGetting the result is enough

One-off or short projects (say, six months or less) and hypothesis testing with an MVP are generally considered good fits for outsourcing.

Decision tree: if it is core to the business, frequent changes point to in-house and infrequent ones to a hybrid. If it is not core, one-off or short-term work points to outsourcing, and the rest to considering SaaS or a package Something to build Core to thebusiness? Changesoften? One-off orshort-term? Yes No In-house Hybrid Outsource SaaS or a packageis worth a look Yes No Yes No

How to work your way out

Three stages: co-create (build together), then transfer (hand over knowledge and access), then self-run (run it in-house) Co-createbuild together Transferpass on know-how Self-runrun it in-house
  1. Revisit the contract: make delivery of source code and design documents, and the scope of operations, explicit
  2. Set up access and environments: give the in-house side read-only access and a staging environment too
  3. Leave documentation behind: have the vendor put the design intent into words every time
  4. Move over in stages: go through the three stages in the diagram above, co-create, transfer, self-run
  5. Go hybrid: keep the core and frequently changing parts in-house, and outsource stable areas and peak periods

Aiming for full in-house development all at once means hiring and training, single points of knowledge, and quality assurance all hit you at the same time. The goal is not cutting outsourcing costs but speed and learning.

Wrapping up

“In-house or outsource” is not a binary choice. The real question is which parts you do yourselves and which parts you rely on outside help for.

The next time you think “we could finish this ourselves so quickly,” start by looking not at the technology but at where things are stuck: the contract, access, knowledge, or the rules.

References