Drill to Detail - Drill to Detail Ep.120 ‘Embeddable, Cube and Lightning-Fast In-App Analytics’ with Special Guest Tom Gardiner

Episode Date: February 26, 2025

In this episode of the Drill to Detail Podcast Mark Rittman is joined by special guest Tom Gardiner, CEO @ Embeddable.com to talk about Embeddable's mission to create the leading developer toolkit for building fast, interactive customer-facing analytics directly into your product in partnership with Cube.dev and Rittman Analytics.Trevor.ioEmbeddable.comWhy Embeddable?Embeddable and Cube - Easy Embedded Analytics for EveryoneEmbeddable & Rittman AnalyticsFacility Solutions Group case study

So hello and welcome to the Drill to Detail podcast sponsored by Ripley Analytics. And I'm very pleased to be joined by Tom Gardner, CEO of Embeddable. So nice to speak to you again, Tom, and welcome to the show. Hi, Royce. Thank you, Mark. Absolute pleasure to be on this podcast with you. Okay, so Tom, just tell us a bit about who you are really and what you do now as a kind of high level intro to Embeddable. Yeah, so I'm one of the two co-founders of Embeddable. And my role is CEO, but basically my co-founder and I, we run the company together.

We're not the biggest company in the world. We've just hit our 17th employee, although we've got another three starting next week. So yeah, it's kind of growing at a fun pace at the moment. I really focus highly on the product side of things. So I work very, very closely with the engineering team, design team, but I also work very, very closely with our customers. So I do probably every day somewhere between two and 10 customer calls

and spend a lot of time working out how customers are doing and basically where they're getting stuck and driving that whole forward from a product perspective. Okay. Okay. So tell us a bit about the story of you getting to where you are now with embeddable. So tell us about trevor.io and I suppose your journey in this industry really, first of all. Yeah, sure. Just maybe just to start slightly before that. We're in the customer-facing analytics space. That's what we're all about. We do customer-facing analytics. We basically enable companies, in particular SaaS organizations, so anyone with an online platform, to deliver customer-facing analytics,

i.e. analytics in their platform for their customers. Just to put that in layman's terms, the example I like to give is Spotify. If you think Spotify from the perspective of most users, you think of Spotify as a music platform where you go and listen to podcasts and music. You don't think of it like an analytics platform. But if you are a podcaster or an artist, publishing your music on there, you very much do think about the massive value proposition of Spotify is that they show you analytics about the music you play. How often does it mean play? Who's playing it? What time of day in collaboration with what kind of music? All of that kind of data allows you to improve your business. And basically, you can think of

any online platform as, yes, there's that core value proposition that they do, you're going to think of Stripe, they do payments, but you actually care hugely about the analytics behind that. And so, we basically enable organizations to very, very easily build analytics into their platform that looks and feels exactly like their thing. So just to give that context to the space that we're in, and then I can tell you a little bit about how we ended up up there. So about 10 years ago now, I was CTO,

so running the engineering team of a startup called RefMe in London. And I had about 20, 22 to 25 engineers working for me at the time. And what I found very, very quickly was that it was just a huge appetite for data questions within our organization. So we had, you know, the marketing team, the product team, just people across the organization, constantly bombarding us with data questions to work out what was going on with all the users and within our application. And so in the end, out of my engineering team, I had probably like two or three, almost look fully dedicated to effectively

writing, building out reports and things for members of our team. And so we started out by that, okay, let's let's just build a bunch of dashboards for them, etc, etc. But as we start to do that, what we realize is you put a dashboard in front of somebody, nobody goes, Oh, look, there's a dashboard. Now I've got, you know, here's a chart. This is the answer to all my questions. What they do is they look at it. And then they have a follow up question. What's about that spike? Why is that? Can I break that down by this? And this is exactly the journey that we

started down in my previous company where I worked. And it just made me realize there has to be another way. And obviously there's, you know, there's loads of what we call BI tools, business intelligence tools, like, you know, Tableaus and Power BI's, etc, in this world. But they're really designed for your data analysts to go and go and get data's that they're really not designed for your usual user who doesn't want to go on a training course for a week or a month. They really

