Is it better to develop software in-house or hire an external team?
Build in-house when the development is at the core of your value proposition and you can take it on in money and time without slowing your operation. Hire an external team to experiment, for well-bounded developments, when it has more experience than your team in what you want to build or when you cannot stop your day-to-day work. In both cases, the biggest risk is usually starting without a good definition.
We are an external team, so we start with the cases where we recommend building in-house.
When to build in-house
- When it is at the core of your value proposition. If you need to master the solution end to end and it has many ramifications across your business, an external team increases the risk that something will not fit.
- When you can take it on. If moving people and time to this project does not stop you from generating revenue.
- When you cannot find a provider that documents well. Without documentation, whoever picks up the project depends on the team that built it.
When to hire an external team
- To experiment or for well-bounded developments.
- When you cannot stop your operation. A third party analyses and proposes improvements while your team carries on with its day-to-day work.
- When it has more experience than your team in what you want to build, or can do it faster and better.
- When it offers a warranty on what it delivers. In how to choose an AI development company we explain what to ask for.
The mixed option
A common situation: you have a problem, but you cannot stop your operation. An external team builds a second version and then trains your team to use and maintain it. For this to work, the external team has to leave the context and decisions documented, so your team can carry on without depending on it.
Costs and risks you do not see at the start
In our experience, the biggest cost usually comes from a poor definition. Before writing code you need a discovery phase that makes clear what is wanted and why. If development starts with whatever each stakeholder asks for, without that phase, the cost shows up later: poor scoping, delays, cost overruns, rework and bugs.
Other risks, with either option:
- Not documenting, which creates dependency on the team that built it.
- Not building testing into the development process.
- Not measuring the before and after, which makes it impossible to show the impact.
In-house or external, in a table
| Situation | Best option |
|---|---|
| It is the core of your value proposition and you can take it on | In-house |
| You cannot find a provider that documents well | In-house |
| You want to experiment or it is a well-bounded development | External |
| You cannot stop your operation | External, or mixed with handover |
| The external team has more experience in what you want to build | External |
| You need a second version and want to own it | Mixed: the external team builds it and trains yours |
An example
At TIFIN, a US fintech with several wealth management products, Criterian's team was integrated into the client's team during a growth phase in which the platform had to scale with high availability. We carried out a progressive migration from a monolith to microservices: API latency fell from 320 ms to 112 ms and infrastructure cost was reduced by 40%. It is an example of an external team integrated into the client's team to bring architecture experience.
Unsure whether to build in-house or outside?
Tell us what you want to build and we will tell you which option we think fits best, even if it is building with your own team.
Let's talk