Bespoke vs SaaS Is No Longer the Old Trade-Off

For a long time, the enterprise software decision looked fairly simple.

If you wanted speed, predictability, and a familiar operating model, you bought SaaS. If you wanted something tailored to how your business actually worked, you commissioned a bespoke build and accepted the usual trade-offs: more time, more cost, more complexity, and more governance overhead.

That framing is now changing.

I am writing this article now for three reasons:

• First, the market signals are becoming too consistent to ignore.
• Second, the underlying technology has shifted in a way that makes modular, governed bespoke delivery far more practical than it used to be.
• Third, our own experience at Gysho has shown that this is no longer a theoretical debate. It is an operating reality.

This does not mean every organisation should rush to build everything itself. It means the old assumption that SaaS equals speed and bespoke equals pain is no longer a reliable way to think about digital enablement.

The real question now is more precise:

> What should be standardised, and what should be differentiated?

That is the conversation I think more firms need to have.

The market is changing the terms of the debate

The strongest reason to revisit the bespoke-versus-SaaS question is not opinion. It is the direction of travel coming from the analyst market.

Taken together, Gartner, Forrester, and IDC are pointing to the same shift: enterprise software is becoming more agentic, more modular, and more process-centric.

Here are the relevant signals:

• Gartner predicted in August 2025 that 40% of enterprise applications will feature task-specific AI agents by 2026, up from less than 5% in 2025.
• Forrester said enterprise software is shifting from user-centric design to worker- and process-centric design.
• Forrester predicted 30% of enterprise app vendors will launch their own MCP servers.
• Forrester also predicted that half of enterprise ERP vendors will launch autonomous governance modules combining explainable AI, automated audit trails, and real-time compliance monitoring.
• IDC predicted that by 2029, 30% of global IT services will be delivered as modular, platform-enabled products.
• IDC also predicted that by 2029, 30% of contractual engagements with service providers will be outcome-based, driven by agentic AI.

Those statements matter for three reasons.

A. Software is moving closer to the workflow

The old software model was often screen-based and user-based. The new model is increasingly process-based

That matters because many businesses do not actually win through generic screens or generic features. They win through the way they structure work, make decisions, apply judgement, and govern outcomes.

When software becomes more process-centric, it becomes easier to design around a real operating model rather than forcing the operating model to fit the application.

B. Modularity changes what “bespoke” means

If a meaningful share of IT services is moving towards modular, platform-enabled delivery, bespoke no longer has to mean building everything from zero.

It can mean assembling proven building blocks into something tailored, governed, and commercially useful.

That is a very different proposition from the traditional image of a long custom build programme.

C. Governance is becoming part of the product

One of the historic objections to bespoke systems has been governance risk.

That concern does not disappear. But the market is showing that governance is becoming a core design requirement across enterprise software, not a separate compliance afterthought.

> The market is not moving away from governance. It is moving towards governance by design.

That changes the quality of the conversation. The question is no longer just whether a system is custom or packaged. The question is whether it can operate safely, transparently, and effectively inside the real business environment.

2. Our own experience showed us where SaaS stopped working

The move from SaaS to modular and bespoke is not just an external market story for us. Some of Gysho’s technologies exists because off-the-shelf AI and software platforms could not do what we needed them to do in practice.

It is a critical proof point of how it works in practice, both from a functional perspective and as a feasibility study.

HubSpot is a great starting platform, but hits a pricing cliff when stretched and Breeze was not not reading its own data. Microsoft Project and SharePoint required specialists to operate and would not pick up a plain email. Off-the-shelf AI assistants indexed file names instead of contents.

All these tools are traditionally good SaaS solutions, but once we started pushing our own ambitions to perfect our processes, they did not fit our needs any longer. The inflexibility meant we could not adapt their operation to our way of working and agents had limited success.

> Standard software works well until the workflow matters more than the tool.

That was the point at which configuration stopped being enough. So we built differently.

Gysho built a composable platform: a modular stack of 25 reusable backend services and application shells that can be assembled into unique client applications in days rather than months.

That platform model matters because it changes what bespoke can look like. It means the application can be tailored to the workflow, while the underlying infrastructure remains reusable, governed, and scalable.

A practical example: why we replaced HubSpot

One of the clearest examples is our own CRM. We built a bespoke CRM as a replacement for HubSpot in approximately three days.

It includes:

• automatic transcript ingestion
• meeting summarisation
• action-item extraction
• follow-up email drafting
• sentiment analysis
• merged stakeholder briefs
• a live decisions-and-risks log

