Creating a business application: a guide for decision makers

Customized business application: what are we really talking about?

Definition and scope of business applications

A business application (or Business application) is a software designed to support a process specific to your business. For example:

• management of technical interventions;
• production monitoring;
• complex product configuration;
• R&D project management;
• management of quality audits.

It is opposed to generic solutions (CRM, ERP, office suite) that cover a wide range of needs but do not perfectly suit the particularities of your business operation.

The fundamental distinction is the Degree of “fit” between the software and your real process. Standard software generally covers a large part of the needs (often estimated between 70 and 80% depending on the contexts and solutions), it adapts to the common processes of all companies. That said, when your process is a competitive advantage, this gap takes on a whole new strategic value.

As an illustration, if we take an industrial maintenance company whose intervention cycle follows a proprietary logic — diagnosis, quotation, planning, intervention, invoicing — with very fine business rules at each stage, then no tools for Field Service Management Standard does not accurately model this process. This is where a tailor-made business application is highly strategic.

The tailor-made spectrum: from parameterization to full custom development

Customized development is based on a 5-level continuum, each with its own characteristics in terms of flexibility, costs and deadlines:

• Level 1 — Setup : advanced configuration of a standard solution like Dynamics 365, without development.
• Level 2 — Extension : adding custom plugins or components to an existing solution.
• Level 3 — Customized low-code : development of a Power Apps application on Dataverse, integrated into the Microsoft ecosystem.
• Level 4 — Integrated custom development : .NET or React application connected to standard solutions via API.
• Level 5 — Full custom : development from scratch, completely independent of any standard base.

The more you advance to level 5, the more flexibility increases, but also the costs, deadlines and complexity of maintenance. Most business projects find their balance zone between levels 3 and 4.

Standard vs tailor-made: the real debate is not there

The real question is not “standard or custom?” buts “where is the differentiating value?”

Your accounting, payroll or administrative management processes are shared by all companies in your sector. Since standard solutions cover them perfectly, there is no point in investing in tailor-made solutions.

On the other hand, your customer relationship method, your product configuration process or your own supply chain can be a real competitive advantage. This is where tailor-made is fully justified.

Note that the most effective approach is often hybrid : a well-configured standard base, complemented by tailor-made extensions targeted at differentiating processes.

When does tailor-made development become relevant?

Differentiating business processes and strong specificities

Certain contexts make tailor-made solutions indispensable. This is the case when your business process is unique and a competitive advantage that you don't want to level out by adopting a generic tool. This is also the case when your sector imposes very specific regulatory constraints (health, aeronautics, chemistry, finance) that standard solutions do not incorporate natively.

To assess the relevance of tailor-made solutions in your context, five questions deserve to be asked, namely:

• Is my process a real competitive differentiator?
• Do the standard solutions not sufficiently cover my needs?
• Do current workarounds (Excel, re-entries, workarounds) represent a significant cost?
• Is my process stable enough to warrant development investment?
• Do I have the resources to ensure long-term maintenance?

If you answer “yes” to at least 3 of these questions, tailor-made development deserves a thorough evaluation.

Limits and frustrations of standard solutions

Parameter rigidity is often the first frustration: some configurations are simply not possible, regardless of the product version. Dependence on the publisher is another: if your need is not part of the product roadmap, you wait. And this, sometimes several years.

There is also the very common case of CRM, which imposes a 5-step sales process while your real sales cycle has 12 steps, with cross-validations. Teams then bypass the tool instead of using it. Therefore, the data that should feed your management is scattered in local files. At this stage, tailor-made is no longer an additional cost but on the contrary, the cheapest solution.

Modernization of the IS as a whole can also highlight these limitations: when we try to build a coherent ecosystem, weak links (in this case poorly adapted tools) become structural obstacles.

ROI of tailor-made solutions: when the investment becomes profitable

Calculating the return on investment of a business application is based on a simple formula: ROI = (Annual Gains − Annualized Costs)/Annualized Costs × 100.

Earnings include direct earnings:

• time saved;
• reduction of errors;
• suppression of re-entries.

There are also indirect gains, which are less visible but just as real:

• better adoption of tools;
• improved data quality;
• team satisfaction.

The costs, on the other hand, include initial development and evolutionary maintenance, which is generally estimated, according to industry practices, between 15 and 20% of the initial cost per year.

This simplified formula gives a useful order of magnitude. In structuring projects, it benefits from being supplemented by a more comprehensive financial analysis, integrating the updating of flows and indirect costs.

Be careful to anticipate the maintenance from the frame. A tailor-made application that does not evolve quickly becomes obsolete, which ends up cancelling out the initial gains.

Development approaches: from low-code to native code

Power Platform: the sweet spot for the majority of business needs

