Welcome to episode eight of the SaaS Backwards podcast, where we interview CEOs and CMOs of fast-growing SaaS firms to reveal what they are doing that's working, and lessons learned from things that didn't work as planned. 

You can listen to the full episode directly below via Spotify, or visit SaaS Backwards on Buzzsprout or wherever you listen to podcasts.

Cyclr CEO on How his Integration Platform as a Service Creates Connectivity and Opportunity for other SaaS Firms

Fraser Davidson, CEO, Cyclr

Edited for clarity and readability 

Host, Ken Lempit:
Welcome to SaaS Backwards, a podcast that helps SaaS CMOs and CEOs to accelerate growth and enhance profitability. We take a look at what's working for growing SaaS companies, what didn't work, and why. Our guest today is Fraser Davidson. Today we'll be talking about his integration SaaS called Cyclr. Hey, Fraser, welcome to the podcast.

Fraser Davidson:
Hi, Ken. Good to speak to you.

Ken Lempit:
Thanks so much for joining us. Before we dig in, I always like to get a little bit of background on our guests, so if you could tell us about yourself and your company, that would be great.

Fraser Davidson:
My name is Fraser Davidson and I'm CEO of Cyclr. I’m at the slightly older end of the spectrum for founders--I'm in my mid-40s--and in fact my co-founder is mid-60s as well, so we are at the elderly end of the founding spectrum and proud. You can hear from my accent I am Scottish by background.

I did my initial degree in marketing and French, spent a brief amount of time in private equity, in venture capital investing, and then a number of years with early-stage startups, and I find myself now as CEO of Cyclr.

Cyclr is an integration platform provider, but specifically what we call an embedded integration platform provider, and I'm sure we'll show we'll talk about that because it means that we provide a toolkit to other software companies to help them create, manage and deliver integrations rapidly from within their own software. So we've been called white label in the past, we've been called OEM solutions in the past. In truth, what we are is a very sophisticated toolkit to ease that process of working with integrations.

Ken Lempit:
Awesome. And when we talked before, you gave me insight into the founding of this company and how you guys came together. And I think that's worth talking about, especially for people that are looking for their next thing, having an open mind about what they're going to do next. Might be interesting just to illuminate your founding story and how you met your partner?

Fraser Davidson:
Yeah, absolutely. So my co-founder is a chap called Philip Bryan, and we have very different backgrounds that collided about five, six years ago. My background, I was mentioning just earlier there, was I came really from the private equity background of investing in software companies. So I invested in my first SaaS business back in 2006, 2007, and really fell in love with that business model at that point in time, the appeals of the subscription-based business model, the efficiency of what you could achieve with SaaS companies.

I then worked on the board of a number of SaaS companies for over 12 years, working with a series of entrepreneurs who were founding SaaS businesses, giving them counsel, giving them advice, rolling up my sleeves. And back in 2006, 2007, when I got started, you could build a SaaS company that stood alone as a powerful standalone piece of software that beat the traditional software applications that were in the market at that point in time. And it did one thing and it did that one thing very well, and that's all it needed to do for someone to buy your software.

What I was seeing as I was getting involved in more and more SaaS was fundamentally that there were more and more SaaS businesses, and interoperability was becoming key. The drivers back in the day in 2006/7 to buying SaaS was that people were using ERP systems that were Jack of all things but master of none, so they were wanting things that were highly powerful and highly focused.

As time has passed, actually the things I saw were beginning to swing back round to that, because people were finding they had a plethora of highly focused pieces of SaaS software, and they were yearning for that opportunity to bring them back together in a collaborative fashion to work effectively as a new generation of ERP system, but one where you could pick the software applications that you wanted to work with, join them up and make it coherent.

Now, Philip's journey's different. His background is actually in ERP systems way back in the day, so he'd been a programmer. He's been a developer for a long time. Philip has also founded a number of software businesses himself over the years. And one of his latest founding companies was a business called Sentori, which is an email marketing business.

And so early 2010, 2012 time-period, Philip was at the coalface of receiving integration requests, because if you own and manage an email marketing software platform, you are going to be inundated with requests for people wanting CRM integrations or other marketing automation integrations into your platform.

Now, Philip's view on the world is that he likes to make things as simple as possible and to eliminate repetition from what he does. So he had this idea of, well, rather than tackling these integrations on a case-by-case basis, as my clients ask me for them, why not build a toolkit that can make my whole process and methodology easier? And so that was the genesis of the idea that became Cyclr.

And what Philip then realized was that actually the problem that he was facing at the coalfaces of an email marketing software provider back in 2010, 2012, was a problem that was currently being faced by other SaaS companies or would certainly be faced by different types of SaaS companies in the future.

