Should You Insource or Outsource System Development?

"Management has decided to strengthen the IT department and bring development in-house. But we can't settle how much we should do ourselves."

"Every change to the system we outsourced takes a month. Wouldn't it be faster to own it ourselves?"

"We moved development in-house, but after the person who built it left, nobody could touch it."

Should you insource system development or outsource it? Consultations on this question start with comments like these.

Let me state this article's position up front.

For many companies, insourcing is the right direction. However, it is not realistic to keep sustaining complete insourcing, development included, on your own. Technology options keep multiplying, and the skills required keep changing. For a business to maintain, on its own, a team that can keep up with all of it is too heavy a burden.

On the other hand, continuing to outsource also has its limits. If the core of your business stays outside the company, you cannot change it when you want to.

The realistic answer lies in between: a state where, as the business moves forward, technology and patterns of decision-making gradually transfer into the company. This article lays out how to build that.

We (wesionaryTEAM) are a contract development company, and at the same time we build and run our own business tools. I write from the position of having experienced both sides: building systems, and owning them in-house.

What Insourcing, Outsourcing and Contract Development Each Mean

If the scope of these words is misaligned, the discussion goes nowhere. Let's align them first.

Insourcing means switching system development or operations that had been entrusted to outside parties over to your own staff. It does not mean bringing everything in-house.

Outsourcing is the general term for entrusting system development to an outside company. There are several forms of contract.

Contract development is a contract in which payment is made for delivering a deliverable. The contracted company handles everything consistently, from defining the requirements through design, development and testing.

Easily confused with this is SES (system engineering service), where payment is made for engineers' working hours. It is a contract to supplement staff, not one that promises a deliverable. Both may be called "outsourcing," but responsibility lies in completely different places.

When considering insourcing, it is worth confirming first whether what you are comparing it against is contract development or SES. For how contract development itself works and the forms of contract involved, see What Is Contract Development? Contract Types and What to Decide Before Ordering.

Pros and Cons of Outsourcing

Before getting into the decision criteria, let's lay out the strengths and weaknesses of each.

Advantages of Outsourcing

You can start without hiring. You can begin development without employing engineers. The time spent recruiting and training talent is cut out entirely.

Specialist skills are available right away. You can secure people well-versed in a specific technology for just the period you need them. You don't need to keep them on staff permanently.

Costs arise only for the period you need. When the project ends, the costs stop too. They don't become fixed costs.

No added burden on your staff. You avoid piling development work on top of people who already have their own jobs.

Disadvantages of Outsourcing

Know-how tends not to stay in-house. The reasons behind the design and the practical knowledge needed for operations accumulate outside. Unless you deliberately take them over, you will have to rely on outsiders next time too.

Every change takes time. Each time, there is a round trip of estimate, agreement and kickoff. The more changes there are, the more this waiting time piles up.

You hand information to outsiders. Business details, customer data and, in some cases, technical secrets are shared with the contractor. You need agreements on how they are handled.

Misunderstandings happen easily. If something is built without the business side's intent fully coming across, you end up with something that works but isn't used.

Pros and Cons of Insourcing

Advantages of Insourcing

Know-how stays in-house. Why a design was chosen accumulates in the company along with the people. Your next decisions get faster.

You can respond flexibly to changes. You can fix something the day after you think of it. The speed of the business and the speed of development converge.

You can reduce the risk of information leaks. You can handle customer data and confidential information without letting it leave the company. In areas with strict security requirements, this can be the deciding factor.

People who understand the business deeply build it. Because the people doing the work know what a feature is for, specifications get nailed down faster.

Disadvantages of Insourcing

It becomes a fixed cost. Personnel costs continue even during periods with no development projects.

Hiring and training cost money. On top of the cost and time of recruiting, you need a period for new hires to understand the business and the existing systems. When securing IT talent is itself difficult, this becomes the biggest constraint.

Knowledge tends to get locked in individuals. If work proceeds without anyone to review it, more and more things can be touched only by one person.