For the vast majority of business applications, Power Platform is the optimal approach. Power Apps makes it possible to develop functional applications much faster than with traditional development, with native integration into the Microsoft ecosystem (Dynamics 365, Microsoft 365, Azure) via Dataverse to unify the data layer.

As a result, maintenance is not only much faster but also considerably simplified. In addition, technical debt remains under control and the IT governance is maintained thanks to integrated security and audit mechanisms. As for current developments, an internal team without heavy development skills can therefore take care of them.

However, the Power Platform is not suited to critical performance needs on very large volumes, or for highly sophisticated user interfaces. But for the vast majority of business management applications, the tool does not run up against these limitations.

.net/React custom development: when complexity justifies it

Some contexts require native development. Especially when the performance requirements are critical (intensive calculations, very high volumes, real-time refreshing) or when the user interface must meet very specific UX constraints that a low-code platform cannot satisfy.

Integrations with industrial systems (IoT, proprietary APIs, production equipment) also fall into this category, as do the needs for portability outside the Microsoft ecosystem. .NET Core or React development then provides maximum flexibility, at the cost of greater complexity and costs.

Hybrid approach: combining the best of both worlds

The hybrid approach is to use Power Platform for most features (management of contacts, opportunities and workflows) and to develop in native code only the components that really require it:

• a complex product configuration engine;
• a specific calculation module;
• a very technical system integration.

The two layers communicate via custom connectors or Azure Functions, offering seamless integration for the end user. This approach makes it possible to scale gradually: start with the Power Platform, identify areas of friction, switch the only components concerned to custom development.

Methodology for a successful tailor-made development project

Phase 1 — Business framework and definition of the need

It is almost always because this phase has been underestimated that a project ends up in difficulty. Dedicating a significant portion of the budget to framing helps avoid unnecessary developments, costly pivots along the way, and deliveries that don't match users' real expectations.

Concretely, this phase is based on workshops with business management and key users. The objective is to map the target process in detail, to identify the real irritants and the “nice to have” and to define measurable success KPIs. At the end of this phase, you should be able to define a MVP (Minimum Viable Product) : the minimal version that solves most of the pain, even if it does not cover all of the need.

It is also at this stage that the technological approach is decided. A good business framework is always the prerequisite for an informed technological choice, and not the other way around. Finally, the writing of a technical specifications structured formalizes these decisions before entering into development.

Phase 2 — Technological choice and architecture

The choice of the technical stack must be guided by objective criteria:

• functional complexity;
• data volume;
• performance requirements;
• skills available internally;
• budget;
• maintenance horizon.

One simple decision matrix sufficient in most cases. If the volume is moderate, the Microsoft 365 integration required, and the IT team is limited, Power Apps on Dataverse generally represents the best compromise between speed, cost, and integration. If intensive calculations or very specific interfaces come into play, native development or the hybrid approach is required.

The architecture must also anticipate future scalability: increasing volumes, functional evolutions, new integrations. A modular architecture facilitates these evolutions and limits the risk of a complete redesign.

Phase 3 — Iterative Development and User Involvement

Development in short sprints (2 to 3 weeks) with regular demonstrations to end users is the method that most effectively reduces risks. It continuously validates that we are building the right thing, and not just that we are building correctly.

User Acceptance Testing (UAT) must be continuous rather than concentrated at the end of the project. Adjustments during development are inexpensive; post-delivery fixes can be much more expensive. Documentation, too, happens during development, not in a final phase that no one will ever find the time to complete.

Agile methods constitute a framework particularly suited to this approach: they structure iterations, clarify responsibilities and maintain alignment between IT teams and business departments throughout the project.

Phase 4 — Deployment, Training and Change Management

An application that is technically perfect but not adopted by its users is a failure. Adoption is the real KPI for success of a business application project.

The deployment strategy as a restricted pilot (a region, a department, a team) before generalization makes it possible to gather real feedback, to adjust and to build internal relays (the Super-users) prior to large-scale deployment. The training should not be limited to technology: it must explain the “why” of the change, show how the new application concretely improves the user's daily life.

A dedicated part of the budget, which is often underestimated, must be devoted to supporting change. This is often what makes the difference between a transformative project and an underused tool. A good integration into the Digital workplace of the company, the environment in which your teams really work, further amplifies the chances of adoption.

Today, the Microsoft ecosystem offers a particularly favourable environment for rapidly developing high-quality, integrated and governed business applications. It is still necessary to choose the right level of tailor-made services and to orchestrate it methodically.

Are you wondering if your need justifies tailor-made development? Askware offers you a scoping workshop to assess the relevance of the approach in your context and establish a realistic roadmap. Contact our experts to discuss it.