You don't need to understand how your car engine works to know that buying one without a standard fuel cap - one that only accepts fuel from a single, proprietary pump - would be a terrible decision. You'd be locked into one supplier forever. And if that supplier stopped operating, raised their prices, or simply couldn't keep up with what you needed, you'd be stuck with a very expensive piece of metal that couldn't go anywhere.
That's roughly what happens when you approve a platform investment without asking whether it's API-first. Except it's worse, because at least with the car you'd notice the problem at the forecourt. With digital platforms, you might not notice for two or three years - by which point you've built your operations around something that can't connect to anything else.
I realise I've already used a term that might mean nothing to you. Let me fix that.
An API - application programming interface, though you never need to remember that - is a way for two software systems to share information automatically, without a human manually moving the data between them.
Here's the most concrete example I can give you. When a prospect fills in the contact form on your website and their details appear in your CRM without anyone copying them across - that's an API at work. The website sends the information to the CRM. The CRM receives it. Nobody had to open two browser tabs and retype a phone number.
When it doesn't happen automatically - when someone in the office is downloading a spreadsheet from the website every morning and uploading it into the CRM - that's the absence of an API. And someone on your team is doing a computer's job.
I was in a meeting with a COO about eighteen months ago, and she squinted at me and said: "So it's basically a pipe between two things?" Yes. It's a pipe. A standardised, well-documented pipe that lets information flow in both directions. Some pipes are wide and fast. Some are narrow and slow. Some platforms have lots of pipes available. Some have almost none. And some vendors will tell you they have pipes when what they actually have is a garden hose held together with tape.
But the principle is that simple.
Knowing what an API is gets you halfway. The other half is understanding what people mean when they say a platform is "API-first" - because this is where it starts to matter commercially.
A platform built API-first was designed from the very beginning to share its data with other systems. To send information out, receive information in, and allow other tools to trigger actions within it. The architects who built it assumed from day one that it would need to talk to other software - your CRM, your email marketing tool, your client portal, whatever comes next.
A platform that is not API-first was designed to do everything itself, inside its own walls. It might have an API bolted on later, like an afterthought, but it wasn't built around that principle. And the difference matters more than most vendors will admit.
Think of it this way. An API-first platform is like a building designed with standardised electrical sockets in every room - you can plug anything in. A non-API-first platform is like a building where the electricity is wired directly into the light fittings. If you want to add a new lamp, you need an electrician to open up the wall.
The business consequence is straightforward: an API-first platform can be connected to your CRM, your client portal, your marketing tools, and any new tool you adopt in three years' time. A non-API-first platform either can't, or can only at significant custom development cost - the digital equivalent of calling the electrician every time you want to plug in a kettle.
I'll leave the technical architecture decisions to the IT team. That's what I pay them for.
I hear this constantly. And I get it - you didn't get to managing partner by learning about software architecture. But "is this platform API-first?" is a commercial question dressed in technical clothing. It has direct consequences for three things you absolutely do care about.
Flexibility. Your firm's digital requirements will change. They always do. You might switch CRM providers, add a client portal, adopt an AI tool, or acquire another firm and need to integrate their systems with yours. If your platform is API-first, each of those changes is a connection exercise - plug the new thing in, configure it, move on. If it isn't, each of those changes is potentially a rebuild.
I worked with a firm a while back - about 200 people, professional services - who wanted to connect their website to a new business development tool their partners had chosen. The platform they were on had been sold to them five years earlier as "modern" and "integrated." Turned out the API documentation was three pages long and hadn't been updated since 2019. The integration that should have taken two weeks took four months and cost nearly £80,000 in custom development. And even then, it was fragile - kept breaking whenever the vendor pushed an update, which nobody had warned them about. They're now looking at replacing the entire platform. Which is exactly the outcome an API-first choice would have prevented, and honestly, it's the kind of thing that makes me want to go back in time and sit in on the original procurement meeting.
Connected data. If you've ever been frustrated by the inability to see a single, joined-up view of a client's interactions with your firm - their website visits, their enquiry history, their event attendance, their portal usage - that frustration isn't primarily a data problem. It's an integration problem. The data exists. It's just locked inside separate systems that can't talk to each other. Without API connections, you're relying on people to manually stitch together information from three or four different tools, which means it either doesn't happen or happens inconsistently.
Future-proofing. And I know that sounds like consultant-speak, so let me be specific. The digital tools that will be most valuable to your firm in three years probably haven't been selected yet. Maybe they haven't been built yet. An API-first platform can connect to them when they arrive. A closed platform might not be able to - and you won't know until you try, by which point you've already committed and the switching cost is eye-watering.
Integration capability isn't just one criterion among many when you're evaluating platforms. It's the criterion that determines whether the platform grows with your firm or starts depreciating the moment it's installed.
Here's the thing that catches people out. If you ask a platform vendor "does your platform have an API?", they will almost always say yes. Because technically, almost everything has some kind of API these days. It's a bit like asking an estate agent if a house has a garden - they'll say yes even if it's a two-foot concrete strip behind the kitchen.
The question isn't whether an API exists. It's whether it's well-documented, widely supported, actively maintained, and capable of doing what you'll actually need it to do. That's harder to assess from a sales deck.
I've seen firms buy platforms on the basis of a "yes, we have an API" answer that turned out to mean "we have a basic read-only API that lets you pull data out but can't push anything back in, and the documentation was last updated in 2021." That's not API-first. That's API-as-marketing-checkbox.
So when you're choosing between two platforms that seem comparable in other respects - features, cost, editorial experience - the one with a well-documented, widely-supported API is the more future-proof choice. Not because you'll use the API immediately. You might not. But because its presence means the option to connect remains open. Its absence closes that option, permanently, unless you replace the platform entirely.
Right. This is the bit I actually want you to take into your next meeting. These aren't technical questions - they're commercial questions that happen to be about technology. Any managing partner can ask them, and your IT team or agency should be able to answer them clearly. If they can't, that tells you something important.
"If we wanted to connect this platform to a different CRM in two years, what would that involve?"
This is the flexibility test. The answer you want to hear is something like: "We'd configure a new integration using the platform's API - probably a few days of work." The answer that should worry you is: "We'd need to scope a custom development project." If connecting to a different CRM requires a custom project, you're on a locked platform.
"What happens to our data if we decide to move to a different platform in five years - can we get it out easily?"
Data portability is one of those things nobody thinks about until it's too late. If the answer is vague - "we'd need to work with the vendor on that" - be concerned. Your data should be yours, exportable in standard formats, without needing the vendor's co-operation or a six-figure migration project.
"What integrations are working today, and how long did each one take to build?"
Honestly, this is the one I'd lead with if I only had thirty seconds. It reveals the real-world complexity of integration on this specific platform. If your team has three integrations live and each took six months, that's very different from three integrations that took a week each. The time it takes to build integrations is the best proxy for how genuinely open the architecture actually is.
"Which of our current tools connect to this platform out of the box, and which would need custom development?"
Out-of-the-box integrations - the ones that come pre-built and just need configuring - are dramatically cheaper and more reliable than custom-built ones. If most of your key tools require custom integration work, the total cost of ownership is going to be considerably higher than the platform licence fee suggests.
"How would we add an AI tool to this platform if we wanted to in eighteen months?"
This is the forward-looking question, and it's the one that separates a platform that will serve you for the next five years from one that'll start feeling restrictive in two. AI tools are coming whether you're planning for them or not. If your platform can't accommodate them without a major rebuild, you're buying something that's already ageing.
I'm not suggesting you need to understand API architecture, start attending technical review meetings, or second-guess your IT team's recommendations. They know more about this than you do, and they should.
But there's a difference between delegating a decision and abdicating it. When the platform recommendation lands on your desk - and it will, because these investments are significant enough to require sign-off - you need to know whether you're approving something that will adapt as your firm grows, or something that'll need replacing the next time your requirements change.
I was chatting with a CTO at a 300-person professional services firm a few months ago. He'd just had his platform recommendation approved by the board without a single question about integration. "They approved it in eleven minutes," he told me, with this sort of weary resignation. "Nobody asked how it connects to anything." He wasn't happy about it. He knew the gaps were there, but raising integration architecture with a board that wants to talk about revenue growth is, well, a hard sell. He'd have loved someone on the other side of the table to ask.
The five questions above give you that. They're not technical questions - they're the commercial questions that the technical recommendation should already have answered. If it hasn't, send it back and ask. Your IT team won't mind. In fact, the good ones will be relieved.
Regardless of who's championing which platform, or which vendor gave the best demo, or which option is cheapest in year one, the integration architecture is what determines whether that investment compounds or depreciates over time.
A platform that connects to your CRM, your portal, your marketing tools, and whatever you adopt next year gets more valuable as your ecosystem grows. A platform that can't connect to anything is a sunk cost that gets more expensive to maintain and eventually more expensive to replace.
And the maddening thing is that both platforms might look identical in a demo. Same features. Same editorial interface. Same price. The difference is invisible until you need it - and by then, you've already committed.
So ask the questions. Not because you don't trust your IT team, but because this particular decision has consequences that extend well beyond IT. It affects your ability to change tools, connect data, serve clients, and respond to opportunities that don't exist yet.
If you want to understand how your firm's current platform estate is connected - and where the integration gaps are creating commercial cost - book an integration architecture review with us. We'll map what's talking to what, what isn't, and what it's costing you.