It is harder to keep up with the latest technology. With a small team, the range of technologies you can handle is limited.

Five Criteria That Shape the Decision

Insourcing versus outsourcing is not a question of which is superior. Nor is it about choosing one for everything. You look at it system by system, area by area. Looking at the following five points makes the decision possible.

1. Is the system at the core of your business?

Parts that directly affect revenue or customer experience, and parts that are themselves what differentiates you from competitors, are worth keeping in-house. Conversely, there is little reason to build things in-house, such as attendance management or expense reimbursement, whose requirements don't differ much from company to company.

2. How often will you change it?

Systems whose specifications change several times a month are suited to in-house development. With outsourcing, each change involves an estimate and coordination, so the more changes there are, the more waiting time piles up. Conversely, something that won't be changed for several years once built usually costs less in total when outsourced.

If you're unsure, count how many times you changed that system in the past year.

3. Can you hire people and keep them?

This is the point most often taken lightly in insourcing discussions. Even if you can hire one engineer, if everything stops the moment that person leaves, you haven't really insourced.

What you need is not one person but a team whose members can review each other's work. That means several people at minimum, and the question is whether your company is attractive enough to keep hiring talent.

There are three things to check.

First, whether you can realistically hire. If you plan on the assumption that people will come once you post a job, that is where the plan stalls. Check first whether your salary levels, development environment and the discretion you give are in line with the market.

Second, whether you have someone who can evaluate engineers. To hire engineers, you need someone who can evaluate engineers. If no such person is in-house, your hiring accuracy won't improve. This is one of the reasons to team up with outside partners during the transition.

Third, whether you can give people reasons to stay. If you entrust them with the core of the business, the work needs to be interesting to them. If all you give them is operations duty, you may be able to hire them, but they won't stay.

4. By when do you need it?

For a project that is pointless unless it is running in three months, starting with hiring is not realistic. Assuming three months to hire and three months to ramp up, the earliest you could start in-house is six months from now.

The split is: outsource what you need in the short term, and insource what you build up over time. If you need both, you can release the first version through outsourcing, build your in-house team in parallel, and move to in-house development from the next version.

5. How do you look at cost?

Here, the short term and the long term reverse. Comparing only initial costs leads to wrong decisions, so the next section covers this in detail.

Costs Reverse Between the Short and Long Term

Outsourcing costs arise in lump sums per project. In-house costs keep arising every month as personnel costs.

Things that end quickly, or that won't change once built, cost less when outsourced, because you don't have to hire anyone.

On the other hand, for systems you will use for years with continuous changes, the balance reverses partway through. Outsourcing incurs a cost with every change, while in-house development can handle changes within its fixed costs.

However, in-house costs include items that are easy to overlook.

• The cost and time of hiring (around 30% of annual salary through a recruitment agency, plus internal time spent on selection)
• The training period (even experienced hires need several months to understand the business and existing systems)
• The effort spent on reviews and documentation to keep knowledge from being locked in individuals
• Licence fees for the development environment, cloud and various tools
• Rehiring and handover if the person you hired leaves

Comparisons claiming that "personnel costs are cheaper than outsourcing fees" usually don't count the five items above. If you compare, line up the total over about three years.

An Example Comparison

Take, for example, a system that is modified twice a year.

If you outsource, there is a cost for each modification on top of the initial development cost. Over three years, that is one initial build and six modifications.

If you develop in-house, engineers' personnel costs arise continuously for three years. Including the hiring and training periods, actual development can start only a few months after they join.

With two modifications a year, outsourcing usually costs less in total. With two modifications a month, the balance reverses, because with outsourcing the back-and-forth of estimates and coordination alone eats up the time.

Count the number of changes before comparing. If you decide by feel that "in-house should be cheaper," you will usually be wrong.

Outsourcing costs are sometimes expressed as person-month rates: the cost of one engineer working for one month, multiplied by headcount and duration to arrive at the total. When comparing this with in-house personnel costs, note that the rate also covers time spent outside development (estimates, coordination, reporting). The same time arises in-house too, but it is buried in personnel costs and harder to see.

