Comparison · Engagement model
Build an in-house team or commission the work? Long term, the team. Until it exists, a commissioned build bridges the gap.
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.
How we compare
-
We sell the alternative
This is not a neutral review. That is why price date, assumptions and the maths sit openly next to it.
-
Both outcomes are shown
Including the scenarios where the vendor wins. A comparison that always ends in our favour would be advertising.
-
Only evidenced numbers
List prices with a source. Where a vendor does not publish, no invented total appears.
-
Your numbers decide
The calculator takes your users, your volume and your term instead of our assumption.
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.
Why there is no calculation here: 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.
In detail
Where the routes differ
| Point | 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 |
The decision
What speaks for which route.
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
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
If you want to switch
What happens next
-
30 minutes
Conversation
We walk through your starting point and say honestly whether a move pays off for you.
-
within five working days
Fixed-price proposal
With scope, assumptions and what is explicitly not included.
-
depending on scope
Build and handover
Code access from day one, manual at the end, no obligation to keep us.
Common questions
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.
Read on
Where to go next.
Next step
Talk about the timeline
If the role is already posted, the only question is what happens until it is filled.
Reply within 24 hours. No obligation, confidential.