just want to go in and get get answers. And so long story short, it just became really obvious that there's an opportunity for something slightly different. I ended up leaving to create a company and a product called Trevor.io, together with my co-founder, Harry. We ran that for a number of years and basically it enabled exactly that. It was a very, very, and still is a very low code solution for building, for querying data from your SQL databases behind the scene. And it's used by hundreds and hundreds of companies worldwide at the moment. Getting onto embeddables. So what started to happen, however, was that, interestingly, more and more companies started coming to us and go, yeah, we really

love using Trevor.io internally for analytics. But actually, our customers are just as data hungry as our internal team. Is there some way we can use your platform in our platform? And at first, we started ignoring these requests because we're like, focus, focus, this, that's not what we're doing. We're doing internal analytics. But just bigger and bigger companies started knocking on our doors.

I don't want to drop any names, but it's, you know, it's definitely heard of. And, and it was just like, okay, there's, and the kind of budget they were coming with was, you know, sometimes like 10 times what we were seeing for this other product. So there was definitely something there. So we explored this and we said, do you know what? Why don't you just take our platform? We'll put it in an iframe for you. You can plonk that into your platform.

And so a load of companies did. But what happened is as we dug in with these customers, we realized that taking, you know, whether it be our BI tool or any other, like if you take Power BI or Metabase or Looker and you try and plonk that in your platform, you know, it literally looks like, you know, kind of Frankenstein solution that's been plonked in your platform. You know, it looks like there's a window onto some other thing inside your platform. It doesn't look and feel like your platform. On top of that, there's

a learning curve that comes with it. And it certainly isn't the case where your design team can use Figma to spin up a beautiful design, pass that over, and then you can make it happen. You're kind of stuck with the components and the look and feel that that platform kind of comes with. And so the more we dug into this, the more we realized, do you know what, there's a big, big opportunity here. People are asking us for this. And so we actually made the decision. We kind of made the decision based on starting to see, actually, can we sell this to people without kind of building it?

And so we took an approach that I guess I've only ever read about, I've heard about, kind of lean startup style. We basically created a PDF. We created a PDF that described what would be what we now call embeddable. So we created a PDF describing a developer toolkit that basically allowed your developers – so it's not purely no code, quite the opposite, it's literally built for your developers to basically build analytics into their platform, effectively allowing you to use any

charting libraries you like, any React code you like. You can literally take your favorite library, whether it be D3 or HighCharts or Google Charts, or build something completely from scratch using canvas elements. You can build that and we basically automatically package that into a no-code experience for you and then combine that with a data modeling layer and then enable you to publish that so it looks and feels like your platform. What we found is people got very excited. Development teams got really excited.

We were like, okay, well, would they actually pay for this? And what we ended up getting was somewhere between 20 and 30 companies paid us a significant amount of money upfront for early access to this platform, which we hadn't yet built. And this is where we realized there's definitely something here. And so a year and a half ago, so not very long ago, we went full in on this. And basically six months later, we launched to that first 30 companies. And I guess to finish my ramble, we've since then gone on from launching that

to a year later. At the moment, we're signing about 100K worth of new deals every month. And like I say, we're a team of 17 people. Where did the name Trevor come from? What was the significance of that or the meaning of that? Yeah, sure. So basically when we started out,

we really wanted it to be like a verb that people would use, like Googling it. We want people to be able to go, I'm gonna, gonna Trevor my data. And so that's really what the kind of where the name came from. And just, we actually had a kind of fun catch phrase, which was, my data could do with a good Trevoring, which, yeah, among British audiences went down, went down really well. We, you know, we had t-shirts and mugs and all that kind of stuff.

And what that quickly turned into is Trevor then became a little cartoon mole who was digging into data. And yeah, from, from now on, that's, that's what Trevor is all about. Okay. So, so, I mean, and you also made, you also talked about customer facing analytics there. So how does that differ really from, I mean, how different is embeddable from Trevor? And was

there anything in the way you built Trevor that made it that made it particularly a good idea to build embeddable and how much of that went through to embeddable really? Yeah, great question. And so that they're quite different. And so Trevor is really a no code experience designed for product teams, you know, customer success teams, salespeople, etc. People with very little experience with SQL certainly know coding skills. Embeddable is very much on the other side.

