When a new need arises, teams have access to four main families of solutions: adopting a SaaS, configuring a low-code platform, assembling and customizing an open-source base, or developing a custom application. Each can be excellent in the right context and expensive in the wrong one.
The choice must not be guided by a technological preference. It must be based on the value of the process, its specificity, the required speed, the integrations, the level of control, and the cost over time.
Start by distinguishing between standard need and business benefit
A standard process, such as expense report management or booking a room, often benefits from an existing product. Reinventing it adds little value and requires maintaining functions that are already industrialized elsewhere.
Conversely, a pricing engine, a regulated workflow, a sector-specific marketplace, or an extranet directly linked to the value proposition can justify a more customized solution. The software then becomes a business asset rather than just a support tool.
The difficulty comes from the intermediate cases: 70% of the need seems standard, but the remaining 30% involves differentiation. The right architecture can combine several families rather than forcing the entire project into just one.
SaaS: speed and standardization
A SaaS software is run by a publisher and accessed as a service. It offers quick setup, shared updates, and a limited initial cost. It is particularly suitable when the need matches the product model and the organization accepts its rules.
Its limitations appear with customization, atypical integrations, volume, data localization, or dependence on pricing. It is necessary to check export capabilities, APIs, service commitments, access management, subcontractors, and the exit scenario.
The good signal: the team agrees to adapt its process to the product. The bad signal: each workshop ends with a workaround or a specific extension.
Low-code: accelerating workflows under governance
Low-code platforms allow you to build forms, rules, automations, and interfaces with less traditional code. They are effective for internal applications, prototypes, and processes that evolve quickly.
The gain, however, depends on governance. Without conventions, testing, environment management, and component control, the debt can shift from the code to a multitude of flows that are difficult to understand. Licensing, performance limits, connectors, and the availability of skills must be integrated into the TCO.
The good signal: a well-defined process, covered integrations, and a team capable of administering the platform. The bad signal: complex business logic scattered across screens and unversioned automations.
Custom open source: control and assembly
A CMS, framework, or open-source product provides an auditable and extensible foundation. The company retains more control over the code, data, and hosting. It benefits from an ecosystem without depending on a single vendor.
Open source does not mean free. You have to design the architecture, integrate, secure, update, and operate it. Quality depends on the choice of components and the ability to stay close to their standard functioning. Deeply modifying the core of a product can make version upgrades costly.
The good signal: the need matches the capabilities of a mature foundation and the extensions can remain clearly separate. The bad signal: the team selects a platform only to avoid licenses while its model does not fit.
Custom development: investing in differentiation
A custom application is designed around the company's rules, users, and integrations. It offers great design freedom, clear ownership, and development driven by product strategy.
This freedom involves an initial investment, operational responsibility, and the need for ongoing maintenance. Customization is only relevant if the value of the process, its duration, and its specificity justify this effort.
The good signal: the solution must provide a competitive advantage, consolidate multiple systems, or handle rules that are impossible to standardize. The bad signal: the need is ordinary, temporary, or too uncertain to be specified.
The diagram positions four families without assigning them an absolute ranking. SaaS generally favors a rapid launch and operation driven by the vendor. Low-code accelerates configuration while requiring platform governance. Customized open source increases control and integration responsibility. Custom development offers the greatest design freedom, with increased responsibility over the lifecycle. These positions still need to be confronted with the project context. The following table provides an equivalent textual representation.
| Family | Commissioning period | Control and customization | Operating liability | Point of vigilance |
|---|---|---|---|---|
| SaaS | generally short if the need is standard | framed by the product | mainly carried by the publisher | export, integrations, pricing and exit |
| Low-code | court to intermediary according to the integrations | extended configuration within the limits of the platform | shared between the organization and the publisher | governance, testing, licenses and skills |
| Custom open source | intermediate | high if the extensions remain controlled | carried by the organization and its partners | integration, security, updates, and hosting |
| Custom development | depends on the scope and the transition | very high | carried by the organization and its service provider | investment, operation and ongoing maintenance |
The twelve criteria that structure the decision
1. Business specificity
The more differentiating the process is, the more value control and customization have. A standard feature promotes the adoption of a product.
2. Commissioning time
A SaaS or a low-code platform can accelerate the launch, provided that integration and migration remain simple. A short timeframe does not allow ignoring the data and change management.
3. Complexity of the rules
Numerous, versioned, calculative, or audit-subject rules require clear representation, testing, and traceability that not all platforms offer in the same way.
4. Integration into the information system
The number of APIs is not enough. It is necessary to check the volumes, synchronization, errors, permissions, and the management of credentials.
5. Security and Compliance
Assess the data, roles, logging, hosting, subcontractors, and the ability to meet internal or regulatory requirements.
6. Sovereignty and control
The control covers the code, the data, the infrastructure, the pricing models, and the ability to switch providers.
7. Personalization of the experience
A highly distinctive or public interface may exceed the customization capabilities of a standard product.
8. Scalability
It is necessary to distinguish between technical load increase and functional evolution. A solution can support a million users while making each new rule costly.
9. Team autonomy
Who will be able to administer, configure, publish, and diagnose? Real autonomy requires rights, training, safeguards, and documentation.
10. Initial cost
The launch budget remains a legitimate constraint, but it must be compared to an equivalent scope and duration of use.
11. TCO
Licenses, hosting, maintenance, developments, security, support, and reversibility must be planned over several years.
12. Skills and ecosystem
The availability of partners, developers, and documentation resources reduces the risk. A high-performance technology that is impossible to maintain locally can become a bottleneck.
Four typical scenarios
Simple and urgent internal tool
A SaaS or a low-code solution is often relevant. The project should prioritize adoption, standard configuration, and export capability.
Client portal connected to the IS
A hybrid architecture can combine an open-source or custom base with specialized SaaS services. Interfaces and identity management become structuring.
Marketplace or differentiating platform
The core business, research, matching, and business rules often justify custom solutions. Standard functions like payment or email can remain outsourced.
Regulated workflow
Traceability, permissions, evidence retention, and testing take precedence. The choice depends less on the speed of a prototype than on the ability to audit the system in production.
Think hybrid without creating a puzzle
Combining several solutions is often rational: CMS for content, business application for rules, identity provider, search engine, and specialized payment. The architecture must nevertheless limit the number of boundaries and clearly define the source of truth.
Each service adds a contract, a permission, a dependency, and a failure scenario. Hybridization is useful when it isolates a standard capability, not when it spreads the same rule across five tools.
Carry out a proof before committing
When two options remain close, a targeted proof of concept can test the riskiest point: an integration, a rule, a volume, or a journey. The prototype should not aim to impress; it should meet measurable criteria and document what remains to be industrialized.
Contracts and architectures must preserve an exit. Check data export, formats, API limits, rights on specific code, and the availability of logs.
A committed and reversible decision
The best choice is the one whose trade-offs are understood. A SaaS can be ideal even if it limits customization. A custom development can be reasonable even if it costs more initially. The risk mainly comes from a solution selected without regard to actual value and constraints.
Partitech works with proven open source CMS, frameworks, and components, while integrating specialized services when it adds value. Our role is to build a proportionate, maintainable, and sufficiently reversible architecture to support the evolution of the business.
To complete this decision, estimate the total cost of software ownership, compare the approaches WordPress, Drupal, Symfony or headlessand prepare aAPI-first architecture. Also discover the Partitech services.
Official references
References checked on August 17, 2026: