The Cost-Optimized Symbiosis: Combining Standard Software, Low-Code, and AI the Right Way

The Cost-Optimized Symbiosis: Combining Standard Software, Low-Code, and AI the Right Way

Part 3 ended with a question: How do you combine standard software, low-code platforms, and AI-powered custom development without ending up back in the application zoo five years from now?

This article provides the answer. We will explore the Symbiosis Model, examine an honest five-year Total Cost of Ownership (TCO) calculation, and discuss who should ultimately decide whether a capability should be bought, built, or simply configured.

The previous articles laid the groundwork. First, we diagnosed why the application zoo emerged under the assumptions of the early 2000s. Then we outlined the Greenfield architecture we would recommend today: five architectural layers supported by four to six core platforms. Finally, we examined the make-or-buy decision in the age of AI.

What remains is bringing everything together. If standard software, low-code solutions, and AI-enabled custom applications all have their place, what does that actually look like in practice? What architecture makes sense? What are the costs over five years? Who owns which decisions? This article connects the pieces.

The Symbiosis Model: Four Building Blocks, No Purity Doctrine

The future application landscape for mid-sized companies is neither “everything from one vendor” nor “everything built in-house.” It is a deliberate symbiosis of four complementary building blocks that reinforce rather than replace one another.

1. The Standard Core as the Backbone

ERP, CRM, and depending on the business model, PLM and MES, complemented by a data and BI platform. In total, this typically means four to six core platforms that should be purchased rather than built. These systems have been proven across thousands of organizations, come with established upgrade paths, and support the standard business processes that look remarkably similar across industrial companies: procurement, inventory management, invoicing, and customer management. Building these capabilities yourself means taking on technical debt for functionality whose maintenance costs are usually absorbed by the vendor.

2. Low-Code for the Gaps

There will always be gaps between standard platforms: supporting workflows, dashboards, approval processes, and department-specific data collection applications. This is where low-code excels. It enables rapid delivery, empowers business users, and lowers the barrier to implementation. However, success depends on clear IT guardrails. Without governance, low-code can easily become tomorrow’s shadow IT environment, complete with its own maintenance burden and architectural debt.

3. AI-Assisted Custom Applications for Differentiation

Wherever competitive differentiation exists, custom development becomes increasingly attractive. This includes specialized product configurators, unique pricing logic, industry-specific workflows, business capabilities that standard software cannot adequately represent. AI-assisted development has dramatically lowered the threshold for building custom applications. However, these applications belong in a deliberate extension layer-not in shadow IT-and only when long-term operational ownership has been clearly defined. Otherwise, the same four categories of debt discussed in Part 3 inevitably reappear.

4. AI as a Data and Intelligence Layer

The fourth building block is not another application. It is a cross-platform layer that enhances all others. Typical capabilities include classification, anomaly detection, semantic search, forecasting and prediction, intelligent recommendations. These capabilities should not be embedded directly into ERP or CRM systems. Instead, they belong in an independent data and intelligence layer spanning the entire landscape. Organizations that establish this layer early decouple AI capabilities from individual platforms and retain flexibility even when core systems change. Each building block has a defined purpose, clear ownership, and architectural boundaries.

→ A well-designed symbiosis outperforms every purity doctrine.

Where Money Really Leaks: Four Licensing Cost Traps

Before discussing the full economics, let’s pause at the line item that receives the most attention in CFO conversations: software licensing. Licensing is rarely the largest source of waste, but it is often the most visible.

1. Activating Modules Without a Business Case

ERP and CRM vendors make it easy to enable additional modules. Disabling them later is much harder. We regularly encounter environments containing active modules whose original owner can no longer be identified, while licensing costs continue indefinitely.

2. Growth Clauses Without a Cap

Licensing models that scale with users, data volume, or transaction counts can be reasonable. The problem arises when contracts lack a ceiling. Without a cap, every business success directly increases IT expenditure. Negotiate the cap during the initial contract—not after growth has already occurred.