So there's a whole no-code dashboard builder side of things, which is used by teams like product teams, etc. But we have an SDK which requires you to write React code. And we have a data modeling layer, which is very similar to those familiar with Looker and LookML. It's similar to that. We use something called Kube. And basically, it's quite technical in that sense. And basically, it's quite technical in that sense. So we definitely benefited in many ways from moving one to the other. I think one of the advantages of having run a data platform for many years was that we also knew all the things

we wish we'd done differently, right? And we really knew what were the things that we wish we'd done differently, right? And we wish, and we really knew what were the things that we wish we'd built it from the ground up to be different. Like one example of that is including a, what we call a, I guess, a semantic layer or a data modeling layer to allow people to kind of create that single source of truth. But also, you know, just, I guess, building it in a scalable way that we hadn't done before. So I think that mainly there's just a lot of learnings, but ultimately it was built quite differently to Trayvon. Okay, so just again, just to set the scene.

So you've got, I suppose if you're someone who's building in-app analytics or customer-facing analytics, you've got maybe sort of a couple of choices there. You can either go and build it yourself using kind of React and you say high charts and so on. Or you can use a tool like Looker. So why would, okay, so why would Looker not be a great Looker or a tool like that not be a great fit? Where does the kind of the where does the detail of the issue come in there really? And why is building it completely from

scratch? Also, maybe not a great idea. Yeah, great question. So if you're using something like Looker, like Looker, Tableau, Power BI, they are fantastic business intelligence platforms. They are used by massive organizations to build internal analytics. And they optimize for a particular set of users. That set of users are internal data teams,

data engineers, data analysts. The characteristics of those people are usually they're doing all day long, they're doing analytics. That's their job. They certainly don't have any worry about requiring a bit of a learning curve because they are happy to spend time doing that. They also are usually running their application on a dedicated computer for that. And so there's no problem with memory. And finally, if they need to run a query or a report and it takes 10 minutes to run, that's not a problem. They'll grab a cup of coffee.

They'll come back, see if it's finished, et cetera, et cetera. If you take all of those three things and try and apply them to an in-app analytics customer facing, it really falls on its face. You know, firstly, they don't want a learning curve. Secondly, they certainly don't want to wait 10 minutes. And, you know, thirdly, they really want it to look and feel like their platform. So, those platforms work really well for internal analytics. They really don't work for customer facing analytics. And that's what we discovered. And on the other side, the other option, like you mentioned, is building from scratch. So yeah, why not just go and build

analytics from scratch? Well, you can and most of our customers have started to do that. And after a couple of months, they've been building our analytics into the platform. And they're still being asked, Yeah, but can I drill into this? Or can I, you know, schedule it to be delivered every Tuesday? Or can I, can I break it down in this way? Can I, you know, can I customize it in this way? And all like, for example, sales teams are being basically saying, Oh, I can close this deal if we can do a custom dashboard for them. Oh, well, you know, two, two, three, four weeks later,

maybe if they're lucky, they'll get something in. And so basically what people are finding is that if they can build it themselves, the requests never stop coming, firstly, and also the opportunities to kind of close bigger deals, bigger business, it just falls on its face because you have to always get engineering involved in order to make any iterations. Also, you end up with churn in your engineering team because your engineering team might be happy building that first dashboard, but when they're constantly making those little plumbing changes, they're just not happy at all. And so where we really sit is

like a really happy halfway house between the two. So all the kind of no code builds your own dashboard experience like a Looker or a Tableau, but all the customizability of building yourself because you can literally bring in your own components. Okay, okay. So, and in full disclosure, we're a partner of Embedable. We like the product so much that we've partnered with you and we actually have done some consulting projects using your technology. And the thing that really struck us was when you first spoke to us and you were explaining the innovation in embeddable, you described it as a bit like, say, Stripe, where you could just drop a line of code into your inter-application and you get all the payment back end and so on.

So is that the innovation that you're bringing to this really? Because you're not the first to sell a toolkit really for embedding analytics in products, are you? No, so there's quite a few libraries to enable people to build analytics faster, right? So if you think of material UI or there's one was bought by Versel recently called Tremor, people unfamiliar with the frontend frameworks might be familiar with like ShadCN and things like that.

And there's just lots of charting libraries that enable you to do this yourself. And those are great. And the interesting thing for us is we're not trying to compete with them at all. We actually enable you to use any of those. So for example, we're recently partnering with Material UI, for example, and we have close integrations with other libraries like Chart.js and Hyjarts. Because interestingly, we're the first platform out there

