De soluciones puntuales al pensamiento plataforma

At some point in every growing company's life, someone opens a spreadsheet and tries to list all the software the business pays for. They get to about row 30, feel a creeping sense of dread, and close the spreadsheet without finishing.

According to Productiv's 2023 State of SaaS report, the average mid-market company uses 254 SaaS applications.^[1] Two hundred and fifty-four. If that number doesn't make you feel slightly unwell, you probably work at one of the companies selling those applications.

This article is about how we think about that problem at Ascentra, and (honestly) about some of the mistakes we've made along the way in figuring it out.

The "Tool Per Problem" Trap

It always starts sensibly. You need to send emails, so you get an email tool. You need to send SMS, so you get an SMS gateway. You need analytics, so you plug in an analytics platform. You need to manage customer data, so you get a CRM. You need to track who consented to what, so you build a spreadsheet. Sorry, a "consent management solution."

Each decision is rational in isolation. The email tool is best-in-class for email. The SMS gateway has the best delivery rates. The analytics platform has gorgeous dashboards. Nobody made a bad decision.

And yet, somehow, eighteen months later, your "technology stack" looks less like a stack and more like a drawer full of cables that have become mysteriously tangled despite nobody ever touching them.

The core issue isn't that individual tools are bad. It's that the spaces between tools are where things break. A customer updates their email preference in your CRM, but that change doesn't propagate to the email platform until the nightly sync. An SMS goes out at 2am because the scheduling tool doesn't know about the timezone data in the customer database. A compliance audit requires pulling consent records from four different systems, and they don't agree.

These aren't edge cases. These are Tuesday.

What Platform Thinking Actually Means

Let's be honest about what "platform" has become in the SaaS world: a word that companies slap on their marketing site the moment they add a second feature. We're aware of the irony of using it ourselves, so let us be specific about what we mean.

Platform thinking, as we practice it, means: building products that share foundational infrastructure, data models, and design principles, so they work together as naturally as features within a single application.

It does not mean "we do everything." We're quite firm about that. We don't build accounting software. We don't build project management tools. We don't build CRMs. We build communication and orchestration products for organisations that need to reach people reliably, across channels, at scale. That's the boundary.

What it does mean is that within our domain, a customer shouldn't have to think about integration. When our orchestration engine decides to fall back from RCS to SMS, it shouldn't need to call a different API, check a different consent store, or format the message differently. Those concerns are handled at the platform level, invisibly.

The Integration Tax

Here's a number that rarely appears in SaaS procurement evaluations: the cost of maintaining integrations between tools.

MuleSoft's 2023 Connectivity Benchmark Report found that the average enterprise spends $4.7 million per year on custom integration work.^[2] That's not the cost of the tools themselves; that's just the cost of making them talk to each other.

The integration tax goes beyond money, though. It's paid in:

• Time: engineering hours spent building, maintaining, and debugging connections between systems that weren't designed to work together
• Reliability: every integration point is a potential failure point, and failure modes multiply when you chain integrations together
• Data quality: when customer data lives in five systems with five different update cadences, the question isn't whether they'll disagree, but when
• Agility: want to change your email provider? Good luck untangling it from the fourteen other systems it's connected to
• Cognitive load: your team has to understand not just each tool, but the interaction patterns between them, the sync schedules, the error handling, the data mapping

When someone evaluates a £5,000/month point solution against a £7,000/month platform, the point solution looks cheaper. But that comparison ignores the £3,000/month you'll spend integrating and maintaining the point solution alongside everything else. Total cost of ownership is the metric that matters, and it almost always favours fewer, more integrated systems.

The Boring Stuff That Makes Platforms Work

The exciting parts of platform building (the features, the UI, the clever orchestration logic) get all the attention. But the parts that actually make a platform a platform are deeply, almost aggressively boring.

Shared data models

When every product on the platform agrees on what a "customer" is, what a "message" is, what a "consent record" looks like, you eliminate an entire category of bugs. No mapping layers, no transformation logic, no "well, in System A that field is called 'mobile' but in System B it's 'phone_cell'." One model. Everywhere.

