Build an in-house team or commission the work?
An in-house team is almost always the stronger long-term answer. This page describes what building one actually takes and when a commissioned build bridges the gap until then.
In short
If you build software continuously, you should have a team. Building one takes time though, from the search through onboarding to the point where the team delivers without direction. A commissioned build does not replace a team; it bridges the time until there is one and leaves a system the later team can carry on.
There is no cost comparison on this page. Salaries, overheads and time-to-hire vary so much by location, role and market that any example figure would say more about our assumption than about your case. What can be compared is the effort and the timeline.
Where the routes differ
| Criterion | In-house team | FW Delta |
|---|---|---|
| Time to first delivery | search, notice periods and onboarding come first | starts once the proposal is signed |
| Cost structure | ongoing, regardless of utilisation | tied to the project |
| Knowledge in-house | accumulates permanently | arrives with the handover, not through daily work |
| Availability | any time, within capacity | within the project |
| Breadth of skills | bounded by headcount | broader for the duration of the project |
| If someone leaves | knowledge goes with them and the search restarts | documentation and code stay |
| Long term | the more durable answer | a bridge, not a replacement |
An in-house team pays off when
- development happens continuously and across breadth
- the product itself is the software
- utilisation is reliably high
- the organisation can carry onboarding and management
Commissioning fits when
- a system is needed now and the search is still running
- the task is bounded and little work remains afterwards
- a skill is needed that does not justify a permanent role
- the result is meant to be taken over by an in-house team later
FAQ
Why is there no salary calculation here?
Because it would inevitably produce our result. Calculations that set high six-figure annual costs against a five-figure project assume a team that permanently delivers more than the project, then compare both totals anyway.
Are you advising against an in-house team?
No. Anyone building software continuously needs one. We are the route towards it or the route alongside it, not the replacement.
Can our team take the system over afterwards?
That is the normal case. Code, configuration and an operating guide are handed over, and the conventions are chosen so somebody else can carry on.
Talk about the timeline
If the role is already posted, the only question is what happens until it is filled.
01
A 30-minute call
We walk through your starting point and say honestly whether a move pays off for you.
02
A fixed-price proposal
Within five working days, with scope, assumptions and what is explicitly not included.
03
Build and handover
Repository access from day one, documentation at the end, no obligation to keep us.