So Philip was looking to spin Cyclr out and stand up as an independent business. We got introduced by a mutual contact and we got on well. We'd approached the problem from different directions. My background is definitively commercial, financial, strategic. Philip's background is technical, understanding, development. And between the two of us, we realized that we could build something quite exciting.

Ken Lempit:
So you had a real organic start to the business, really within another business. So the pain was real, it wasn't imagined. I think a lot of times, people imagine they have a solution, but really they've got a solution that's looking for the problem. In this case, we have a real problem that was begging for a solution. That's kind of a nice place to start.

Fraser Davidson:
Yeah, you're spot on, Ken. I mean, Philip had identified a problem he was facing right there, right then. So he was living and breathing that problem, and he had just worked out a very clever way to resolve that problem.

Ken Lempit:
That's awesome. So I guess I want to talk to you about how you decided as a business strategy to go to other software firms versus the users of the software. And having watched the cloud business, along the same time scales as you have, start out as this single-purpose apps, the promise of the cloud always was that the data would move freely, so you had to find a way to make good on that promise. But what made you target the other software firms versus the more public-facing, more exciting if you will, branded software?

Fraser Davidson:
Yeah, there's certainly a lot of well-known names out there in the market, the Zapiers of the world, the Boomis, the MuleSofts, the Jitterbits, who do that very, very well. And that traditional past market of targeting the end user, and an end user can be an individual or an end user can be an organization as well, it was very well established.

Why we decided to go for the software end of the spectrum was the genesis of the business really, is that's where the idea came from, was being in a software company, feeling that pain, seeing the problem, and realizing that always handing off your customer to a third party wasn't always the best thing to do from a customer relationship and customer success perspective.

I mean, these traditional iPaaSs (Integration Platform as a Service) are phenomenal, and they work incredibly well, and an embedded iPaaS doesn't replace them. But in most circumstances, you don't want to be handing off your customer to a third party to resolve their integration needs. You want to be resolving those yourself.

So when we looked at it, we realized that nobody was really looking and addressing that problem from the software vendors' perspective. There were no other embedded iPaaSs out there offering that kind of functionality. And when we thought about it not just from a technical perspective but also from that commercial perspective of customer experience, we realized we're onto something interesting.

Now, that's not to say we haven't dabbled in or experimented with the idea of going to end users. And we do go to end users. The end users come through the front door. If they can identify that Cyclr is a product that will work for them as an end user, we definitively do not turn them away. We will work with them. And there are definitely things like marketing services organizations or sophisticated enterprises that have a CTO but maybe don't develop software, who see the appeal in using an embedded iPaaS and having that control. So we love end users and we go after them.

Ken Lempit:
You may remember that's how we met. We were looking to do a moderately complex integration between three pieces of software for one of our clients, and came upon Cyclr and realized that you guys would be a truly elegant solution, not only for us to implement but, because of the way the tool works, for the client to be able to maintain it on their own.

Fraser Davidson:
Yeah. You're spot on, Ken. And you guys have done an amazing job with it as well, because the type of people we're appealing to are those that are technically literate, technically competent, understand what they're wanting to do, and want to have a powerful toolkit that they can then administer on behalf of themselves or on behalf of their client, because Cyclr is positioned in that way.

We don't have a managed service wrapper around what we do. We provide you or any organization with a box of LEGO bricks, and it's amazing what people can build with LEGO bricks. Clever people can build very clever stuff with small component parts.

Ken Lempit:
When we prepped for the call today, we talked about three kinds of integration: those that are within the company that are core to the function, the commercially relevant integrations, and then the real edge cases. And I'm wondering if you could talk about that, because I thought that was illuminating.

Fraser Davidson:
Yeah, by all means. When we're chatting to CTOs or even CEOs or anybody within a software organization, we try to be very clear that you're really looking to have an integration strategy. You should look at all of the various integrations that you can have as a SaaS company, and then almost put them into buckets.

Now, I could sit here today and pitch you and say, "You should use an embedded iPaaS for everything," and technically you could use an embedded iPaaS for everything, but it might not necessarily be the most sensible thing to do.

And the way I look at it and talk to the CTOs about it, I see that there are three buckets. There's functioning critical integrations, there are commercially critical integrations, and then there's the long-tail integrations that you're not quite sure about yet. And I think you should really have a strategy for each of those.

Functionally critical, for me, are integrations that are critical to the performance of your platform. So an example I often use is if you're developing a diary-booking platform, you really need to own natively and direct yourself all of the various calendar integrations, because your diary-booking platform is critically dependent upon that integration to the calendar booking. So every function, everything your diary-calendar booking does, is reliant upon the integration. So you really should be thinking, "I should own those natively, I should develop them myself, and they should be under my control."

