Why internal development teams fail with operational core systems
In-house development vs agency: a structural guide for B2B service providers in the DACH region with 10 to 50 million turnover
Table of Contents
The question of in-house development vs. agency seems clear at first glance, until you are in the middle of it. DACH B2B service providers with a turnover of 10 to 50 million, logistics companies and operational service companies, eventually reach the point where their daily operations no longer run on SaaS tools and Excel spreadsheets. Something has to be built. And the first impulse is almost always: we hire a developer.
That is an understandable impulse. The budget for one or two developers is there. You want control. You want someone who understands the business. And experience with agencies building the wrong thing is common enough that an internal solution seems safer.
However, for most companies at this revenue level, internal development teams face specific structural limitations when building core operational systems. Not because of poor personnel decisions, not because of a lack of engineering quality. Because the combination of skills that a core operational system really needs is rarely what an internal development team of this size can structurally provide.
This article clearly describes these limits so that the decision to set up your own operating infrastructure is made on the right basis.
The sales level at which standard advice no longer applies
Most advice on in-house development vs agency is written for two target groups: early-stage startups validating an MVP and large corporations managing complex engineering organizations. The mid-sized company with 10 to 50 million in revenue sits between these two worlds, and the standard recommendations don't fit.
At this stage, the company is no longer a startup. The operation is real, complex and runs under real commercial pressure. Real orders are processed, real inventories are managed, real customers are served, with service level expectations that cannot be missed. Operational revenues are high.
But the company is not a corporation either. It can't support a ten-person engineering team. A full-time CTO, a business architect, two senior developers, a QA lead and a DevOps engineer, the budget is enough for one or two developers, not for a department.
It is precisely this bottleneck, real operational complexity with limited engineering capacity, that makes the question of in-house development vs. agency more difficult than it seems, and a mistake in it expensive.
What operational core systems really need and why they differ from product development
Before evaluating in-house vs agency, it's worth clarifying what kind of problem is actually being solved here. There is a significant difference between building a product and building a core operational system, and the skills profile required in each case is different.
Product development
A product is software that the company sells or that defines how customers experience the service. It needs to be well developed, scalable and often enhanced based on user feedback. In-house development can be the right choice here if it is sufficiently funded, because the team builds up in-depth product knowledge over time and can iterate continuously.
Development of an operational core system
An operational core system is software that controls internal company processes. Quotation creation, scheduling, stock allocation, exception processing, customer intake. It must reflect the operational reality of the specific company, its own pricing logic, its own exception types, its own data structure, its own integration conditions.
This difference is critical because operational core systems require a different input at the beginning: someone who understands where value is lost in the as-is process before the first line of code is written. This is not a developer skill, but a business architecture skill. And at the 10 to 50 million revenue level, internal development teams almost never have it built in.
The most common and costly mistake at this revenue level is to hire an internal development team to build a core operational system to a specification written by operations staff and reviewed by a developer. The result is software that is technically correct and operationally misaligned. It automates the documented process, not the optimal one.
Five structural challenges of internal development teams at the 10 to 50 million sales level
The following challenges are not about the quality of the developers hired. They are structural, a consequence of what a two- to three-person internal team is and is not at this revenue level.
The structural challenge | Why better hiring doesn't solve this |
|---|---|
No competition for senior developers possible | Tech companies pay two to three times as much. The budget is missing. |
Maintenance supersedes new development | operational core system generate support load. New projects come to a standstill. |
Development according to specification, not according to result | Without a business architecture, the system drifts away from the P&L. |
Domain knowledge takes 6 to 12 months | Operational precision requires industry knowledge, not just code. |
A departure puts the project on hold | There is no redundancy in a small team. Knowledge is lost. |
Challenge 1: No competition for senior developers
Building a core operational system requires senior engineering. Junior developers build what they are told, accumulate technical debt faster than they reduce it, and require supervision that is typically not available at this level of the organization. Senior developers at the level required for complex core operational systems earn EUR 90,000 to 140,000 in the DACH market, and tech companies and funded startups are competing for the same profiles with equity, flexibility and better infrastructure. A logistics company with 30 million turnover is not a preferred employer in this market.
The practical consequence is that internal development teams at this level often end up with developers who are either overqualified and gone after 18 months, or junior enough to be affordable but not enough for the complexity of the task. Neither outcome delivers what the business needs.
Challenge 2: Maintenance supersedes new development
As soon as an operational core system, or even just a part of it, is in operation, it generates a support load. Errors occur. Incidents occur. Users request changes. Data migration takes place. Interfaces break. For a one- to two-person internal team, this ongoing maintenance responsibility competes directly with new development capacity. Within twelve months of go-live, we observe in most internal teams of this size that the majority of capacity, typically 60 to 70 percent, is absorbed by maintenance and support of existing systems, leaving 30 percent or less for new builds.
This is not a planning error. It's what operational software does. The question is whether the internal team is big enough to absorb this without bringing the timetable to a standstill. At this level of turnover, it rarely is.
Challenge 3: Developers build to specification, not to result
Without a business architect on the team, the development brief is typically written by the person closest to the problem: an operations manager, a COO or the founder himself. This briefing describes the current process, not the optimal one. It documents how things are done today, including the inefficiencies, workarounds and manual steps that have accumulated over the years.
A developer who works according to this specification builds what the specification describes. The result is a system that automates an existing faulty process instead of replacing it with a better one. The automation is technically successful. The operational improvement is marginal. The opportunity that justified the investment, faster throughput, better margins, less key person dependency, is not realized.
Challenge 4: Domain knowledge needs time that the timetable does not have
Operational precision in a logistics company, a freight forwarder or a complex B2B service provider requires industry knowledge, not just code knowledge. How price exceptions work. What triggers non-standard scheduling. How customer-specific agreements influence the standard process. How margin is actually calculated compared to what's on paper.
An internal developer builds up this knowledge over time, typically six to twelve months, before they can build systems that reliably reflect it. In this time frame, what is built is based on what has been told, not what has been observed. The difference often shows up in the first six months of live operation, when edge cases emerge that the specification never captured because the developer didn't know to ask about them yet.
Challenge 5: A departure puts the project on hold
With a two- to three-person internal development team, a single developer is not a capacity reduction, but a project reset. The developer who built the system took the architectural decisions, the undocumented logic and the integration knowledge with them. What remains is a codebase that the remaining team, or their successor, must reverse engineer before further development is possible.
This is not a documentation error, even if better documentation helps. It is a structural consequence of small team size. There is no redundancy. There is no second person who has made the same decisions and holds the same knowledge. The key person risk is absolute, not marginal.
In-house development vs agency: what the comparison really shows
When companies come to the conclusion that internal development teams have limitations, the next question is usually the agency. But the common comparison of in-house development vs agency overlooks the most important variable: what kind of agency, and what brief it gets.
A generic software development agency solves the hiring and headcount problem. It does not solve the business architecture problem. Most agencies take a specification and build to it. The specification is still written by operational staff. The domain gap remains. The system still risks being technically correct and operationally misaligned. The agency delivers faster and with more engineering discipline, but to the same wrong brief.
The comparison that really counts at this level is not internal development team versus generic agency. It's between any model that starts with a developer and any model that starts with a business architect working alongside a developer.
Factor | Internal development team | Operational optimization partner |
|---|---|---|
First results | 4 to 9 months (hiring + onboarding) | 4 to 8 weeks (audit + scope) |
Domain knowledge | Builds up slowly, starts from zero | Introduced from day one |
Business architecture | Rarely present in the team | Firmly coupled with engineering |
Cost structure | Fixed, independent of output | Project-based, linked to delivery |
Key person risk | High, an exit blocks the timetable | Distributed, team continuity built in |
AI integration | Possible, depending on team skills | Planned from the process layer onwards |
Right for | Core product development on a large scale | Core operating system with sales of 10 to 50 million |
When an internal development team is the right choice
Internal development teams really are the right choice in certain situations. If your software is your core product, what customers are paying for, an internal development team builds the deep product knowledge and iteration speed that cannot be replicated externally at this scale. With more than 50 million in revenue and a viably structured engineering team with senior leadership, the fixed costs of an internal team become competitive with external alternatives. If the development roadmap is continuous and multi-year, the institutional knowledge that builds up in an internal team is a real asset.
For operational B2B service providers with a turnover of 10 to 50 million, whose core product is the service and not the software, these conditions rarely all apply at the same time.
The third option that most in-house vs. agency comparisons don't mention
The in-house development vs agency comparison presents two options. There is a third. For core operational systems at this revenue level, it is typically the most suitable: an operational optimization partner that couples business architecture and engineering from the start.
The difference is not a marketing vocabulary. It's a structural difference in how the engagement begins. A standard agency starts with a requirements conversation that produces a specification, then builds from there. An operational optimization partner starts with a value chain audit that captures where time and margin are actually being lost, produces a process design before any line of code, and only then goes into build, with an engineer working from that design, along with the one who created it.
Case study: EUR 25 million logistics company, third attempt
A logistics company with a turnover of EUR 25 million had tried twice to build its own quotation system, once with a freelance developer and once with a medium-sized agency. Both times the system was delivered and within six months had been partially abandoned in favor of Excel workarounds. The bid logic was more complex than either project had captured, and neither engagement had involved anyone with sufficient operational familiarity to recognize the gap before it was built into the system.The third engagement began with a two-week process audit. The audit identified four price exception types that accounted for 40 percent of the quote volume and were not documented anywhere. The system was designed around these exceptions, not as edge cases, but as core process operations. It went live on schedule, was fully adopted within eight weeks and completely eliminated the Excel workarounds.
The difference was not better engineering in the third engagement. The engineering quality was comparable to the second. The difference was that someone with operational expertise had grasped the process before the engineer started building and discovered what two previous specifications had overlooked.
How appleute works at the 10 to 50 million sales level
appleute is an operational optimization partner for B2B service providers in the DACH region whose business processes have outgrown their existing infrastructure. We are not a general software development agency. We work specifically with companies where the gap between operational complexity and current systems costs measurable margin and throughput.
The dual-lead model
Each engagement pairs a Senior Business Architect with a Lead Engineer. The Business Architect is responsible for the operational design: capturing value leakage, identifying the process with the greatest leverage, redesigning the process before writing code. The lead engineer is responsible for the technical build: translating that design into a system that can be integrated into the existing infrastructure and maintained and evolved after delivery.
This is the structural difference to both internal development teams and standard agencies. Engineering does not work to a specification written by an operations manager. It works to an operational design created by someone whose primary job is to understand how B2B service businesses create and destroy value.
What we do not do
We do not accept a specification and build according to it. Before a construction order is placed, we use a value chain audit to check whether the specification describes the right process. If a standard solution fits, we say so before a project starts. We compete on operational effectiveness, not on hourly rates.
The entry point
Every engagement begins with a Strategic Audit: a fixed-price, stand-alone, in-depth analysis of the operational process where friction and cost are most concentrated. The audit produces a process design and a roadmap to cost neutrality before a construction contract is awarded. Organizations that have gone through a failed internal development or agency engagement typically find the audit most valuable: it shows precisely what the previous engagement overlooked, and why.
What to do now
If you're debating whether to hire a developer, expand your internal team or work with an external partner to build a core operational system, the most useful first step is not a software decision. It's a process decision.
Start by answering three questions. Which single operational process would have the greatest impact on your margins if it ran reliably and without manual intervention? Where in this process does the most time and coordination effort go? And is the problem that a system is missing or that the existing systems do not reflect how the work actually flows?
These three answers tell you more about the right building approach than any comparison of hourly wages or team structures. In most cases, they also show that the problem is smaller and more addressable than it initially appeared: a process, well designed and properly built, typically produces more impact in six months than a full in-house development team in the same period.
In a short discovery conversation, we capture the process where operational friction is concentrated, assess whether the constraint is a design or a build issue, and give you a clear assessment of whether an operational optimization assignment makes sense at your current stage. No commitment required. A concrete assessment of your situation.
If you want this external perspective: We are ready.
Arrange a free, no-obligation consultation with our team.
EN 
DE 
FR 
ES