where instead of competing with them, we actually are completely partnering with them because you can use any of those libraries within embeddable and what we do is we turn them into a kind of no code experience. On the other side, you've got the BI tools that are saying, hey, yeah, but we integrate with React and that kind of thing. But it's really, when you dig into it, it's unfortunately very much a marketing gimmick, right? As in, it's like, yes, you can embed within, but it's really not built from the ground up for engineers. And what I mean by that is you can't just take a platform that's designed and built from the ground up for data teams and then turn it into something that's ideal for developers. Developers are incredibly picky

about what the solutions they use. They have a lot of choice out there. And so you really need it to be built from the ground up from a performance point of view, as well as a user experience. I don't mean even user experience, a developer experience perspective. It needs to be built completely different.

And we're the only platform out there doing that. Okay, so I can understand that you've got these kind of, I suppose, toolkit components that you can use to build a customer face analytics experience. What about adding things like dashboards? And you mentioned the low code builder. I mean, how does it go? How far does the product go in things like, I suppose, like build dashboards, for example, how does that work? Yeah, sure. So basically what happens is we have a,

if you go to embedable.com, there's lots of examples, you can see how it works. But just to give you an idea, basically we have a kind of no code canvas, very similar to what you'd expect in any dashboard building tool is you can drag and drop your components, resize them, move them around, toggle all sorts of different inputs

and outputs. But the interesting thing is that every single component there are actually React.js components that are coming directly from your code base. And so when you're interacting with it, what's actually happening is that's passing different props into your React components. Then what happens is you build out those dashboards,

and what we do is we have a innovative way of React components. Then what happens is you build out those dashboards and what we do is we have a kind of innovative way of loading data. So we basically take your data modeling layer, which is where you describe what's really called dimensions and measures and data models, which basically describes where to get data from. Dynamically, all of those kind those assets are made available inside the dashboard building experience. So as soon as the data team in your team, for example, adds a new

data model or a new dimension, that's automatically made available within that dashboard building experience. And then behind the scenes, what we're doing is we're automatically hooking that all up, meaning that those individual components can actually talk to each other. So it's not just about, for example, I've got a filter and that can filter my chart, but actually I might have a pie chart where I want to click on a slice of that pie and that affects all the other components around, or even sends events back to your React code in your end. Like I said, it's really built for developers as well. It's really built so you can build it as an integrated part of your application. Okay. Okay. So the reason our paths crossed really was, I mean, the front end part you

described is great, but it's not an area that my company typically gets involved in. But I suppose the backend is what's interesting to us and your use use of cube, right, cube open source. So tell us how, take a picture, how does embeddable get access to data? You mentioned dimensions and measures there and so on. How does that work and how does cube come into it? Yeah, sure. So basically, cube is a semantic layer

or a data modeling layer. And so what you do is you, and it's really very similar, very similar to LookML for anybody who's familiar with that. And so you're moving over from Looker, it can be a very, very nice transition. And effectively, what you do is you describe concepts in the form of data models. So you know, you might have users or orders or products depending on the type of application you are. And within then you define these things called dimensions. Dimensions are your kind of virtual columns, if you will. So it can be the literal columns in your database

or another example would be, let's say you've got a first name and a last name column, you might define a full name dimension, which is obviously the concatenation of the two in some way. And so you divide these dimensions, and then you have measures. Measures are your sums, your aggregates, your averages, et cetera, your maxes, your min.

So it's basically your KPIs, if you will, things that you want to calculate. And the really nice thing is you define everything in In a single place you end up with a single source of truth So for example the term revenue you might define this in one place and what that means is that every dashboard and every query behind the scenes and Basically uses that and if you change it later And obviously a lot of these things do change

Whether it be because of your schema changing or just because of business definitions changing. You just change it in one place and suddenly everything is updated automatically. The alternative to this, which is what most, for example, BI tools will do is that they'll have a... You end up writing a separate SQL query, for example, per chart. You see that a lot in a lot of tools. And that allows you to get up and running pretty quick. But then as soon as you've got to make a make a change, it becomes an actual nightmare. And also the consistency you get, you know, revenues calculated or maybe a better example, active user, what is the user? Well, the

