The tech market has become paradoxical
In France, executive hiring in IT and telecommunications fell from 71,920 in 2023 to roughly 57,000 in 2025 — close to a 20% decline in two years. The Apec expects a modest recovery in 2026, but hiring would still remain well below the 2023 record.
Yet most developers I know are not short of work. Many are overloaded. Companies are hiring fewer people, but the software built over the previous years does not disappear with the roles that remain unopened.
Existing systems still need maintenance. Technical debt still needs reducing. Production still needs securing. Web platforms need to evolve, AI tools need integrating and business projects still need shipping. Apec even expects IT to remain the largest executive hiring function in 2026, driven by digital transformation, cybersecurity and artificial intelligence.
Lower hiring does not mean lower software demand. It mostly reflects greater caution around permanent headcount in an uncertain economy.
Numeum describes the same shift in the French digital market: more cautious hiring after the 2021–2023 shortages, while structural demand for technical skills remains significant over the medium term.
AI speeds up code, not everything that follows
AI makes it faster to explore a codebase, generate a first component, draft tests or automate repetitive work. It increases the amount of software a small team can produce.
But every generated line still needs to be understood, reviewed, tested, secured, integrated, observed and maintained. The 2025 DORA report on AI-assisted development captures the dynamic well: AI acts as an amplifier. It strengthens capable organisations, but also magnifies weak testing, fragile deployment processes, poor documentation and unclear ownership.
Producing code faster does not remove the work. It moves the bottleneck towards review, architecture, quality and production. Expectations rise as quickly as generation capacity.
The result is visible: smaller, more senior teams with a wider surface area. The question is no longer only “can we build this?” It is “who can actually own it without dropping everything else?”
When should you hire external developers?
Between making a permanent hire and quietly shelving a project, a third option is gaining ground: give a well-defined subject to an external engineering team. Not to add bodies to the org chart, but to take ownership of work the internal team lacks the time — or sometimes the specialist expertise — to carry.
1. An important project keeps slipping into the next quarter
The need is real and the business case is clear, but the core roadmap always wins. A migration, internal tool or automation can remain stuck for a year not because it lacks value, but because it is never the most urgent item that week.
2. You need a specific skill, but not a permanent role
AI agent architecture, cloud migration, rescuing a no-code product, data processing or observability may be critical for a few weeks and far less important afterwards. Hiring permanently for a temporary peak creates a mismatch between the work and the commitment.
3. The internal team understands the problem but cannot stop
Your developers may be the best people to fix the technical debt. They are also keeping production alive, handling customer requests and shipping the roadmap. Giving them a foundational project without removing anything else from their workload is usually another way of scheduling a delay.
4. The market window is shorter than the hiring cycle
Good hiring takes time: defining the role, sourcing, interviews, notice periods and onboarding. If an opportunity needs testing this quarter, an external team can begin while the company decides whether the capability should later move in-house.
5. A fragile system needs a rescue, not a theoretical rewrite
A vibecoded application, a no-code tool at its limits or a legacy codebase does not always need rebuilding from scratch. Someone first needs to understand what works, stabilise what breaks, document it and only then decide. That is focused work that an overloaded team often cannot absorb.
6. You need an outcome, not more people to manage
The right external model is not necessarily renting two developers and handing their management to your CTO. A small autonomous team can own a perimeter, organise the work, ship every week and hand back the code, tests and documentation.
What to outsource — and what to keep
External development works when the expected outcome and its interfaces with the rest of the product can be explained. It becomes risky when outsourcing is used to delegate a decision the company itself has not made.
| Good fit for an external team | Keep or lead closely in-house |
|---|---|
| A feature or product with an identifiable perimeter | Product vision and strategic trade-offs |
| Rescuing a stalled project or fragile codebase | Unwritten domain knowledge held by a few people |
| A migration, integration or automation | A continuous stream of unprioritised small requests |
| An audit followed by a concrete execution plan | Final accountability for security and data |
| A prototype designed to validate an opportunity | A capability that will be core every day for years |
The code can be produced outside the company. Understanding the problem, making product decisions and being able to take the system back cannot.
The conditions that make external development work
An external team does not remove the need for collaboration. It reduces workload only when its operating model protects the internal team’s time.
- Hand over an outcome, not a ticket list. The partner should understand the problem, propose a route and remain accountable for delivery.
- Name an available internal decision-maker. A few quick decisions beat a weekly committee of ten people.
- Provide access and context from day one. A partner without logs, test data or access to the right people cannot operate independently.
- Ship in small increments. Every week should produce something visible in production or staging, not just a status report.
- Plan the exit from the start. Code in your repositories, decisions documented, tests automated, access transferred and the internal team trained.
The real test: at the end of the engagement, your team should carry less load and have more control than it did at the start. If it depends more heavily on the supplier, the model has failed.
There are also bad moments to outsource: nobody internally can make decisions, the scope changes daily, the only selection criterion is the lowest day rate, or the company wants to delegate responsibility for a product it does not yet understand. In those situations, another team mostly creates another coordination layer.
This paradox is why we created Foundry Studio
We saw this shift coming: fewer permanent hires, more software to maintain and senior engineering attention becoming the scarcest resource.
That is why we created Foundry Studio.
We do not simply add developers to a team that is already saturated. We take ownership of a bounded subject: rescuing a stalled project, moving a product beyond its no-code limits, absorbing part of the backlog, automating a process or building a Web and AI product through to production.
We work in short sprints with the same senior team, a written scope and a planned exit from the start. The goal is not to make ourselves indispensable. It is to get the project moving, then hand it back cleanly.
Sources
- Apec — 2026 executive hiring forecast
- Apec — IT and information systems executive roles
- Numeum — The French digital employment market in 2025
- DORA — State of AI-assisted Software Development 2025
Is an important project stuck because the team has no capacity?
Tell us what is going on. We will say honestly whether it needs an external team and how to take it on without disrupting yours.
Talk it through for 30 min