3. All-Inclusive Suites with Significant Idle Capacity

Large suites promise comprehensive coverage. In practice, many organizations use less than 70% of the functionality they pay for. This is not always wrong; sometimes strategic flexibility is worth purchasing. However, it should be a conscious decision rather than an accidental one. An annual utilization review usually reveals the gap quickly.

4. Full Licenses for Occasional Users

The classic silent cost driver. Employees who access reports once a week often receive full-user licenses because read-only or casual-user tiers were never considered during procurement. Over five years, this can easily accumulate into six-figure unnecessary spending.

Der lautlose Klassiker. Mitarbeiter, die nur einmal pro Woche eine Auswertung einsehen, bekommen Vollnutzer-Lizenzen, weil Read-Only- oder Casual-User-Tarife im Anbietergespräch nie thematisiert wurden. Über fünf Jahre summiert sich das zu sechsstelligen Beträgen, ohne dass jemand davon profitiert.

→ Licensing costs are the symptom. Architectural debt is the underlying disease.

There are four recurring licensing cost traps: highly visible in the budget and usually correctable through a small amount of contract discipline and regular usage reviews:

What Does It Really Cost? An Honest Five-Year TCO Calculation

Organizations that make technology decisions based solely on licensing costs have only seen a fraction of the actual bill. A realistic TCO assessment includes six to seven cost categories that accumulate over a five- to seven-year horizon. Licensing is merely one of them. The categories that should be considered include license or SaaS subscriptions, implementation and rollout, customization and configuration, integrations and interfaces, operations and maintenance, training and change management, and risk and maintenance contingency. Underestimating any of these categories means underestimating the decision itself.

Who Decides What We Buy, Build, or Configure?

The question of whether we buy, build, or simply configure a solution is not just an architectural question – it is a governance question. In our experience, this is exactly where most symbiosis models fail: not because of the technology itself, but because nobody is truly clear about who is responsible for what.

In its simplest form, our model defines four distinct roles. First, there is a platform owner for each component of the standard core. This person is responsible for the platform roadmap, ensures data consistency, and represents the system’s interests to the business. Second, there is a business domain owner who owns the underlying process – whether in sales, production, service, or another function – regardless of which system happens to support it. Third, there is a low-code guard: a small IT function that enables and guides business-led low-code development without becoming a bottleneck. Finally, there is a data owner for the AI layer, responsible for determining how data may be used, ensuring its quality, and maintaining accountability for governance and compliance.

This model does not eliminate shadow IT, but it does channel it. Most shadow IT initiatives do not emerge out of defiance; they emerge out of speed. Business teams need a solution, and the formal process is often too slow to deliver it. A low-code guard supported by clear rules creates a legitimate fast path, allowing business users to move quickly without bypassing governance. In doing so, it removes much of the rationale for shadow IT in the first place.

The Quick Check: Five Questions for Every Use Case

Whenever a new requirement appears – whether from the business, IT, or an external recommendation – five questions should be answered before making a decision.

1. Which architectural layer does this belong to: core, extension, specialized application, or data layer?

2. Who owns the platform, and who owns the business process?

3. Which integrations are required, and who maintains them?

4. What is the realistic five-year TCO, including contingency reserves?

5. Who will operate, maintain, and own the solution five years from now?

If you can answer all five questions honestly, you no longer have a tool decision. You have an architectural decision. That is the difference between a symbiosis and the next application zoo.

What Comes Next

The Symbiosis Model describes the target architecture. What it does not describe is the migration path. No mid-sized company arrives tomorrow with a blank technology landscape. Moving from today’s application zoo to a disciplined symbiosis—while keeping the business running, avoiding a big-bang transformation, and minimizing disruption-is a challenge in its own right. That topic will be covered in Part 5 of this series.

Until then, consider one question before your next technology investment: Do you actually know what your largest platform will cost over the next five years—including customization, integrations, maintenance, and contingency reserves? Or do you only know the licensing fee? If it is the latter, you are working with the same incomplete calculation as most organizations.