How to decide where custom development can close capability gaps and reduce friction across the systems already in place, without defaulting to wholesale replacement.
Technology leaders often inherit applications already embedded in how the business operates.
You may not have chosen them, and you are responsible for making that environment work.
Those applications reflect years of investment and technical decisions, but they do not all carry the same value forward. Some may still support work the business depends on. Others may no longer justify the same level of attention or spend.
That makes the immediate task one of judgment: understanding which parts of the inherited portfolio are still creating value, where friction is coming from, and where further investment may make sense.
Start With Current Value, Not Sunk Cost
When you decide whether to invest more, what the system still contributes to the business should count for more than what has already been spent.
An application can be painful to support and still do work the business depends on. That leaves you weighing the burden of supporting it alongside the value of that work.
The support burden matters, but it should not decide the question on its own. Past spending should not either.
If the application’s current contribution no longer supports further investment, past spending alone is not a reason to keep investing. Even if you decide the application still warrants investment, that decision alone does not identify what is producing the friction or how far the problem reaches.
Trace the Source and Reach of the Friction
Deciding that an application deserves further investment does not necessarily tell you where corrective work belongs.
Take a connected service that produces incorrect output. The application consuming that output may be where teams encounter the problem, while the service is producing it.
We saw this in a finance department, where recurring manual work turned out to stem from a downstream service producing incorrect output. Once the team could see how that service was behaving, they identified and corrected the underlying issue without rebuilding the otherwise functional application.
That downstream service may also support other systems. If it does, changing it can affect systems that were never part of the original problem.
So knowing what else relies on the service helps you judge how much change the problem justifies.
Four questions before choosing a path
- What value does this system create today?
- What is producing the risk or friction, and how far does it reach?
- What else depends on the part you are considering changing?
- What scope of change does the problem actually justify?
Scope the Change to the Problem
We saw this in an engagement with a commercial vehicle manufacturer. The application was still mission-critical to the business. The problem was supporting it.
Documentation was limited, and too much system knowledge sat with a small number of people. The challenge was making that knowledge usable beyond the people who already knew the system well.
Axian built a RAG-backed support capability around the application so the client team could query that knowledge when the application failed or behaved unexpectedly. This gave the team a more usable way to diagnose issues without relying on a single expert. That way, they could improve how they supported the application without rebuilding the application itself.
Your situation may be different, and the work may need to go much further. If the problem runs through more of the application or its dependencies, then a larger change may make sense.
The difference is that you got there by following the problem, not by deciding in advance how much of the system should change.
Custom Has to Fit the Problem and Be Practical to Support
Knowing how much needs to change still leaves one decision open: whether custom is the right way to make that change.
If the commercial software already in place meets the need without much modification, there may be little reason to add custom.
But if making that software fit requires substantial modification, it is worth weighing the added upgrade and maintenance burden against a more targeted custom approach. And when even substantial modification would still leave an important gap, custom software development may be worth considering alongside the existing system.
Custom software also has to fit the organization that will own it after launch. The design should account for who will support it, how it will evolve, and how much complexity the team can realistically carry.
If the solution is hard to maintain or adapt as business changes, fixing the immediate gap may simply create a different source of friction.
That responsibility does not have to sit with your internal team alone. Axian can work alongside your team to assess the options, shape the architecture, and stay involved through implementation and ongoing support.
You Don’t Need a Finished Solution to Bring in Engineering Help
You may know an inherited application is creating friction or leaving an important capability gap without yet knowing what the architecture or solution should look like.
That is enough to start a useful engineering conversation.
Axian’s senior Architects, Product Leads and Engineering Leads can work alongside your team (both the business and your technical teams) to fully understand the problem and associated opportunity, evaluate the options, work through unresolved technical questions, and stay involved as the solution moves into execution.
A useful engagement can start with the problem, the constraints, and the business outcome you are trying to achieve.
Working through inherited applications, capability gaps, or modernization decisions? Talk with Axian about where targeted engineering support can help.