definition of that is, is can be very woolly, you know, is it somebody who's been who's done this set of actions in that particular period, or is it something else? And so you really don't want half of your company or half of your users thinking of a definition of one thing in one way, and then over here it's being used somewhere else. And they're like, well, why don't these numbers match?

Oh, because the definitions are different. And so that causes a lot of pain and a lot of confusion. And so that's where something like Kube is just really, really effective for creating this kind of single source of truth. But specific to your question about how we use it. So we basically, they have an open source version, and we basically run that automatically for our customers. So our customers just define their models. They, as they commit them into their main branch in Git, as part of their CI-CD pipeline, that gets automatically then pushed to our platform, models get updated on our side, and basically everything is run and scaled on our side.

Behind the scenes, there's also two levels of cache. These caching layers enable you to get a lot of performance out of these things. Most of our customers do this themselves, but like you said, Mark, we've had a few customers who come in with just these massive data, it's very, very complicated. And so that's where partnering with you guys at Ritman has just been fantastic. We've just said, hey, bringing is very, very complicated. And so that's where, you know, partnering with you guys at Ritman has just been

fantastic. We've just said, hey, you know, bringing these guys, they can really help clean up your data and create your data models. Okay, so well, I mean, does cube also help in terms of connectivity as well, to different data sources? Yeah, exactly. That's correct. So basically, the nice thing about using cube out of the box is that I don't know exactly how many. There's somewhere between a dozen and 20

different types of connections. So your obvious ones like your Postgres, MySQL, Redshift, Snowflake, BigQuery, et cetera. But they also have all your engines that maybe aren't so common, but a lot of people use. And so Out of the Box basically works with every possible kind of SQL type database you can think of.

Okay, so does somebody need to be a cube expert or a cube administrator to work with embeddable then, or do you kind of wrap that up in your own admin functions or whatever? How does that work? So we fully manage the cube side of things when it comes to structure. So you don't need any knowledge at all for that. And obviously, we're doing that for a lot of companies, and so we're very good at scaling that.

We also have a partnership with the actual Kube team. Obviously, Kube, just to mention, they do have a cloud solution as well, which is fantastic, especially if you want to use Kube beyond embeddable. If you want to use it with other applications, then using the Kube cloud as an option together with embeddable also works pretty well. But for those who just want to use it with embeddable, we kind of manage that for you. So the only thing you need to know is how to define Kube, which is a very simple, either YAML and SQL syntax, or you can use a JavaScript syntax.

Okay. So how does, when a customer uses embeddable, how does it actually work in practice? I mean, do you host it for them? Do they host it? What's the, how does it deploy then really? It's completely software as a service, right? So it's SaaS. We run everything for them. So you can choose your region. You can say, I want it in the US, I want it in the EU, wherever. And basically, we run everything for them. So the only thing that needs to sit on your side is your component code and your model code.

That all sits in your Git repository. It can be completely private. But as part of your CI-CD, that gets pushed to our cloud platform, which runs behind the scenes on AWS, and we manage that all on top of Kubernetes, etc. But yeah, it's very much sitting on our side. We have a lot of requests for running this as part of your own kind of private cloud. That is coming very soon. At the moment, it's not something we offer.

At the moment, we're cloud first. Okay, so again, it's a bit like Stripe. You wouldn't expect to get all the Stripe systems running in your part of your application. You would just have the code interfaces with their system. Exactly. Exactly, okay. So who, I mean, within bounds of who you can talk about,

who has been using embeddables so far? And what are some, maybe some examples of where it's been used and been sort of successful Yeah, sure. I think obviously one example we can talk about is one that we did together, which is FSG. Maybe let's come back to that one in a second, but just to give context of it. FSG are a huge company in the US, do manufacturing within everything from huge company in the US do manufacturing within everything from electronic devices, etc. And high level companies like that, they have a lot of suppliers. Those suppliers care hugely about where in the particular step is there, are there manufacturing processes, etc. They have a lot of data about these different things and they want to be able to show that analytics to them.

So maybe that's one example. Let's come back to that in a second. On the other side, we have, for example, without naming any names, we have a large education provider in the US that does, for example, analytics. They have a kind of education platform for schools, hundreds of schools across the US, about 200,000 students across the US who basically are using that platform with their teachers and students. And what they want to do is they really want to show analytics to, for example, the teachers on you know, which students are doing well, which ones are falling behind,

