When your custom app gets hard to change: is architecture the cause, and what then?

A price changes, and someone has to update it in five places: the quoting screen, the invoice template, two reports and a spreadsheet that finance keeps on the side. Or a partner asks for a connection to your system, and nobody can say how the application could offer one.

Many companies own an application like this that nobody outside the company has heard of. It was built a few years ago, in-house or by a small supplier, because no product handled the way they work. It still runs a core process every day, and it holds years of rules about how the business operates. Those rules are valuable, whatever happens to the code.

Slow changes and awkward connections are reasons to look closer. They do not yet say what is wrong, and they do not say that the application should be replaced. The cause may be the architecture, the structure underneath the screens. It may equally be missing documentation, a dependence on one person, or the way your systems are connected. Each has a different, proportionate fix.

The pattern is clearest in a company that has grown since the application was built. The application still supports the internal process well, and a standard product that fits does not exist, but the business now asks more of it than the original design allowed for.

This guide explains what to check before deciding, what architecture means in terms of what the business can change, connect, control and recover, which options to compare, where AI helps and where it does not, and how a staged rebuild is planned when one is justified.

What you notice, and what else could explain it

Each observation below is a reason to investigate. None of them settles the cause on its own, and there is no number of observations at which an application must be replaced.

If the checks keep pointing to the same structural cause, the case for a larger change becomes proportionate. If they point to missing documentation, a missing screen or an unmanaged connection, the fix is smaller.

Architecture in plain terms

Every application makes a few structural decisions, even if nobody names them. Early versions are built to prove a process on a tight budget, by whoever is available, so those decisions tend to stay implicit: one database table for everything about a client, one set of permissions for everyone, business rules written directly into screens, no defined way for other systems to connect, no record of who changed what. They were reasonable choices for the company at that time. They become expensive when the business changes.

It helps to see each decision as a business question:

Settling these decisions deliberately does not mean months of design before anything works. It means making the ones that are expensive to reverse early, and leaving the rest to evolve. A data model that allows a second country costs little to plan; the second country itself can wait until it is real.

Compare the options in proportion to the problem

A rebuild is one option among several, and usually the largest. The others are often enough.

A larger intervention becomes proportionate when the evidence points one way: the same structural cause shows up in several blocked changes, the cost of change keeps rising, the growth you have planned does not fit the current structure, and the smaller options cannot reach it. Without that evidence, the smaller options are usually the better investment. Our application modernization work compares these options before anyone commits to the largest one.

What AI changes, and what it does not

AI-assisted engineering shortens some of the work. Engineers use it to read old code, draft tests, write well-defined components and produce documentation, and it can help them propose which business rules the old system contains.

It does not make the whole project cheaper by the same amount. Writing code is only one part of delivery. Understanding the business, agreeing the design, migrating and reconciling data, testing, connecting other systems, training people and operating the result remain, and each needs people who answer for it. Rules inferred from old code are hypotheses until the people who use the system confirm them and tests against real data bear them out. A rule that was never written down, such as an exception for one client, is exactly the kind a code-reading tool can miss.

A separate question is whether your systems can use AI at all. Document extraction, assistants that answer questions about your own data, and agents that prepare work for review each need clean data, clear permissions, an interface to call and a record of what was done. Google’s 2025 DORA report, based on a survey of nearly 5,000 technology professionals and published in September 2025, found that teams working in loosely coupled architectures with fast feedback loops see gains from AI, while those constrained by tightly coupled systems and slow processes see little or no benefit. The same report found that AI adoption is associated with lower software delivery stability, which it links to weak testing and feedback practices. It is a survey, so it shows associations and does not prove that architecture causes the difference, and it describes software teams in general, not your company.

Two other sources add context, and both are cautionary. In June 2025, Gartner predicted that more than 40% of agentic AI projects will be cancelled by the end of 2027, citing rising costs, unclear business value and inadequate risk controls, and noting that integrating agents into legacy systems can be technically complex. In its State of IT Modernization Report, published on 15 September 2026 and based on a survey of IT decision makers in the US and the UK, the IT services firm Ensono found that 78% say legacy systems matter more to their organization than they did two years ago, mainly because of the data and business logic inside them, and 54% say AI is accelerating modernization. The same release reports that 71% of modernization initiatives exceeded their planned cost. Ensono sells modernization services, Gartner’s figure is a forecast and not a measurement, and neither describes your market. Together they suggest that the knowledge inside an existing system is worth keeping, that AI can speed some of the work, and that unplanned modernization is easy to get wrong.

Whether to act now is therefore a judgment about your own situation. Waiting has a cost when growth is planned: the application accumulates data to migrate, workarounds and integrations to replace. Where the process is stable, nothing on your roadmap needs more from it and documentation covers the risk, waiting can be the right decision.

If you rebuild: a staged plan

A rebuild does not have to be a single switch-over weekend. The approach we prefer grows the new system around the old one:

1. Learn the current system first. Watch the process with the people who run it, read the code and the data, and write down the rules, including the unofficial ones.
2. Design the core. Data model, module boundaries, interfaces, access rules and how the system will be operated.
3. Move one part at a time. Start with the area that blocks the business most or changes most often. Old and new run side by side, and data is reconciled between them.
4. Retire the old application in steps, each with a recovery arrangement, until nothing depends on it.

The objective is to keep the business operating throughout. A migration plan, regular reconciliation between old and new, and a recovery arrangement for each step support that objective. How fully it can be achieved depends on the system, for example on how deeply its data model is shared across processes, and some steps may need a short planned interruption. We establish what is feasible during the assessment, before anyone commits.

When a rebuild is not the right answer

Be skeptical of a rebuild in these cases:

• A product now covers the process. Markets change. If a product handles your process without heavy workarounds today, it is usually cheaper to adopt it.
• The pain sits between systems, not inside one. If most of the effort goes into re-entering data between tools, an integration may solve the problem at a fraction of the cost.
• The business is not changing. If the application supports a stable process and nothing on your roadmap needs more from it, stabilize it, document it and keep it.
• The cause is missing documentation or a single point of failure. Writing down the rules and training a second person addresses that without changing the architecture.

How we work on a rebuild

Discovery usually takes 1-2 weeks. We spend time with the people who use the application, read the existing system, and define the architecture, the first release and an investment range. A first working version typically follows in 6-10 weeks, depending on integrations, data quality and how much is still unknown. That is a first release covering part of the process; the full transition depends on the size of the system and is planned in stages after discovery. Your organization owns the code, the documentation and the project accounts.

That ownership is deliberate. On 29 September 2026, Gartner predicted that by 2028, 70% of enterprises will abandon agentic AI built for them by vendors’ forward-deployed engineering teams, because costs keep rising and they cannot evolve the systems on their own. Its advice is to settle ownership and exit terms before work starts, and to measure success by whether the company can run and adapt the result itself. The prediction is about AI agents, but the lesson carries over to any system a supplier builds for you.

This is the work our custom software development service is built around. It draws on our founders’ background: Dragoș worked as a database administrator, technical lead and CTO before Solandrix, and Lorelai has spent years translating operational processes into the requirements a system has to meet.

Questions buyers ask

How do we know whether architecture is the problem?

Trace the last few slow changes and refused requests back to their cause. If the same structural reason keeps appearing, such as rules in code, tightly connected parts or no interface for other systems, architecture is a likely cause. If the causes are missing documentation, one person’s availability or unmanaged connections, smaller fixes apply. A discovery of 1-2 weeks can establish which it is.

Can we keep using the current application during a rebuild?

That is the objective. The new system takes over one area at a time, with both running in parallel where needed, data reconciled between them and a recovery arrangement for each step. Whether it can be done without any interruption depends on the system and is established during the assessment.

Will AI build the new system for us?

AI assists a large part of the engineering: reading the old code, drafting tests, writing well-defined components and documentation. The architecture, the data model, the verification of every business rule with the people who use it, and the migration and testing stay with engineers who answer for the result.

Our application was built by another supplier. Can you work with it?

Yes. Discovery starts from the code, the database, whatever documentation exists and the people who know how the application is really used. Where knowledge sits with one person or one supplier, capturing it is part of the work.

How long does it take, and who owns the result?

Discovery usually takes 1-2 weeks and a first working version typically follows in 6-10 weeks, depending on integrations, data quality and unknowns; the full transition depends on the size of the system and is planned in stages after discovery. Cost depends on scope, integrations and data quality, and you receive an estimate for each phase. Your organization owns the code, documentation and project accounts.

If your application is getting harder to change

Use the contact form to send us four things: what the application does, who uses it, what has changed in the business since it was built, and what it needs to support next. We will reply with the option we would examine first, whether that is documenting and stabilizing it, targeted fixes, an integration, re-architecting part of it or designing its next version, and what a discovery would need to confirm.