This system replaces HubSpot’s core CRM behaviour, but it is configured precisely to Gysho’s preferred way of working - we value efficiency and want AI to flag important actions to us, instead of having to log every interaction and go into the CRM to determine what we need to do.

We did not replace HubSpot because bespoke is inherently better. We replaced it because the off-the-shelf route was not supporting the way we actually worked, and because an AI-first, agentic-ready system was more useful in practice.

We now run our commercial operations, internal project management and customer intelligence on the same platform we sell to clients. In other words, we use the model ourselves. We “eat our own cooking”.

SocialOS is another example. It is Gysho’s social-selling and commercial-signal intelligence application, built because HubSpot and its peers could not offer that capability at any price.

That is an important point to make carefully: this is our lived operational example, not a claim that every company should replicate it exactly. But it does demonstrate something useful.

When the workflow is strategically important, and the market tools cannot support it properly, a bespoke route no longer has to be slow, expensive, or impractical.

3. Why bespoke is becoming easier — and more valuable — in a commoditised market

This is where I think the discussion gets more commercially interesting. The case for bespoke is not that everything should become custom. The case is that in a commoditised market, firms need to be much more deliberate about what they standardise and what they protect as distinctive.

There are three reasons bespoke is becoming both easier to achieve and more strategically useful.

A. The plumbing can now be reused

Modern bespoke does not need to start from a blank page. Reusable components can now handle a large share of the foundational work:

• orchestration
• connectors
• workflow controls
• security patterns
• monitoring
• deployment support

That means the bespoke layer can focus on what actually creates value:

• proprietary frameworks
• decision logic
• review workflows
• governance rules
• firm-specific data structures
• client-facing operating flows

This is the practical shift: custom at the value layer and reusable at the infrastructure layer. That is why bespoke is easier to achieve now than it used to be.

B. Differentiation is moving away from generic tooling

In many sectors, the base technology is becoming more available and more similar. That is not a problem for end users. In fact, it is helpful since technologies are more likely to integrate and there is more choice, making them a commodity which should be treated as such.

The strategic question is whether a firm’s distinctive expertise is being flattened into generic software in the process. That matters especially for consulting, advisory, and research firms.

Their value is often built on:

• proprietary frameworks
• structured methods
• specialist taxonomies
• repeatable decision processes
• experience-based judgement
• governed review models

If those assets stay trapped in documents, spreadsheets, project teams, and institutional memory, they are harder to scale, harder to protect, and harder to apply consistently. A bespoke product can help operationalise that IP without forcing it into a generic system that weakens it.

That is the logic behind our own offer.

We help consulting, advisory, and research firms embed differentiated IP into secure, governed agentic products, starting with a rapid, outcome-driven 5–7 day proof of concept and scaling through subscription-based continuous improvement.

C. Bespoke supports a better balance of trust, governance, and agility

One of the biggest misconceptions in this space is that bespoke and governance pull in opposite directions. They do not have to.

A well-designed bespoke model can create stronger control over:

• where human review is required
• how outputs are explained
• which sources are authoritative
• how audit trails are maintained
• how confidentiality boundaries are enforced
• how the workflow connects to the wider busines

Governance is part of the operational design of a system, which matters even more in an agentic environment or system.

> Do not customise commodity. Differentiate where your business actually wins.

This is also why I think the “build or buy” question is increasingly the wrong one.

The better questions are:

• What is truly commodity in our operating model?
• What is truly differentiating?
• How do we govern both properly?

Those questions lead to better decisions than a default assumption that buying packaged software is always safer, faster, or more commercially rationale.

Sometimes it is. Sometimes it is not.

Conclusion: standardise what is common, build where it matters

The old bespoke-versus-SaaS debate was built for a market that looked different.

Today, applications are becoming more agentic. Services are becoming more modular. Governance is becoming embedded. And the real competitive advantage is moving away from generic tooling and towards the way firms structure work, apply expertise, and turn knowledge into repeatable outcomes.

That is why I think the decision needs reframing. Not as a binary choice between custom and packaged software. But as a more disciplined question of standardise versus differentiate.

From our own experience at Gysho, the lesson is straightforward. Off-the-shelf tools are useful until they stop fitting the workflow, the governance model, or the intelligence the business actually needs. When that happens, a composable bespoke approach can now be a credible option in a way it simply was not for many firms a few years ago.

That does not mean customising everything.

It means being clear about three things:

• what is common
• what is core
• what must be governed

If firms get that right, the choice becomes much clearer.

• Standardise what is common.
• Protect what is core.
• Govern both properly.