The next bucket, then, is what we call commercially critical. Now, these are the integrations that are not functionally critical to your platform but are absolutely critical to sales success and performance. So when you speak to your customers, they say, "Ken, I love your software, but does it integrate Salesforce?" or, "I love your software, does it integrate to NetSuite?" or whatever it might be thereafter.

Now, these are the things on which commercial conversations swing. If you have it, if you don't have it, will you win the business or will you be leaving MRR (Monthly Recurring Revenue) on the table because somebody else has that integration?

Now, commercial integration is the heart of where I think an embedded iPaaS should preside. That's the area where you want to be agile, you want to be quick. It's key to commercial success, and therefore you want to have a platform that can be worked on by your developers but can also maybe be worked on by your customer success team or your commercial team, and you can get those to market quickly.

Then you have the long tail. Now the long tail, for me, are the ones which are the nice-to-have integrations. So maybe they're the less valuable integrations, not from the platform itself isn't valuable, but because you've got a small number of customers using it or low-value customers using them, or they're just ones that aren't really commonplace in terms of what's requested.

Now, you could put of those into an embedded iPaaS if you want to. But that's the point really where you might begin thinking of offering your client your API or pointing them to the Zapiers of the world and saying, "Why don't you serve yourself?" until such point as the volume of requests for those integrations are high enough that you think you should then bring them into that commercially critical bucket.

Ken Lempit:
So, if you're going to promote them to be commercially critical, then you'd have to pay attention to what's going on with the Zapiers of the world, right? You have to have some sense of what's going on with your customers.

Fraser Davidson:
I think that's it, actually, Ken. You need to pay attention to what's going on with your customers more than what's going on with the Zapiers of the world, because we see in our client base that every single software company uses a different basket of integrations, and what's critical to one SaaS company is not necessarily critical to the next one. Not every one of our clients wants to integrate with Salesforce, for example. Some would say that's critical, some would say that's non-critical.

So really, it's about understanding your client based on what their needs are, and then determining your strategy off the back of that. The thing that none of us ever do is say yes to everybody, right? You assess the value of it to you as an organization, and then you decide, is that something you want to offer within your platform, or is that something that you maybe get the client to resolve in a different way?

Ken Lempit:
It's interesting as we look at SaaS software for our own business or for our clients. Ever since we had our first conversations leading up to today, I look at their integrations list, and it's the ones with small numbers of integrations, I almost feel like they're at risk. If you don't have enough integrations available, you do potentially leave a lot of revenue on the table, right?

Fraser Davidson:
Yeah. Look, I agree but only to point to on that, actually, because again, different flavors of SaaS platform require a different number of integrations to meet the needs of their client base. So if you're in the marketing arena, you need a lot of integrations, because there're a lot of powerful marketing platforms out there that your clients are inevitably using. If however you're perhaps in the project management arena as a software company, you may not need that many integrations, really, to meet the needs of your customers, because there's a lot higher concentration in that market of platform providers.

So again, it comes down to that balance, that kind of common-sense approach of what makes sense to you rather than what everybody tells you should be doing. And we have customers that have a small number of connections and a high volume of customers, but equally at the other end, we have ones who have a high volume of connections and a low volume of customers. And it's not that one that right and one is wrong. It's just that they're both thinking about integration from the perspective of what's valuable to them.

Ken Lempit:
Awesome. Well, as we're talking about customers, maybe you could give us a simple case study of how you've helped one of your clients recently that will illuminate the value of working with an iPaaS.

Fraser Davidson:
Yeah, absolutely. We've got a great customer in the US called Drive Social Media, and they're an interesting combination of being a software company in the services business, and they operate in that marketing arena. So actually they're quite a high-consumption user of Cyclr in itself. And what Drive Social Media do is they're working with their clients really to optimize data flows to help their customers understand the marketing data they receive on a day-to-day basis.

And the example they've always given me is they work with, for example, a gym chain, and somebody walks into that gymnasium, signs up for a new subscription. Now, if you looked at things very simply, you would call that person a walk-in, and call it an offline acquisition of a customer.

However, with some sophisticated analytics that Drive Social Media help the client understand, they can look back through Facebook records and social media records and web interactions, and try and cross-reference that individual's data with interactions they've had in the past. And where they get a match, they can then say, "Well, that walk-in actually was not an offline transaction but was triggered by some online activity," be that advertising, be that social media, where they get a tick in the box.