Also, when estimating personnel costs, it is wiser to avoid using published average salaries. Published average annual salaries for IT engineers range from the ¥4.5 million range to the ¥7.3 million range, depending on the survey. What you should use is not the average but the amount your company can actually offer. That also lets you check whether you can hire at that level.

What Happens When You Try to Insource Everything

Insourcing itself is the right direction. But when you try to bring everything in at once, certain things commonly happen.

Progress stalls. Hiring doesn't go as planned, and keeping existing operations running takes all your capacity.

Quality is unstable. You keep building without anyone able to review, and you are left with things that run but that nobody can fix.

You depend on specific individuals. This is the "after the person who built it left, nobody could touch it" mentioned at the start. A system that was supposedly insourced becomes less flexible than an outsourced one the moment that person is gone.

It gets slower than when you outsourced. Because there is no one in-house who can make decisions, waiting for confirmation increases.

These are not problems of ability but of approach. This is what happens when you try to take everything in without a foundation.

Put the other way, they can be avoided if you don't try to take everything in. If you don't assume you will keep up with fast-changing areas yourself, and leave parts where you continue to use outside capability, the burden on your team won't become this heavy.

What you need first, in order, are things like these: a development environment and testing setup, a habit of code review, and a way of working that decides what not to build. If you add people without these, knowledge locked in individuals spreads as fast as headcount grows.

The Realistic Option Is to Split Ownership (the Hybrid Model)

You don't have to choose between insourcing and outsourcing. Owning different areas in different ways is called the hybrid model. In practice it is the most common outcome, and it is also the most sustainable form in a fast-changing environment.

The essence of insourcing is not taking over all outsourced work wholesale. Own the parts that are at the core of the business and change often, and leave highly specialized, rarely changed parts to outside partners. It is about where you draw this line.

Concretely, the split looks like this.

This line is not decided once and done. When the business changes, so does its core. Plan on reviewing it at least once a year.

When in doubt, ask yourself: "Would it be a problem if this system were built the same way as a competitor's?" If not, it is an area you can hand outside. If so, that is your core.

There is one more perspective that helps draw the line: whether the business-side owner of that system can say in detail, "this is how we want it." Areas where they can say it in detail require business understanding and are worth keeping in-house. Conversely, areas where "please handle it well" is enough can go outside without trouble.

Note that once you decide to split ownership, designing the boundary itself becomes important. If in-house parts and outsourced parts are tightly intertwined, both become hard to change. Decide the form of data exchange first, and keep the two from affecting each other. This is worth investing effort in at the start.

Which Fits You: A Rough Guide

Let me also restate the criteria from the viewpoint of a company's situation.

When outsourcing fits

• You have no engineers in-house who can develop, or no prospect of hiring them
• There is a fixed deadline, and it must be running within six months
• The system won't be changed for a while once built
• It is an area such as authentication infrastructure or infrastructure setup that is highly specialized and has little point being maintained in-house
• Development is temporary and you don't have a steady volume of projects

When insourcing fits

• The system directly affects revenue or customer experience and is core to the business
• Its specifications change several times a month
• It handles customer data or confidential information you don't want to leave the company
• You can expect to hire and retain several engineers
• You will keep using it for several years, with continuous changes

It is normal for items on both lists to apply. In that case, assume a hybrid model and think about where to draw the line.

What to Check When Choosing an Outsourcing Partner

For the parts you outsource, here are points worth checking.

• Contract type. Is it contract development with responsibility for the deliverables, or a contract for working hours?
• Assumptions behind the estimate. Requirements organization, UI/UX design, testing, cloud costs, handling of spec changes, and maintenance after launch: which of these are included?
• How changes are handled. Does every spec change mean a new estimate, or are changes absorbed within a certain range?
• Whether it is built to be handed over. If you may insource in the future, say so at the start. It changes the design.

