Which Model Fits Which Process?
Companies often face a seemingly simple decision when it comes to new software: implement an existing SaaS solution or develop a custom application.
Both paths have clear advantages. However, both can become the wrong model if chosen without regard to the specific process.
Standard software is not inherently inflexible. In-house development is not automatically sovereign. And co-creation is not just a new word for customizing.
The right decision depends on how standardizable a process is, how strategic the data and knowledge it contains are, and what responsibility a company can take on in the long term.
This comparison looks at three models:
- classic SaaS,
- complete in-house development,
- co-creation on an existing platform.
Overview of the Three Models
| Model | Central Strength | Typical Limitation |
|---|---|---|
| SaaS | quick start on a proven standard | limited individuality and potential vendor dependency |
| In-house Development | maximum design freedom | high responsibility for architecture, security, and operation |
| Co-Creation | individual solution on an existing foundation | requires active collaboration and clear responsibilities |
None of these models is fundamentally superior. The key is the fit to the application case.
When Classic SaaS Makes Sense
SaaS is particularly strong when a process is largely standardized and does not form a direct competitive advantage.
Typical examples are:
- video conferencing,
- scheduling,
- travel expenses,
- simple collaboration functions,
- or clearly defined administrative processes.
The advantages are well-known:
- quick start,
- predictable updates,
- low operational effort,
- standardized security and administration functions,
- and a large ecosystem of integrations.
SaaS becomes problematic when a company tries to permanently squeeze a highly individual core process into a rigid standard model.
Warning signs are:
- extensive workarounds,
- many manual exports and imports,
- additional tools for missing functions,
- high costs for individual adjustments,
- or processes that are oriented towards the software rather than actual needs.
SaaS remains usable, but may no longer be the sole solution.
When In-house Development Makes Sense
Complete in-house development offers maximum freedom. Data model, user interface, integrations, and process logic can be tailored exactly to the company.
This is particularly interesting when:
- the process creates a significant competitive advantage,
- standard solutions do not cover the core needs,
- there are special technical requirements,
- or complete control over operation and further development is necessary.
The risks are not only in development costs.
A productive enterprise application requires ongoing:
- architectural decisions,
- roles and permissions,
- tests,
- monitoring,
- security updates,
- documentation,
- interface maintenance,
- data migration,
- and competent responsible parties.
AI-supported development can significantly accelerate implementation. However, it does not eliminate these long-term tasks.
In-house development is therefore sensible when the company can and wants to take on not only development but also long-term product responsibility.
What Co-Creation on a Platform Means
Co-creation attempts to combine the strengths of both models.
An existing platform provides the technical foundation. This can include:
- identity and rights management,
- data models,
- interfaces,
- document and knowledge management,
- process automation,
- AI assistants,
- operation and monitoring,
- as well as development tools.
The user company brings in the specific process, professional requirements, data, and expert knowledge.
Together, an application is created that is individual enough for the process but does not start from scratch.
Co-creation is particularly suitable for cases where:
- standard software does not sufficiently map the process,
- complete in-house development would be disproportionate,
- several existing systems need to be integrated,
- expertise plays a central role,
- and the process is to be further developed step by step.
Co-Creation is Not Customizing
In classic customizing, the customer operates within a framework defined by the provider. Fields, roles, masks, and workflows are configured, but the basic product logic remains unchanged.
Co-creation goes further.
The joint solution space can grow. New assistants, data flows, or professional modules are created iteratively. Insights from operation flow back into further development.
The difference is reflected in the questions:
In customizing:
Which existing function can we adjust?
In co-creation:
Which specific process should measurably improve and which platform components do we need for it?
Co-creation must not be confused with unstructured contract development. Platform boundaries, rights, and responsibilities must be clearly defined.
What Responsibility Remains with the Provider
A co-creation model only works if the platform provider takes on more than just individual development services.
Typical areas of responsibility are:
- technical architecture,
- security and updates,
- platform operation,
- integration standards,
- quality management,
- documentation,
- monitoring,
- and long-term compatibility.
The provider ensures that individual extensions do not become an unmanageable isolated solution.
What Responsibility Remains with the Customer
The user company is not just a client. It is a professional co-designer.
This includes:
- clear process goals,
- availability of experts,
- decisions on data and permissions,
- prioritization of requirements,
- tests in the real work process,
- and internal responsibility for introduction and change.
Without active participation, no co-creation arises, only another IT project with unclear expectations.
Decision Criteria for the Right Model
1. How Standardizable is the Process?
The more a process functions the same across industries, the more suitable SaaS is.
2. How Strategic are Data and Knowledge?
If a process contains business-critical experiential knowledge, the need for control and further development increases.
3. How Strongly Must Existing Systems be Integrated?
Many individual integrations can make a standard product economically unattractive. A platform with reusable connectors can offer advantages here.
4. How Quickly Does the Process Change?
A stable standard process requires less flexibility. A growing or experimental process benefits from iterative development.
5. What Operational Responsibility Can the Company Take On?
Those who do not want to build their own product organization should critically examine complete in-house development.
6. How Important is Exit Capability?
Data export, source code rights, documentation, operating model, and transfer possibilities should be clarified before signing a contract.
Three Typical Scenarios
Scenario 1: Standard Process
A company needs an established solution for travel expenses. The requirements hardly differ from the market standard.
Suitable Model: SaaS.
Scenario 2: Strategic Core Process
A machine builder develops a proprietary configuration process that is directly part of its competitive advantage and must be deeply integrated into product data.
Suitable Model: In-house development or very extensive co-creation, depending on existing product expertise.
Scenario 3: Knowledge-Intensive Industrial Process
A manufacturing company wants to record fault messages by voice, integrate SAP PM, secure experiential knowledge, and gradually add more assistants.
Suitable Model: Co-creation on an industrially suitable platform.
Why a Pilot Process is Better than a Fundamental Decision
Companies do not need to first decide on a company-wide platform strategy.
A sensible entry point is a clearly defined process with a measurable problem:
- incomplete reports,
- manual duplicate work,
- lack of system integration,
- long information searches,
- or impending knowledge loss.
This process can be used to test:
- how quickly a solution is created,
- which platform components are reusable,
- how well professional users are involved,
- and whether the chosen model is sustainable in the long term.
This turns an abstract build-or-buy discussion into a concrete economic decision.
Conclusion
SaaS is strong when standardization is more important than individuality.
In-house development is strong when a process is strategically unique and the company can take on long-term product responsibility.
Co-creation is strong when an individual process is to be created on an existing technical foundation.
The crucial question is not:
Which model is fundamentally the best?
But rather:
Which model gives this specific process the right balance of speed, control, and further development capability?