Drive Social Media are incredibly good at doing that, and they do it both on a services basis, joining up the flows between the Facebooks of the world and that kind of thing, and equally joining up that data into their own software platform called Marketing Milk. So Drive Social Media manage an ecosystem of thousands of workflows across about 40 to 50 different applications that they need to connect together. Now, it's not 40 to 50 for every client. An individual client has two or three applications. But the whole buckets are connected to the users' 40 to 50.

And they've come out and said that they're saving a significant amount per day per customer by using an embedded iPaaS like Cyclr, or they actually are using Cyclr, to be fair, and therein is the benefit. And what they're able to then do is to scale that ecosystem without having to scale that internal resource massively in order to meet those needs.

Ken Lempit:
So it was good talking about the case study of success, and I thought it would be good just to paint the picture of the other side, where we were actually on the wrong side of a custom coded integration on behalf of one of our clients. And part of the beauty of Cyclr is we've used it, as we realized it's almost self-documenting, so that when we create an integration using Cyclr, the next user in can come in and see what we've done and understand, like if a change is needed, it's relatively easy to understand, dig in and make those updates.

And the client we were working in had an integration between a billing system and its accounting software that was hard-coded. And the individual who wrote that was not even an employee of the billing system software, and it exposed our client to a great business risk, as it was hard to maintain and there were problems with it.

So I think it's valuable for us, as software marketing people and your clients, to consider the value not only in terms of commercial success, leaving the money on the table or being able to close the deals, but also being able to ensure that as changes are needed, it's easy for the next person to pick up that integration, figure out what needs to be changed or added, and make it happen. For us, our client, their entire technology stack was at risk because of this failed integration.

Fraser Davidson:
Yeah, you're spot on, Ken. And actually, the larger an organization tends to think about things in the way that you've just outlined there. Number one, the benefits of standardizing your approach to integrations through a common platform, so if Fraser leaves or Ken leaves the organization, then somebody else can easily and intuitively pick up the work that they've done and develop all the integrations in the same way.

The second part of what you're talking about there really is the fact that the more integrations you do, the more you realize that they're not static. Too often there's this preconception that you will build an integration between your application and Salesforce, then that's it, done. Now, you know and I know that the reality of that is not true. At the basic level, which most people get straight off, is that APIs vary and APIs change, so Salesforce will version its API in the same way you will version your API. Your integrations will need to adapt and evolve with that.

But actually, the flavor above it that's almost more relevant is that Ken's version of application X to Salesforce will be different to what Fraser wants from application X to Salesforce, which will be different to what the next person wants from application X to Salesforce. That can be at the simplest level, like picking up different lists or different areas in the CRM.

But equally, it can be just different ways of thinking as an organization, because each of your clients isn't going to be vanilla. It's not going to look at things in the same way, so you're going to want to adapt that framework for individual customers too.

So when you think about it from that perspective on change management within your organization and also change management for your customers, then having an agile platform that enables you to use those LEGO bricks and put new bricks in and take old bricks out and shift them around gives huge advantage to you in terms of ability to respond to those changes and what's taking place.

Ken Lempit:
So that's a real compelling case for an iPaaS, right, is that as a software exec, really in product marketing or at the most senior leadership level, we want to be able to support our customers. We want to be able to gather more of the opportunity, we want to capture more of the opportunity, and we want to make it easier over time to maintain that library of integrations. We want to make it possible that it's a good experience as things change.

Fraser Davidson:
Yeah, I'd agree. The interoperability and platforms working together is becoming part of life. There are so many ways in which that will impact you as an organization.

Now, again, I'll reiterate what I was saying earlier, I think, earlier in the podcast, in that you can do all these things yourself. Cyclr, for example, or any embedded iPaaS, is not a magic wand. We're not achieving integrations that a good technical team could not do with time and effort. But it's that component part, it's that time, it's the effort, it's the responsiveness, that really should sway you towards using an embedded iPaaS or any iPaaS.

Ken Lempit:
Fraser, we didn't discuss this as we prepped, but an area we're very interested in is what CEOs need to do post-funding. As you lead up to funding, you're all focused on getting the deal done, the check deposited in the bank, but you've done fundraising before, so you can look back on that experience and let us know. So once you get that funding in, how do you set your priorities for the organization, and how much of that have you done before actually the funding event closes?

Fraser Davidson:
Well, I've learned actually is a combination of things from my days in private equity and then also my days as a founder, which is that the work starts after the funding has arrived. In private equities, they used to laugh because it feels like such hard work to get the deal done that you almost feel you've reached the conclusion when the money lands in the bank account, and then you very quickly realize that that's the beginning of your journey with your investment partner rather than the end of the journey.

