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:
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 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:
Those statements matter for three reasons.
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.
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.
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.
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.
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:
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.
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.
Modern bespoke does not need to start from a blank page. Reusable components can now handle a large share of the foundational work:
That means the bespoke layer can focus on what actually creates value:
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.
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:
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.
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:
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:
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:
If firms get that right, the choice becomes much clearer.