An airline does not need every person who maintains every part of an aircraft to sit on its own payroll.
Specialist companies can maintain engines, avionics and other highly technical systems because concentrating expertise can make operational sense.
But the airline cannot outsource responsibility for whether the aircraft is safe to operate.
That distinction is useful when thinking about application maintenance.
A business can employ its own engineers, use an external maintenance company, or divide responsibilities between the two. Any of those models can work. What matters is whether the operating model gives the application enough technical knowledge, specialist coverage, response capacity and accountability to remain healthy.
The mistake is asking:
Is in-house maintenance better than outsourcing?
The more useful question is:
Which responsibilities need to stay close to the business, and which can be delivered more effectively through external capability?
An application that changes every week and contains highly specific business logic may benefit from permanent internal engineering knowledge. A stable business application that needs broad technical coverage but not five full-time specialists may be much better suited to outsourced maintenance. Many organizations ultimately need some combination of the two.
Microsoft's Well-Architected guidance reflects this idea. A workload may involve dedicated application teams, centralized specialists, partners and vendors, but those contributors need to operate as a coordinated whole around the success of the workload. Microsoft Azure Well-Architected Framework: Workloads
For Levelworks, the choice is therefore less about employment structure and more about whether the model can consistently protect the application's health. Responsibilities related to Supported, Secure, Observable, Current & Updated, Tested, Well Documented and Seamlessly Updatable App Health all need owners regardless of whose company name appears on their payslip.
In-house maintenance means the organization employs the people primarily responsible for maintaining the application.
Depending on the size of the system, that might mean a dedicated maintenance team or responsibilities distributed across an existing product-engineering organization.
A mature internal team might include application engineers alongside QA, DevOps/SRE, product and support capability. Smaller organizations may have only one or two engineers covering several of those responsibilities, with specialists shared across other teams.
The defining characteristic is that the people responsible for most maintenance are part of the organization that owns the application.
This usually gives the business direct control over priorities and preserves technical and business knowledge internally.
The trade-off is that the organization also has to recruit, retain and provide enough specialist coverage to meet the application's needs.
[Internal Link: “Building an Effective App Maintenance Team: Roles, Skills and Structure”]
Outsourced maintenance transfers agreed maintenance responsibilities to an external provider.
The provider might supply:
The arrangement can range from a small retained team handling defects and routine updates to a dedicated external product-maintenance team responsible for most day-to-day technical operation.
Outsourcing does not mean the business stops owning the application.
The UK's National Cyber Security Centre makes this distinction particularly clearly for third-party technology services: even when a function is outsourced, the owning organization remains accountable for ensuring relevant security requirements are met. NCSC: Cyber Assessment Framework — Supply Chain
That principle extends beyond security.
The external provider can perform maintenance.
The business still owns the consequences of whether the application is properly maintained.
The strongest argument for in-house maintenance is often not technical expertise.
It is context.
An internal engineer may already know why the pricing engine works a particular way, which customer workflow is commercially critical, which legacy integration cannot yet be removed and why a seemingly strange database rule exists.
That accumulated context reduces communication.
When product says:
“The enterprise approval workflow needs changing.”
the engineer may already understand the customers, architecture and business constraints involved.
An outsourced team starts with less of that knowledge and has to acquire it.
For applications where maintenance regularly overlaps with product development, strategy or complex domain logic, that difference can matter considerably.
DORA's research on loosely coupled teams supports the broader principle that teams work more effectively when they can make, test and release changes without excessive coordination and handoffs to other groups.
The more frequently an external maintenance team has to wait for internal clarification before acting, the less advantage outsourcing provides.
The advantage moves in the other direction when the application requires skills too intermittently to justify dedicated internal positions.
Imagine an application that occasionally needs:
Hiring six dedicated specialists would be disproportionate if the application requires only part of each person's capacity.
A maintenance provider can spread those specialist skills across several clients and bring them into an engagement when required.
This can be particularly valuable for small and mid-sized businesses where one or two internal developers are expected to understand everything from React to database recovery to AWS networking.
The important distinction is between access to a skill and full-time need for that skill.
If the application needs a database specialist five days each year, outsourcing or shared expertise is usually easier to justify than a full-time hire.
If database performance is a daily competitive concern, keeping deeper expertise inside the organization may make far more sense.
Cost comparisons between in-house and outsourced maintenance often begin badly.
Someone compares:
internal developer salary
with:
vendor hourly rate.
The higher vendor rate then makes outsourcing appear expensive.
Or somebody compares:
vendor monthly retainer
with:
one engineer's salary
and concludes outsourcing is cheaper.
Neither comparison captures the real economics.
An internal maintenance capability can involve:
An outsourced arrangement may involve:
The relevant comparison is the cost of obtaining the coverage the application actually needs.
Consider an application requiring approximately one application engineer's workload plus occasional DevOps, QA and database expertise.
The in-house model may require hiring more total capacity than the application consistently consumes.
An outsourced provider may be able to deliver those skills fractionally.
Reverse the situation and the economics change. If several engineers work on the application every day, permanent internal capability can become more efficient than continuously buying equivalent external capacity.
There is no universal cost winner.
Utilization matters.
Some products do not have a clear border between maintenance and development.
A SaaS platform might release every week while continuously:
Calling half of that work “maintenance” and transferring it to another team can create an artificial organizational boundary.
If the same architecture, customer behavior and product decisions affect both new development and maintenance work every day, one cross-functional internal product team can be more effective.
DORA's research indicates that cross-functional teams with sufficient autonomy can reduce the communication and coordination overhead created by repeated handoffs. DORA: Loosely Coupled Teams
That does not prohibit external specialists.
It simply means separating everyday maintenance ownership from everyday product ownership may add more friction than value.
Many business applications have a different profile.
They remain important but are no longer under intense product development.
The business still needs:
The workload may average one engineer's capacity but occasionally require several people during an incident or upgrade.
This is where outsourcing can work well.
A dedicated maintenance provider can maintain continuity without requiring the company to build an internal team large enough to handle peak demand.
Google's SRE guidance offers a useful parallel. Google describes both full-time and part-time SRE engagement models, with the appropriate arrangement depending on service maturity, required support and available specialist capacity rather than assuming every service needs a permanent dedicated SRE team. Google SRE Workbook: SRE Engagement Model
The same reasoning is useful for application maintenance: specialist capacity should follow the application's needs rather than an assumption that every capability needs a permanent full-time role.
Production incidents test both models.
An internal team has one major advantage: it often knows the application deeply.
The engineers may recognize patterns immediately and understand which business processes are affected.
An external provider can have a different advantage: structured coverage.
A mature maintenance company may already operate:
A small internal team may have deeper context but poor resilience if the one engineer who understands the application is unavailable.
The better model therefore depends on the combination of knowledge depth and coverage depth.
For a business-critical application, ask:
Who actually responds at 2 a.m.?
Who can diagnose the application?
Who can access production?
Who can make the decision to roll back?
What happens if the primary engineer is unavailable?
An org chart does not answer those questions.
The operating model must.
One legitimate concern with outsourced maintenance is that application knowledge can accumulate inside the supplier.
After several years, the external team may understand:
The client technically owns the application but cannot operate it without the provider.
That is vendor dependency rather than healthy outsourcing.
Avoid it by ensuring the organization retains:
The provider should maintain the application, not become the only place from which the application can be understood.
This is where Well Documented and Version Controlled App Health become particularly important.
Strong documentation lowers the cost of moving between in-house and outsourced models because knowledge is less tightly bound to individuals.
Internal teams are not automatically better at knowledge retention.
Consider the application where everyone says:
“Ask Priya. She built that part.”
Priya is effectively the documentation system.
If she leaves, the knowledge problem is almost identical to losing a vendor.
The more important question is whether knowledge is institutionalized through:
Internal employment reduces one type of organizational boundary.
It does not eliminate key-person risk.
Giving an external maintenance provider access to production systems, repositories and customer data creates an additional trust relationship.
That does not make outsourcing inherently unsafe.
It means supplier security becomes part of the operating model.
NIST's Secure Software Development Framework explicitly notes that software purchasers can use the framework when communicating secure-development expectations to suppliers.
The NCSC similarly recommends evaluating supplier security before contracting, embedding necessary controls into agreements, monitoring whether those controls remain effective throughout the relationship and recovering organizational assets and access when the contract ends. NCSC: Embed Cyber Security Controls Throughout the Contract
For outsourced maintenance, practical governance should therefore cover areas such as production access, source-code access, credential management, security incidents and offboarding.
A mature provider should be able to work inside those controls.
If the application handles unusually sensitive systems or data, the governance requirement may make a larger internal security role appropriate even when engineering maintenance remains outsourced.
Suppose a business has one internal developer maintaining an application.
That arrangement is technically in-house.
It is also extremely fragile.
Vacation, illness or resignation can temporarily remove the organization's entire maintenance capability.
A provider with multiple engineers may offer better continuity because knowledge and coverage can be spread across a team.
But the opposite can happen too.
Some outsourcing arrangements sell the appearance of a team while effectively assigning one engineer who becomes another single point of failure.
When evaluating outsourced capability, understand:
The relevant comparison is not “employees versus vendor.”
It is resilient team versus fragile team.
When maintenance is internal, reprioritization can be immediate.
A product leader can move engineering attention from one issue to another without negotiating contractual scope.
This is valuable in fast-moving products.
Outsourcing introduces a commercial boundary.
Depending on the engagement, changing priorities may involve:
That structure is sometimes perceived as bureaucracy.
It can also force useful discipline.
A provider asking whether an unplanned feature should displace dependency upgrades exposes a trade-off that an internal team might otherwise absorb silently.
Good outsourced relationships therefore need enough commercial flexibility to handle maintenance uncertainty without turning every backlog adjustment into contract negotiation.
[Internal Link: “How to Scope an Application Maintenance Engagement”]
The weakest outsourcing model is:
Business
↓
Tickets
↓
Vendor
↓
Code comes back
The provider has little exposure to users, product priorities or business context. Internal teams have little visibility into technical health.
Both sides optimize locally.
Microsoft's Operational Excellence guidance specifically warns against workload teams, centralized teams, partners and vendors behaving as isolated units. It recommends treating the contributors as a collective force around shared business outcomes. Microsoft: Operational Excellence Maturity Model
A better model includes:
Outsourcing should change where people work, not whether they communicate.
The decision does not have to be binary.
A strong hybrid structure might keep internally:
An external maintenance team could provide:
Another company might keep core application engineers internally but outsource:
Google's SRE engagement model provides a useful analogy for shared responsibility. In some models, SRE teams own platform-level operational capabilities while development teams continue owning functional application issues. Google SRE: Evolving the SRE Engagement Model
The exact split differs, but the lesson is important:
responsibility can be divided according to capability rather than company boundaries.
For many businesses, hybrid maintenance combines internal context with external depth more effectively than either extreme.
A useful decision matrix looks like this:
Decision factor
In-house tends to fit better when…
Outsourced tends to fit better when…
Product change rate
Maintenance and feature development overlap continuously
Application is relatively stable
Domain knowledge
Deep business context is needed every day
Domain can be transferred and documented
Specialist needs
Specialists are needed frequently
Specialist demand is intermittent
Workload
Maintenance capacity is consistently high
Demand varies significantly
24/7 coverage
Organization already staffs reliable rotations
Additional coverage would require significant hiring
Technical ownership
Technology is strategically differentiating
Application is important but not a core engineering differentiator
Scaling capacity
Hiring can keep pace with demand
Additional expertise is needed quickly
Governance
Sensitive requirements favor direct internal control
Supplier controls can satisfy requirements
Cost structure
Internal staff will be highly utilized
Fractional skills reduce unused capacity
Knowledge
Organization wants expertise deeply embedded
Strong documentation and transfer practices exist
No single row should decide the answer.
Look for the overall pattern.
An internal model becomes more attractive when the application is central to how the business differentiates and changes frequently.
It is particularly compelling where engineers need continuous access to product decisions and complex domain knowledge.
For example, consider a SaaS company's primary platform.
Its engineers may spend Monday fixing a billing defect, Tuesday redesigning part of the architecture, Wednesday supporting a new enterprise customer and Thursday developing a new capability.
Trying to determine which hours are “maintenance” and transfer them to another organization may create more coordination than value.
In that case, maintenance capability is simply part of the product-engineering organization.
Outsourcing becomes more attractive when the application needs dependable technical stewardship but does not justify maintaining every required discipline internally.
Consider a manufacturer with a business-critical customer portal.
The portal is important enough that outages and security issues matter, but the company is not fundamentally a software engineering business. It may need backend expertise regularly while requiring database, frontend, security and cloud specialists only occasionally.
Building and retaining that entire technical organization may not be sensible.
A maintenance partner can provide a broader capability around the application while the manufacturer retains product ownership and business knowledge internally.
This is one of the strongest economic arguments for outsourcing: shared specialist capability without having to employ every specialist full time.
The problem is rarely that the engineers are incapable.
More often, the structure has stopped matching the workload.
Warning signs include situations where one or two people hold most application knowledge, maintenance is continually displaced by feature work, important upgrades are repeatedly postponed, after-hours support depends on goodwill, or the team cannot access specialist skills when unusual problems occur.
Those are capability gaps.
Adding more responsibility to the existing team does not necessarily solve them.
Outsourcing has its own recognizable problems.
Be concerned if the provider needs extensive re-explanation of the application for every issue, personnel change frequently, documentation deteriorates, response looks fast while recurring defects remain unresolved, or the organization no longer controls critical repositories and accounts.
Another warning sign is when every technical conversation begins with contractual interpretation.
The provider should operate within a clear scope, but successful maintenance still requires enough flexibility and shared ownership to solve real production problems.
One of the best ways to design the model is to identify responsibilities the business should always retain.
Even with extensive outsourcing, organizations usually benefit from retaining clear internal ownership of:
Business priorities. Someone internally must decide which outcomes matter.
Application accountability. Somebody must know whether the provider is delivering what the system needs.
Risk acceptance. A vendor can explain that an outdated framework creates risk; the business must decide whether to fund the upgrade.
Supplier governance. Access, security and contractual performance remain organizational responsibilities.
You can outsource execution.
You cannot outsource the need to make decisions.
The second question works in the opposite direction.
Which skills are important but only occasionally required?
If an internal organization employs a specialist primarily because “we might need them during an incident,” there may be a more efficient way to obtain that coverage.
This analysis frequently identifies opportunities for:
The goal is not maximum outsourcing.
It is avoiding unnecessary fixed capacity without creating dangerous capability gaps.
A practical decision can be made by examining frequency, criticality and context.
How continuously is the skill or responsibility required?
High-frequency responsibilities favor dedicated capability.
Intermittent ones are easier to share or outsource.
What happens if the required capability is unavailable?
A low-frequency but extremely critical responsibility still needs dependable coverage.
How much application-specific or business-specific knowledge does the work require?
Responsibilities that rely heavily on proprietary knowledge often benefit from closer integration with internal teams, even if some execution is external.
This produces more useful decisions than comparing hourly rates.
One subtle risk in both models is measuring the team instead of measuring the application.
An internal team can be busy while the app becomes harder to maintain.
A vendor can meet every response target while technical debt and dependency risk continue accumulating.
The business therefore needs an independent view of application condition.
For Levelworks, that is where App Health provides useful continuity across operating models.
Whether maintenance is performed internally or externally, the application should remain sufficiently Observable, Secure, Tested, Current & Updated, Supported, Well Documented and Seamlessly Updatable for its business needs.
Those qualities provide a better test of the maintenance model than organizational preference alone.
[Internal Link: “How to Choose an Application Maintenance Company”]
“In-house or outsourced?” sounds like a sourcing decision.
In practice, it is a capability-design decision.
Put the application's needs on the table first: product context, engineering depth, production coverage, security, testing, specialist skills, continuity and anticipated change.
Then decide where those capabilities should live.
Some applications justify a permanent internal engineering organization because maintenance is inseparable from continuous product development. Others benefit from an external team that can provide wider expertise and more flexible capacity than the business could reasonably build itself. A large number sit somewhere between those positions.
The strongest arrangement may therefore be less dramatic than choosing a side.
Keep the knowledge and decisions that genuinely belong inside the business. Bring in outside capability where specialization, coverage or flexibility makes it stronger. Define the boundary clearly enough that both groups know what they own.
The result should feel less like handing maintenance away and more like designing the right team around the application.