The big thing for me is that as Cyclr has grown up over the years, it’s actually openly doing the things that are a little less fun but are fundamental to driving scale into the business. And it's things around process, organizational processes. You're taking yourself a little bit away from the things you love like the sales, the marketing and the product development, and then bringing in clever people who are better than you who can then manage those functions on your behalf.

And it's almost like letting your baby go a little bit to allow somebody else to take this, work with you, and then gradually get better than you and begin taking your company in different directions. So I find that the more funding we've got, the more I've been looking at HR and recruitment and organizational procedures and setting strategy and spending time in meetings. The amount of time I spend speaking to people now rather than doing things is incredible. Now, it's illuminating and it's fun, but it's definitely a step change in terms of experience for me.

And I didn't have deep people-management skills before I got involved in Cyclr--you know, a laugh and a smile. Maybe some people say I don't have deep people-management skills now that I am involved in Cyclr. But I tell you, where I'm on the learning curve is that I'm learning those people-management skills, how to bring the best out of my team, and also looking introspectively at how to bring the best out of myself as well as the organization changes, to find those new strengths and identify the new weaknesses as well, the areas where I need support, and to reach out and get other people to help me develop the business as we grow off the back of not only the commercial success, but also the capital and the funding that we've received from our investors.

Ken Lempit:
So the scale-up demands the CEO-founder delegate really thoughtfully and build new skills, is what you've said here?

Fraser Davidson:
That's a much more succinct way than I put it. Absolutely, yeah.

Ken Lempit:
Some people say I'm a man of few words, others disagree.

Fraser Davidson:
No, very eloquent indeed.

Ken Lempit:
I think it's interesting because, certainly from the outside in, we've seen organizations where maybe we think the CEO was too involved in a line of business function, whether it's product management or sales, and it could hold back an organization. Sometimes founders need to be the driving force, the vision, and only they can truly conceive of this next step, this future, the Steve Jobs kind of model. But I think there's handfuls of those among the thousands and thousands of SaaS entrepreneurs who run companies.

Fraser Davidson:
Look, I would never hold myself out to aspire to be anywhere close to that Steve Jobs style of person. What I think, though, from my personal belief, having been that investor and being the founder, is that if you're involved in everything, eventually there comes a point where it's entropic or it slows the business down because everything has to pass through you.

So my mentality is to really focus on the areas not that I enjoy or that I want to be involved in, but that I'm actually fundamentally good at, and to invest my time in those, and then to bring in people who work alongside me who are good at the other areas as well, and to really have a coherent executive team within the business that then drives the company forward. It's a different angle, a different way of thinking about it. But for me, that is how you build a scalable organization without a single point of dependency as well.

And with my old private-equity hat on, you're always looking for single points of dependencies. So if you become the founder that is that single point of failure within the organization that lives or dies by you, then really, you're putting a lot of risk onto that company for the future, because if something does happen to you or you lose focus for whatever reason, then the organization isn't resilient enough to push through.

Ken Lempit:
So the other side of that is that then that organization might not be as investable, right? So if we were seeking capital or a complete liquidity event, a sale of the business, it might look from a professional investor's point of view that that business actually is not as valuable.

Fraser Davidson:
They're certainly going to think long and hard about it, I think. And they're going to assess that risk, and then it's going to impact the terms or the price that they will pay for your organization as a result, because they have to handle that risk. If you're exiting and you're being acquired, the acquiror needs to know how that organization is going to survive within their organization, and how they then overcome any single points of failure. And if you are that single point of failure, you become one of those risks that needs to be handled.

Ken Lempit:
I think that's a great place to land our podcast episode. Fraser, how can people learn more about Cyclr and reach you?

Fraser Davidson:
Please email me. It's Fraser, which is fraser@cyclr.com. Equally, I have a very good team, so if you just visit the website, there's a number of ways you can reach out to us indirectly through the website, and we'd love to be in touch and have a conversation.

Ken Lempit:
Excellent. Well, Fraser, thanks very much for the time today. I think it was a great episode. We learned a lot, and look forward to connecting with you again in the future as we work on future client engagements.

Fraser Davidson:
Thank you so much, Ken. We love working with you guys, and look forward to that too.

Thanks for listening to the SaaS Backwards podcast brought to you by Austin Lawrence Group. We are a growth marketing agency that helps SaaS firms reduce churn, accelerate sales, and generate demand. Learn more about us at www.austinlawrence.com. You can email Ken Lempit at kl@austinlawrence.com about any SaaS marketing or customer retention subject. We hope you'll subscribe, and thanks again for listening.