which ones need to be focused on or like general how are the how are the districts or those particular schools doing. And so basically, they use us for building out analytics into their into their platform across that difference. So that's a kind of more of B2C. But you know, we have large, kind of big SaaS companies as well. Again, I try and refrain from using the name but yeah, large SaaS companies that for example, do online sports teams, sorry, not online sports teams, for sports teams like physical sports across the US, for example, who, you know, very much like if you think of, I don't know, Formula One, you think of it being very analytical, they're

measuring everything. Well, for sport teams across the countries, that's very much the case as well. And so they're building out, you know, this analytics, they can really dig into those those kind of things. So if you can, if whether it's B2B, B2C, if you can think of it like software as a service, and people having data with you, there is a use case for embedded customer facing analytics. Okay, so I suppose one of the challenges you've got

is because your product is so themable and it is so able to adopt the look and feel of whatever SaaS application it's running in. I suppose that viral marketing thing for you is not so much of an option where people sort of see you on everything and then think we've got to use you. How do you, what's, it's a little bit off kind of piece really,

but how do you go about actually growing the company and the awareness of you when you are so invisible really to most people? Yeah, completely. So, but yeah, by definition, we are invisible in the sense that people really use our platform in order to build something that looks and feels like their own platform.

However, our audience is really on the developer side. Developers are huge evangelists of products that they love to use. They're also very good at jumping between companies and bringing products with them, which is great. We don't have an outbound sales team. We basically have an inbound motion. What that means is, is that companies are literally or customers or developers, you know, CTOs, heads of engineering,

etc. are literally hitting this pain point, this pain point that hey, we're trying to build analytics is killing us. No, we this never ending roadmap. And is there a solution for it? People are searching for things like embedded analytics. Interestingly, they're also searching for alternative to Looker and Power BI and that kind of thing. And people are ending up finding us and obviously, the more people that are happier, the higher we end up in the rankings. And so basically, every day, we, dozens of companies coming to us knocking on our door going, Hey, can we try out your product? And at the

moment, that's working really, really well for us. Obviously, at the moment, we're, we're spending a lot of time with our customers. So when a customer comes on board, we jump on a call with them at least, you know, every one or two weeks, we're spending quality time understanding their use cases and needs. And eventually, we hopefully next year, we're spending quality time understanding their use cases and needs. Eventually, hopefully next year, we will be opening this up to a self-serve platform, something like when you think of Stripe, where you can sign up without talking to anybody. But right now, we really want all that quality input.

And so, yeah, this people basically searching for us and signing up is driving a huge amount of revenue for us right now and we're in a really good position. That's good. I mean, your website actually, I think it's fantastic. The design for it is really good. And I think the way that you use, the way that you say you put those kind of alternative sort of posts in there. So you put, you did one a little while ago, which was talking about different options for, I suppose, in-memory databases or fast access databases to support things you're doing really.

And I thought that was good, but in particular, that topic, is there anything that you consider to be a success criteria or things that you look out for, for customers that they're doing things in the right way that would make embellish success in your view? Completely, Yeah. So we're actually very picky at the moment. And who we let in for exactly the reason I just said, which is that we're very hands on. And so we really want to make sure we're, we're letting people in. And so interestingly, we have this fun dynamic that a lot of times, we're turning companies away as opposed to the other way around. And so, yeah, but the kind of things we look for are developer first, right? So if you're looking for a purely no code solution, then as in you don't wanna dedicate engineering resource,

you know, we're not a great solution for you. We're our developer tool. We're really there for teams who care intimately about what the end solution will look like. The ideal team is coming to us with Figma designs already and going, hey, this is what we want. We have this ambitious view and goal that we want to do with. That's on one side.

On the data side of things, customers are... If your data is all sitting in Postgres and MySQL, we're a fantastic solution for you. But even better is if you started on that journey of, for example, setting up your data warehouse. You started using Snowflake, you started using BigQuery. Or even better is, you're miles down that road and you're just looking to make the most of your kind of data infrastructure. So those are the kinds of things that we look for is really opinionated about what you're building, highly ambitious and developer,

development team driven. Okay, okay. So what's coming down the line then with embeddable? So you said it's like you've been going for about a year and a half now and you've got quite a long way, but what's, I mean, your roadmap is fairly public, but what is coming down the line then with embeddable. So it sounds like you've been going for about a year and a half now and you've got quite a long way. But what's, I mean, your roadmap is fairly public, but what is coming down the line and what are the challenges you're looking to solve in the next kind of year