The last point is especially important. Development where the vendor has been told you eventually want to insource is built differently from development where it hasn't. If you tell them later, the system may need to be rebuilt.

Specifically, when handover is assumed, differences like these appear: choosing technologies that are easy to hire for in the market; reducing custom-built work and aligning with common architectures; documenting the reasons behind the design; and writing tests thorough enough that others can make changes with confidence.

All of these are detours if you look only at development speed in the moment. If the handover assumption isn't shared, the development company will choose the faster route. That isn't wrong; the assumption simply wasn't communicated.

Through our system development service, we handle everything consistently from requirements definition through design, development and operations. We also publish our case studies.

Practical Points When Using Contract Development

For areas you decide to outsource, here are points on contracts and process that will make things easier later.

Don't fix the total price before the requirements are settled. If you put a price on things that haven't been decided, the development company will either add a margin for the uncertainty or interpret the scope narrowly. Either way, the ordering side loses. One approach is to split requirements organization into a separate contract.

Decide up front how changes are handled. Specs changing during development is nothing unusual. At contract time, put in writing whether a change leads to a new estimate or is absorbed within a certain range.

Write down acceptance criteria first. If you proceed with "complete" only vaguely defined, disputes arise at delivery. List, feature by feature, what must work for you to accept it.

Decide who handles operations. Who takes inquiries after launch, and who makes the call when there is an outage? If you launch without deciding this, things grind to a halt right after launch.

Confirm the rights to the deliverables. Which party owns the copyright to the source code matters if you insource in the future.

All of these are items that are too late to confirm once a dispute arises. If you align them when comparing estimates, you will also see where the differences in price come from.

How to Use Outside Partners When Insourcing

You don't need to make it a binary choice of "we're insourcing, so we'll stop outsourcing." During the transition period, using outside partners makes things move faster.

Hand over while building together. Outside engineers and your engineers develop as one team, handing over as they go. This takes root far better than handing over documents and calling it done.

Set up the foundation first. If you prepare the base, such as the development environment, testing setup and deployment procedures, in advance, the people you hire can get moving right away.

Hand over the patterns of decision-making. The way of deciding what not to build and the points to look at in reviews are harder to hand over than the systems themselves. There is value in doing this part together.

A realistic order for the transition is as follows.

First, choose one target: something at the core of the business that changes often. Don't try to switch all of the company's development at once.

Next, prepare the foundation: the development environment, testing and deployment procedures. Without these, the people you hire will spend their first few months setting up environments.

Then, build together. Outside and in-house engineers work as one team and touch the same code. It is not a case of the handing-over side writing and the receiving side reading; both write.

Finally, step back. If you start without deciding this, the side-by-side phase goes on indefinitely. Decide at the start what needs to be possible before the outside team steps back.

We offer this as DX promotion and in-house development support. The team that shaped the concept carries on into implementation and operations, while handing over to your team in parallel.

If you are at a stage where what to build isn't even settled yet, as with a new business, starting with PoC and MVP development may be faster.

Our Position

We are a contract development company. Even so, we neither push insourcing nor push outsourcing.

The reason is that going all-in on one or the other has become hard to make work in today's environment.

Technology options turn over within a few years. In cloud architecture, development methods and the use of AI alike, what was common sense a few years ago no longer holds as is. Keeping up with this change using only your own staff is a burden that lies outside a business's core work. Yet if you leave everything to outsiders, you can't change the core of your business yourself when you want to.

What we practice is co-creation. Rather than splitting into client and vendor, we move the business forward as one team while handing over technology and patterns of decision-making.

Specifically, it works like this.

Build together. Outside engineers and your engineers touch the same code. It is not the handing-over side writing and the receiving side reading; both write.

Don't stop the business. There is no need to halt development for training. As the business moves forward, we share the technologies used and the reasons behind decisions.

Make it a form where your people grow. The way of deciding what not to build, the points to look at in reviews, the reasons behind the design: these are harder to hand over than the systems themselves.

