Software as a service for the mid-sized company: buy, configure or build

More options, more risk of fragmentation

Adopting cloud tools has become the norm in organizations of all sizes. McKinsey’s 2025 global survey on the state of AI shows, for example, that 88% of organizations use AI in at least one function, much of it delivered as a cloud service, but that only 7% have scaled it (McKinsey). The ease of contracting software by subscription has a side effect we often see in the mid-sized company: each area contracts its own tool, none of them talks to the others and the data ends up fragmented.

BCG identified a modular, business-led technology and data platform as one of the six success factors of digital transformations (BCG). Modular does not mean fragmented. It means the pieces are chosen to fit.

The right question

The usual question is “what software should we buy?”. The useful question is “which process do we want to change, who uses it and which decision do we want to improve?”. With that answer, the choice between buying, configuring or building becomes clearer.

In our work with a business group, the answer for most processes was to configure: the ERP already had the modules needed for procurement, inventory and barcoding, but they had not been configured. In other cases, such as a quoting tool that combined standard components with cost calculation, the answer was to build a specific tool, connected to the ERP. Buying a new system was not the first option in any case.

The software vendor’s point of view

We also work on the other side: with a technology SME that develops tailor-made solutions, integrations and support for companies. Its strategic challenge was competing against technology services companies with much greater scale. The diagnosis revealed a strategy that was more implicit than documented, with no structured competitive analysis or explicit differentiation.

The strategic conversation revolved around where a small vendor can win. The answers we explored were specialization in an industry or a type of process, proximity to the client and speed of response, and the shift from tailor-made projects toward recurring products or services. The last is the hardest and the most valuable: turning what is built for one client into a component that can be offered, with configuration, to many.

From project to product

The shift from project to product requires decisions many software companies don’t make. Which part of the work is common to several clients. What is configured and what is customized. How to charge: per project, by subscription or by usage. How to provide support and updates without each client having a different version.

In our experience, the small software companies that achieve this transition start with a narrow segment, with a well-defined problem, and resist the temptation to customize everything. Product discipline is, above all, the discipline of saying no.

Architecture before tools

For the buying company, the recommendation is to think about architecture before tools. A minimum architecture defines which system is the source of each critical data item (customers, products, suppliers, transactions), how the systems are integrated and who is responsible for each one. With that definition, every new tool is assessed against a simple question: does it fit?

In the teams for the programs we design, cloud solutions architecture is a capability we build in explicitly. The reason is that most software decisions that go wrong don’t fail because of the tool, but because of how it integrates with everything else.

Total cost, not the subscription

The monthly subscription is the most visible cost of software as a service, but it is rarely the largest. The total cost includes initial configuration, integration with other systems, data migration, training, the team’s time during adoption and the cost of exiting if the tool doesn’t work. An honest assessment compares alternatives on the basis of that total cost and of the value of the process they improve.

Signs that there are too many tools

There are signs that a company has accumulated more tools than it can manage. People copy information from one system to another by hand. Reports from different areas show different figures for the same thing. Nobody knows for sure how many subscriptions the company pays for or who uses them. Every new team member takes weeks to learn the tools they need. And when someone leaves, access to or knowledge of a critical tool is lost.

If several of these signs are present, the first step is not to buy a tool that integrates everything, but to take an inventory: which tools exist, which processes they support, who uses them, how much they cost and what data they hold. With that inventory, the consolidation decisions become obvious.

Security and continuity

Software as a service shifts part of the security responsibility to the vendor, but not all of it. The company remains responsible for who has access, how credentials are protected, the personal data it stores and being able to recover its information if it changes vendors. We recommend reviewing in every contract the data ownership and portability terms, the service level agreements and the vendor’s security certifications. These are clauses that are seldom read when signing and much regretted when leaving.