A custom mobile app is easier to justify financially than standard tooling when the mobile workflow cannot easily be reduced to standard fields and validations, particularly if the legacy system contains complex field validations and triggers that are insufficiently documented. In such cases, a custom solution with a Backend-for-Frontend (BFF) layer provides more stable and manageable integration.
Cost structure of mobile apps with legacy integration
When developing mobile apps connected to legacy systems, most of the budget shifts to integration work rather than screen design. This is due to the need to harmonize mobile interactions with rigid legacy systems through a Backend-for-Frontend (BFF) layer.
- A custom solution is needed when standard tooling cannot handle the complex field validations and triggers of legacy systems.
- The initial costs of custom development are higher, but it offers lower and more predictable ongoing maintenance burdens.
- Standard tooling appears cheaper, but can lead to rising licensing costs and vulnerability to backend changes.
- A realistic budget must distinguish between interface work and integration provisions to ensure operational continuity.
When custom mobile apps are preferable to standard tooling
The financial trade-off between a custom mobile app and standard tooling does not start with the number of screens, but with the gap between the mobile way of working and the legacy system. Mobile interactions are generally reactive and stateless: a user expects a quick response to an individual action. An older core system, by contrast, may operate with rigid, monolithic sessions, proprietary protocols and dependencies not designed for mobile use. When those two worlds are connected directly, a translation problem arises that standard tooling does not solve automatically.
In that situation, a Backend-for-Frontend, or BFF, can form the boundary between the mobile app and the existing system. This intermediary layer harmonizes protocols and safeguards data integrity. The BFF is therefore not an additional screen or cosmetic extension, but a separate component that makes mobile interaction suitable for the constraints of the core system. This is precisely where the budget shifts: from what the user sees to what is needed to move data back and forth in a controlled manner.
Custom development is preferable when the mobile workflow cannot easily be reduced to the standard fields and standard validations of a generic platform. This is especially true if the legacy system contains complex field validations and triggers that are insufficiently documented. Direct deployment of generic tooling can then lead to point-to-point scripts acting as makeshift connections between the app and the core system. Those scripts may initially seem like a quick route, but they are fragile: a change in the core system can then break the mobile workflow.
The relevant financial boundary is therefore not whether a standard package can display a mobile interface. The question is whether the package can support the required translation without creating a collection of disconnected links. If this translation, validation and data protection must be designed independently of the screens, a custom app with a BFF is often easier to justify. The higher initial investment is then mainly not about design, but about a manageable connection between the mobile process and the existing core system.
Sources for this section: microsoft.com
Why are integration costs often higher than expected?
For a mobile app with a legacy connection, the initial budget is often anchored to the number of screens. This is understandable, because screens are visible and countable. But that count says little about the effort behind each form, every status change and every data transfer. As soon as a mobile screen must retrieve, modify or validate data from an existing system, a second workstream emerges that is not visible in the interface design: the integration cost item.
If that item is kept artificially low, budget is often removed from components that only become noticeable when the app operates under real business conditions. Consider a message queue and automated validation tests. Without these provisions, a go-live may encounter stalled backend processes and data loss. The initial saving is then not more efficient delivery, but a shift of work and risk to a later stage, when remediation must take place under time pressure.
Mobile conditions also make the cost structure less linear than a screen-based estimate suggests. Network connections can fail in the field. If the app then makes only direct, synchronous calls to the legacy system and has no local queue, forms can become stuck. For field staff, this turns from a technical incident into a process problem: they revert to paper contingency forms and manual handover. This creates additional actions outside the app, while the data still has to be processed later.
The core of a realistic budget is therefore distinguishing between interface work and the provisions that keep a mobile workflow usable even during network outages and backend constraints. Middleware, validation and controlled processing are not optional embellishments around the app. They determine whether mobile input can move safely and usefully through the existing process. Those who budget only for screens are comparing a visible front end with a solution whose real weight lies at the back end.
Consequences of underestimated integration effort
Underestimating backend and middleware effort has a more direct financial consequence than a small deviation in screen design. The available evidence cites acute budget overruns of 50% to 100%. These are not marginal corrections within an ongoing project. At this scale, an initiative may have to be halted halfway through because emergency funding is needed to make integrations operational after all. The planned mobile functionality may already exist, but it cannot be reliably connected to the core system.
This outcome also changes the project's governance position. A budget set on the basis of the visible app proves insufficient for the technical connection that makes the app usable. The additional funding is then not aimed at extending the original ambition, but at restoring work that was included too narrowly in the initial estimate. This puts pressure on the relationship between expected costs and progress: the project requires more resources before the intended business flow is operational.
In addition to the immediate overrun, integration debt arises when standard tooling is rushed into a direct connection with the legacy system. Without decoupled middleware, a dependency grows that makes the mobile app vulnerable to backend changes. This debt is not solely a maintenance issue. Necessary security updates to the backend may be postponed for fear of breaking the mobile flow. A change required for security thus becomes tied to uncertainty about the continuity of the mobile workflow.
The cost of underestimation therefore consists of two different kinds of pressure. First, there is the visible financial interruption: additional funding is needed to complete the integration. Then there is the less visible constraint on future backend changes, because a direct connection is difficult to modify without consequences for the app. A low initial estimate can therefore result in a more expensive and less adaptable whole than a budget in which backend and middleware work are included as full components from the outset.
Sources for this section: forrester.com
Key considerations when choosing between custom development and standard tooling
The comparison becomes clearer when the initial expense, recurring costs and connection risk are assessed separately. The table below distinguishes what a lower starting price actually means from what is needed to demonstrably manage the integration.
| Consideration | Standard tooling with direct connection | Custom development with explicit integration provision | Financial implication |
|---|---|---|---|
| Initial investment | A standard platform may initially seem less expensive because some mobile functionality is already available. | Custom development has higher start-up costs because the solution and required connection are set up separately. | A low entry price is not a complete cost comparison when the connection still requires additional work. |
| Ongoing costs | Monthly user licences and costly workarounds can accumulate in operations. | The maintenance burden can be low and predictable despite the higher upfront investment. | Assess costs over the period of use, not only at the time of purchase. |
| Modifiability of the connection | A direct connection can be set up quickly, but makes the app vulnerable to backend changes. | A decoupled approach requires an additional investment before the app is ready. | The extra initial cost is offset by isolating future modernization from the mobile flow. |
| Proof before screen development | When screens take priority, it remains unclear whether the connection meets expectations. | Formal API contract specifications using OpenAPI or Swagger and automated integration tests can be applied before screen development. | This makes the connection risk measurable before a large part of the budget is committed to the user interface. |
Sources for this section: forrester.com
Steps for preparing a realistic budget
A useful budget makes visible the components that would otherwise disappear behind the screen budget. The following steps divide the estimate along the boundary between mobile experience, reusable integration and protection of the existing core system.
- 1. Allocate a separate item for the UI layer. Budget the mobile screens as their own layer rather than grouping all work into a single mobile item. This makes visible which part of the investment relates to what users operate. This separation prevents interface work from automatically being confused with the effort required for data exchange, validation and processing. The UI layer can therefore be assessed on its own scale, without necessary underlying work appearing as unexplained design expenditure.
- 2. Budget the API as a reusable asset. In addition to the UI layer, include a separate API asset. This item covers the data orchestration and regression tests needed to keep the connection usable. Estimating this explicitly prevents these activities from being cut as perceived screen overhead. In this approach, the API is not a residual item after the app is designed, but a reusable component with its own purpose: to process data between the mobile process and existing environment in a controlled manner.
- 3. Include protection of the legacy system as a budget component. Allocate work for asynchronous message queues and rate limiting. These provisions protect vulnerable legacy monoliths against overload. This links the budget to a concrete operational boundary: mobile interactions must not create a load that the core system cannot adequately handle. The costs therefore belong to the mobile extension, even if they are not visible as a separate app screen.
- 4. Test each cost item against its function in the chain. Do not place an expense under a general category if it has a specific role. Screen work serves mobile operation; the API serves reuse, data orchestration and regression testing; queues and rate limiting serve to protect the core system. This classification makes visible what happens if an item is removed. A lower estimate is only meaningful when the relevant function is demonstrably not needed, not when it is simply excluded from the budget.
Sources for this section: forrester.com
Frequently asked questions about budgeting and integration
A low quote for standard tooling and skipping middleware often appear to be two different choices. In practice, both arise from the same trade-off: saving time and investment by connecting the mobile app directly to the backend. The consequences become visible only when the backend changes.
- Why do quotes for standard tooling seem so much lower, and what happens if middleware is skipped? Standard tooling appears less expensive when the quote assumes a direct point-to-point connection. That connection initially saves design time because no separate decoupled layer is included. The lower price therefore mainly indicates that part of the architecture work is not included in the initial estimate. If middleware is skipped, the app remains directly dependent on the backend. Any backend change can make the mobile flow vulnerable. A decoupled middleware layer does require additional upfront investment, but it isolates future modernization from the mobile app. The objection to that investment is therefore valid when only start-up costs are considered; it carries less weight when the costs and uncertainty of changes in the existing system are included as well. The relevant question is not whether a direct connection looks faster on paper, but whether the organization accepts that a backend change can directly affect the mobile workflow.
Sources for this section: microsoft.com
Key insights for budgeting and integration
The budget can be used to test the chosen change path. Not every mobile initiative requires replacement of the existing system. When the mobile extension must also enable gradual modernization, the assessment shifts from individual functionality to the architectural boundaries that remain resilient during that change.
- Set the budget and change boundary in advance. Use established enterprise architecture patterns such as Strangler Fig and Anti-Corruption Layer when a legacy environment must be modernized gradually. These patterns provide direction for an approach in which new components can be placed alongside the existing environment, without the mobile extension automatically inheriting every peculiarity of the old system. Link that architectural choice to a separate UI and API budget: the UI is the visible mobile component, while the API asset supports connection and reuse. Before screen development, also create formal API contract specifications using OpenAPI or Swagger and carry out automated integration tests. This makes it visible earlier where mobile needs and the existing environment do not align. The financial constraint remains concrete: when the costs of safeguarding this boundary are not included, the budget effectively depends on untested connections, and the mobile flow can come under pressure when the core system changes.
Sources for this section: martinfowler.com