Decide the conditions for stepping back. At the start, we decide what needs to be possible before working side by side ends. If you start without deciding, it goes on indefinitely.

Insourcing is a direction, not a destination. Bringing everything in-house is not the goal. In fast-changing areas, the realistic form is to keep using outside capability while widening the range of what you can decide in-house.

Our experience building our own tools also supports this approach. We built our business tool "projectAI" ourselves and use it daily in-house. As we announced in July 2026, we implemented 73 screens and 31 AI features in about 4.5 months. We know what happens when you own a system in-house from experience, not from the imagination of a supporting party.

Finally, a word on recent changes. AI-assisted development has raised the speed of implementation. As implementation gets faster, the speed of deciding what to build becomes the speed of the business. This judgment can only be held in-house, so growing people in-house who can make it matters more than before. On the other hand, the patterns of AI-based development themselves are learned faster by bringing them in from outside. Here, too, splitting ownership pays off.

Frequently Asked Questions

Which is cheaper, insourcing or outsourcing?

It reverses depending on the time frame. Things that end quickly, or that won't change once built, cost less when outsourced. Systems you will use for years with continuous changes favor in-house development from some point on. When comparing, line up the total over about three years, including hiring costs, training periods, the effort to keep knowledge from being locked in individuals, and development environment costs.

What is the difference between contract development and SES?

Contract development is a contract in which payment is made for delivering a deliverable, and the development company is responsible from design through delivery. SES is a contract in which payment is made for engineers' working hours, to supplement staff. Both may be called "outsourcing," but responsibility lies in different places.

Where should we start with insourcing?

By choosing one target. Pick something at the core of the business that changes often. If you try to switch all of the company's development at once, hiring and training can't keep up and things stall.

Can we insource by hiring one engineer?

In practice, one person is not enough. A state where everything stops when that person leaves can't be called insourcing. You need a team of several people who can review each other's work, and the ability to keep hiring. It is more realistic to proceed together with an outside partner during the transition.

We want to insource in the future. Is it OK to outsource now?

Yes. But please tell the vendor about that plan at the start. Whether handover is assumed changes the design and the level of detail in the documentation. If you tell them later, the system may need to be rebuilt.

Once we insource, should we stop outsourcing entirely?

There is no need to. Leaving highly specialized, rarely changed areas to outside partners lets your in-house engineers focus on the core of the business. Splitting ownership is the realistic form.

Can we switch an existing outsourced system to in-house development?

Yes. But avoid moving everything at once. It is realistic to move the frequently changed parts first and leave the stable parts as they are for the time being. Before migrating, check the rights to the source code and how much of the design history remains; that makes it easier to put together an estimate.

Is it OK to consult a development company about insourcing?

Certainly. In fact, telling them up front that you eventually want to insource leads to better results for both sides. Whether handover is assumed changes technology choices and design, so if you tell them later, the system may need to be rebuilt.

How long does insourcing take?

When you narrow it down to one target, six months to a year counting from hiring is a rough guide: three months to hire, several months to understand the business and existing systems, and then development begins. Plans that underestimate this period tend to stall midway.

Does AI making development faster affect this decision?

It does. As implementation speed has increased, the speed of deciding what to build has become the speed of the business. That judgment can only be held in-house, so owning the core of your business yourself matters more than before. On the other hand, the patterns of AI-based development themselves are learned faster by bringing them in from outside.

Summary

Insourcing versus outsourcing system development is not a question of which is right. And with today's pace of change, it is not realistic to keep sustaining complete insourcing, development included, on your own.

The realistic form is to keep the parts that are core to the business and change often on your side, and to keep using outside capability for highly specialized, fast-changing areas. On that basis, you widen the range of decisions you can make in-house as the business moves forward.

There are five criteria: whether it is core to the business, how often it changes, whether you can hire and retain talent, by when you need it, and the total cost over three years.

Insourcing is a direction, not a destination. It is fine if you haven't drawn the line yet. Please reach out via our contact page. We will work with you, starting from sorting out what to bring in-house and what to move forward together.