Shared authentication and authorisation

One login. One set of roles. One audit trail. If an admin revokes a user's access to sensitive customer data, that takes effect across every product instantly. Not "after the next sync." Not "in most places." Everywhere, immediately.

Shared observability

When something goes wrong (and things always go wrong) you need to trace what happened across the entire system, not dig through logs from six different products with six different logging formats and six different timestamp conventions. (Yes, we have seen systems where different components used different timezones in their logs. No, debugging those incidents was not fun.)

Shared design language

If a user knows how to configure a journey in one product, they should have a reasonable intuition for how to configure a journey in another. Consistency reduces training time, reduces errors, and frankly shows that you care about the experience enough to invest in cohesion.

Where Custom Solutions Fit In

We're sometimes asked why we offer custom solutions alongside our products. Doesn't that undermine the platform story? Actually, we think it strengthens it.

The build-vs-buy spectrum isn't binary. In practice, most organisations need a mix: buy the 80% that's common across the industry, and build the 20% that makes you different. The platform approach means that the custom 20% can be built on the same foundation as the off-the-shelf 80%: same data models, same APIs, same deployment infrastructure, same monitoring.

A custom solution built on our platform isn't a separate island. It's a first-class citizen with access to every capability the platform provides. That's a meaningfully different proposition from "we'll also build you some bespoke software on the side."

The Best Platforms Feel Invisible

This is something we think about a lot. The best infrastructure disappears. You don't think about electricity until it goes out. You don't think about plumbing until something backs up. (Sorry for that image.)

A communication platform should work the same way. The end users (the people receiving the messages) should never think about the platform at all. They should just get the right message, at the right time, through the right channel. The operators (the teams configuring journeys and managing campaigns) should think about what they want to achieve, not about how the system works under the hood.

If a customer has to understand your architecture to use your product, you've failed at the product level no matter how elegant the architecture is.

This is our north star, and we're not there yet. We're honest about that. There are still rough edges, places where the platform seams show, configurations that require more technical knowledge than they should. We're working on it. The goal is for Ascentra to feel less like "a platform with several products" and more like "a single, coherent tool that does everything I need for customer communication."

What We've Learned (The Honest Version)

Since this is a company article and not a whitepaper, let us be real for a moment.

Platform thinking is easy to talk about and hard to do. We've made our share of mistakes. We've built features that were tightly coupled when they should have been modular. We've shipped shared components that weren't quite ready and caused problems across multiple products simultaneously. That is, of course, the dark side of shared infrastructure. When your foundation has a bug, everything built on it has that bug.

We've also learned that the temptation to expand scope is constant. "If we just added a CRM feature..." No. Knowing what you don't build is as important as knowing what you do. Every time we've been tempted to wander outside our domain, we've reminded ourselves that the value of a platform comes from depth in a focused area, not breadth across everything.

The other lesson that's taken us a while to internalise: customers don't care about your platform. They care about their problems. Nobody wakes up thinking "I wish I had a better platform." They think "I wish I could send my customers appointment reminders without it taking three weeks to set up." If the platform helps us solve that problem faster and more reliably, great. But the moment we start talking about architecture instead of outcomes, we've lost the plot.

Looking Forward

We're still early in this journey, which is a strange thing to say given that we've been at it for a while now. But the gap between where we are and where we want to be remains humbling. Every customer conversation teaches us something new about what the platform needs to do, and every engineering sprint surfaces another area where our shared infrastructure could be better.

What we're not going to do is pretend we've figured it all out. The companies that claim to have a "complete platform" for anything are either lying or defining "complete" very generously. We'd rather be honest about what works, what's still in progress, and what we're actively wrestling with.

Because at the end of the day, a platform isn't a destination. It's a decision: a decision to invest in shared foundations rather than quick fixes, in long-term coherence rather than short-term convenience. Some days that decision feels brilliant. Other days, when you're debugging a shared component at 11pm because it's affecting three products simultaneously, it feels somewhat less brilliant.

But we'd make the same decision again. And we think, if you're building software that needs to grow beyond a single product, you probably should too.