or so? Yeah, sure. So I think the big thing for us, one of the big things for us, which we're very excited about, is that because of the nature of our platform, which is that it's kind of developer driven and there's an SDK that allows you to do it wherever you want, is that pretty much all of our customers are building their own components, their own ways of interacting with data. And so even now, we've got the ability to have a huge variety of charts and interactive controls and things built by our customers that they can then share with others. And so we really wanna be driving that forward so that basically everybody can be benefiting

from the effort of each other. And before you know it, instead of being stuck with, oh, I've only got this one pie chart or whatever, you know you've got a dozen different ones designed for your particular area or region in a similar way to tools like Notion have templates built by the community. And so that's very, very exciting. On the other side, when it comes to AI, so AI is obviously the big thing at the moment, talking about it, there's so many opportunities, whether it comes to automatically generation of your models or even of your

components, or even allowing your end users to query your data through a natural language interface, for example. These are the obvious ones. There's lots of nitty gritty things that I won't bore you with, but the point is there's lots of nitty gritty things that I won't bore you with. But the point is, there's lots of opportunities to go there as well. Okay. And you mentioned about community there. So obviously, there's a there was a conscious decision at a certain point to

not go down the open source route. What was the reason for that? And, and, you know, is there? Why have you chosen the route you did? And what are the kind of the it's been your mind the pros and cons of that decision? Yeah, sure. So I think it's worth pointing out that we do have a massive open source component to our code, which is the whole SDK, the whole component side of our business is fully open source. And so everybody basically who wants to take advantage of our component side of the business and, you know, whether it be controls or charts,

that's fully open source. So, and that's important. When it comes to the kind of core part of the business, we really want to be able to move as quickly as possible and deliver huge amounts of value to our customers as quickly as possible. What we've found is that there are huge advantages to being open source, but what that comes with is you can't just say, oh, it's open

source and then not put any effort on it. You really need to drive that community. You need to spend time on it. And so what we're doing at the moment is driving the community around the component side. When it comes to the rest for now, it's not an open source solution, but that enables us to move as quickly as possible. And we're really listening to what our customers want and reacting to that. Okay, so I suppose a bit like segment, for example, where segments, I suppose the client SDKs are all open source,

but then the core of it is closed source. Is it that kind of model really where the bits that the key value of the innovation part is your bit there really, but everything else you open source? I think the main thing is that we want it to be extensible, right? So extensible on the component side, but also on the data modeling side. At the moment, like we mentioned, Cube is the way we do data modeling. We get lots of demand for people wanting to do modeling using dbt semantic layer, for example. There's another tool called AtScale, but also lots of our customers have existing data layers

that they've built many years ago and they want to use those. So we very much want to open it up so that people can connect their own data. There's also lots of other kind of competitors coming along the line, which are really interesting. And so we really want to be extensible in that sense. Okay, one last question for me. So when we spoke earlier before we did the call, you mentioned you're in Berlin.

So what's Berlin like as a kind of a place to run or start a startup like this really? What's the community like and the environment? I think Berlin is a fantastic place to run a startup. Berlin, and it's one of the big reasons I came here, there's a thriving community. Also from a location point of view, it's very central in Europe, which means, for example, it's very easy to get to Western countries like France and the UK and even get over to the US, but you have direct access to incredible talent from the Eastern end of Europe as well. It just fits really nicely. Also,

So it just fits really nicely. Also, you know, you're bang for your buck. Let's put it that way, it's pretty good here. And so I think it works really well. Our team are fully remote. So most of our engineers are here, but the rest of the team is spread across Europe and we'll be expanding across the US as well. So how do people find out more about embeddable

and maybe sort of like get in contact with you if it's suitable for them and so on really? Yeah, thanks Mark. embeddable.com, embeddable.com if you're not sure how to spell it, there's some Bs and Ds and things going there, just Google embeddable as well. And that's a great way to get in touch with us. LinkedIn is also a fantastic way to get in touch. Fantastic.

Well, Tom, it's been great speaking to you. Thank you very much for your time and best luck with the product for the future. Likewise. Thanks, Mark. Have a great day. you