Drill to Detail Ep.77 ' Keboola, Scaling Analytics and Winning the Looker Join Hackathon' with Special Guest Pavel Dolezal

Hello and welcome to Georgia Detail and I'm your host, Mark Rickman. So I'm joined today by Pawel Dodojal, CEO of Kabula, a company I first came across at the London Looker Joined conference last year and more recently at the Looker Join event in San Francisco where his company won the Hackathon event. So Pawel, welcome to the show. It's great to have you with us.

Hey Mark, thanks for having me on the show. It's really a pleasure. I'm a big listener to your podcast and I love them. I love the people you bring on and the level of technical details. So thanks for this. Yeah, as you said, my name is Pawel and I was born in Europe in Czech Republic and basically I was fascinated by technology since I was very, very, very young. And then when the Internet came, I started to actually do my own Internet businesses with a couple of friends. We started the search engine Internet portals in Europe. I was part of the leadership team and then we actually we were part of a Microsoft network for a while. We were in several countries, developed over 50 different products in consumer facing. B2B facing was late 90s and we were all based on. Net, Microsoft SQL and all that environment. Then my second company actually later started fastest growing performance media company and within two years we were actually servicing 15,000 businesses all over Europe. We moved our stack from Microsoft to open source Ruby on Rails couchb, Redis. That was that time, you know, everything was changing and then cloud started to catch on and you know, like servicing 15,000 clients meant that we were really automating a lot of things and we were doing a lot of that with data and machine learning. But in both of those ventures I would always have dozens of people taking care of data infrastructure and the process to get to something, you know, to answers, insights. It was very linear. We as a business owner, I would say well I have an idea, I would like to explore this and I would issue a ticket and ticket goes to it, then goes back. I thought, well it's really good, I explore it, but something missing. So it goes back to it and before you know it we have four iterations and the answer is nobody cares. So later on I actually, when I sold that company, I invested in a couple of, a couple of startups and one of these companies was actually doing Google Apps and Google Cloud implementations into large banks. And I was working with the CIO of that bank and he actually wanted to quickly analyze data about engagement of their employees and from totally different sources like internal systems, external systems, RESTful API. And I was like, well, it's going to take a year, right? It's like, well, you taught this cloud, so I have a cloud challenge for you. I care about speed, accuracy and cost. So that's how I found Kibbler, because nobody else was able to do it. And it was really interesting back then. Kibbler was really an agency which was specialized in moving clients to cloud and helping with their systems and data integration for analytics. And they were doing integration projects, right. So but they already had this internal tool which I really fell in love and they were the only ones who were able to deliver what I wanted from them in 12 hours. So that got my attention. That's kind of like my story.

So my understanding of Kaboola is it's a product that came out of the consulting work your company was doing originally. So you were developing, I suppose, tools and techniques which you eventually found that could be turned into product and is now being offered for sale as a packaged up accelerator, I suppose really for businesses looking to scale their analytics and to deliver things faster. But there's quite a few companies out there that do this. So what is it particularly about Kaboola that is its unique selling point and who are you aiming this product at particularly?

So I have to say we typically would serve more and more two groups of customers. One of them would be hypergrowth customers and the second one would be kind of like the large enterprises. And as you say, we've been around for some time taking what we had internally and prioritized that and what we see there's some pressures in the enterprise kind of world with more and more people wanting to scale analytics. And what we really can address for those people is kind of like three problems. The first one is when there is a rise of agile teams across functional teams across the enterprise and their desire to actually do analytics and move from those linear ways to kind of like non linear ways, you know, and actually analyze data from. Gartner says There is over 1100 applications which are SaaS used in typical enterprise, plus all of the old systems. So this rise of, you know, like people and how to how citizen analytics, how you scale it to them. Second is kind of like, you know, when you want to democratize this analytics and scale it across the company, usually with our customers we see the rise of 10% of the whole company would really need to do deep analytics, not just looking at the dashboard, but really do analytics if you want to go the traditional IT way. What we have found you would need actually to support for three to five business people you would need one IT person and that's just not scalable. If you talk about 10% of people doing analytics because you would have to hire hundreds of IT personnel to actually support that linear approach that we talked about some minutes ago. And then as I said there is that PLATO for our data sources and not only data sources but also tools for analytics. Somebody wants to use for something SQL, somebody wants to use R somebody, Python somebody, Julia, MATLAB, OpenRefine and on and on you go. And also what you want to do with the data changes. Originally people just wanted to look at the data. Now they want to do a simple bi move to machine learning and all the way do neural networks and applying third party components and all of that is for insights and automations and all that creates a huge stress on organization design where traditional IT and business roles are really separated their responsibility and stuff. And especially when you think about the legacy technology. And so what we saw was the, you know, like companies actually wanted to move from this. They wanted to become more agile, you know, like create cross functional team. And really the reason was to compete with Silicon Valley tech giants, right, who are actually really fast and traditional business. How can we compete with it? We need to really, you know, change something. We need to augment, you know, the typical humans with you know, data powers, make them into data heroes and automate the manual kind of the boring stuff so they have more time to be creative and the company moves from he does this, she does that and they are siloed into hey, let's bring the cross functional teams into Agile and create tribes. But it's hard what we typically see that companies take two routes. Previously they would either resonate because we are in that old world, kind of like Oracle data warehouse, lot of data Mars, very rigid node structure. And that's by the way what Looker CEO talk to Looker Frank calls the first wave of enterprise architecture where only a selected few could really do something. When we talked about it a little bit when we were preparing for this call and and the tools like the Oracle and they were brilliant. When you talked about being used by IT people and this didn't really scale, the cloud came and suddenly you would have all these small tools as you talk about stage DBT or whatever and anybody could use it. And as Frank Lucasio says, this is the second wave of analytics architecture and then there is no security around it. So the second wave is kind of good, but not for enterprise. And it creates a lot of shadow ip. So what we See, now is actually the need to kind of like come at this third wave, which is the abstraction layer on top of these two ways, which actually gives the users the ability to use the tools they want in the teams they like, which are cross functional, reuse what they build. And still that has to be augmented with enterprise grade security metadata, lineage, procurement certificates, etc. So the way we think about this is kind of like if you think about what Twilio did for communications, they actually put an API layer on top of all communications. On Stripe, they put an API layer on top of all the payments. So what we are in a sense doing, we are putting in data API layer on top of the whole data analytics and automation journey, on all the infrastructure which is there on all the processes, so we can abstract the users from actually the complexities. This results kind of like in a serverless implementation of the data analytics journey where people say, well, this is what I want to do, the code and this is the data I want to work with. It's a little bit more difficult or different from the serverless implementation in, in development, but I think it's actually very good. What this abstraction actually allows us is to have all the data goes in through API, goes out through API, all processes go in and out through API and that going through API layer, we have all the metadata, we have all the payloads, user activity, changes in data. It creates automatic lineage, creates all this data intelligence which is done automatically on the fly. It can be actually used by company procurement and security departments. We put all the data in GraphDB and it's very easy for users to use. So if you think about the environment, kind of like looker or tableau, it just usually kind of starts with I want to do bi, right? I want to connect to new systems or old systems. Then we. Well, I want to do transformations. Well, I actually need to do some machine learning and I want to use Python. Oh no, no, I want to use Julia. Hey, we need to work together as a team and we need to work all of this, all of these data operations, if you will, along the whole journey is kind of like just like really difficult because too many moving pieces. So that's why we created an abstraction API layer that would enable actually the company is to actually really move into DataOps way. And I don't know if you're familiar with the guys from Data Kitchen, they actually wrote a very good piece about DataOps and they kind of stated several things, how DataOps is different from DevOps. We all know that it's kind of like the DevOps is kind of people over processing conventions and over technologies. But if you think about this approach and you think about it, how it applies to data analytics and how it enables the agile teams, the guys actually say three components. First of all, we have different users in Data Analytics. In DevOps they have just the engineers, the developers, and they are very technical, they want to tweak things. They love to learn new technologies and new approaches in the data analytics. I just counted, we have over six user groups from IT developers, data engineers, data scientists, data analysts, business analysts, except for IT developers. Five of those groups don't really care about the code and tweaking the code. They all care about business outcomes. So we need to support them and automate the process around them so they can actually create agile, you know, themes. Second piece of the Data Ops, kind of like manifesto, if you will, that the data Kitchen guys put together. It's kind of like, well, we need to adopt the DevOps methods for continuous integration and continuous testing. So because we have two different, we have two different systems, if you will, in data, right? We have innovation cycle where we need to be really speed, velocity, different tools, agile teams and everything. But then we need to move it into the second cycle, which is a production cycle. So they say DevOps methods thinking, the second pillar enables us to do that. But the third pillar is actually the production cycle. If you think about it, the production cycle, the models and pipelines and automation of workflows, they need to run both in cloud and some of them on prem. And they need to be really rigid, they need to be scalable and we need to be able to test them and actually measure that production cycle. And it actually brings together the methods of lean manufacturing. Right? And so when we, when you think about this, you know, it's kind of like when you ask us, well, how do we fit in? We say, well, we are kind of like a serverless data operations platform and we, what we enable is to kind of like scale business insights and revenue through the whole organization, not just parts of it, and automate workflows and enable click and mainly risk free secure experimentation in that innovation cycle with one click, putting the models and pipelines into production and that all is enabled by the API abstraction layer. That's how we fit very well in that world of the new tech together with old tech.

So the product sounds quite technical. Obviously we're talking about being aimed at business users. I mean there's quite a few products in this space. You've got from one extreme, maybe Tools like DBT or Data form, where that's about trying to make analysts into engineers, but it's quite kind of basic and scripting and so on. Other extreme you've got maybe more established, maybe more old school tools like whereascape Red. Who do you see as the target market for this and who's the Persona that you've developing this product for really?

Well, that's actually the great question, that's the only question that matters, right? You know, like what value you bring to your users and who are they, right? You know, like all of those guys, we know most of those guys are really, really great, you know, technical people are really great people, but they come to the problem, you know, from purely technical perspective, right? And kind of like, and I would say those kind of like everybody comes to a problem, you know, like from two different angles and I would say both are wrong. And the first one is kind of like it, right? Everything says it's an IT problem, right? And therefore we need to think about IT and their current needs and how we kind of like, you know, like change it. And second, kind of like people saying, well, if I just solve this, you know, let's say Gartner quadrant and my quadrant, which I know you know about, you know, a little bit better, it's going to do the revolution, right? So if I just enable more access to people to data warehouse, or if I enable them to run just more Python notebooks better, or if I just enable better consumption of whatever tableau looker, you name it, it's just going to solve the problem. But I believe this is dead wrong because people have their own bias and they box themselves into seeing, they don't see the whole journey of, you know, they don't have the design thinking, right? They see just, you know, like they put themselves in the box. We do the data warehouse, you know, we do data warehouse virtualization, we do transformations, we do etl, we do whatever. And then they actually think that the whole world is kind of like, you know, that better data warehouse or better whatever. And I just don't think that it really works because like if you, if you live inside the white box, your whole world seems to be white. So what you need to do is step out, think outside the box and really look at the whole journey as a complex journey. Talk to users, talk to them, talk to the end users and see that the typical enterprise has 1100 outside SaaS applications, together with old Oracle warehouses, together with, together with Hadoop likes, together with everything and things like etl, mdm, or different ways of integration, then suddenly become just a method that you need to do to actually get to the target. And so our target and our users, we come from the business users, we come from the perspective of that changing world where this whole data democratization and moving company into agile tribes is not gonna happen. Only with hiring more it. We need to be. We actually have people in business departments who are more and more tech savvy. You know, we have a very, very similar view of the world as Luker has, right? They said, well, you know, I love your, kind of like your podcast with Colin, right? Colin Zima. And he said, well, the guys at Luker did very good thinking in the beginning that, you know, they need to enable more engineering, not less of it, right? Not kind of like click and pause. It just doesn't work. And so, you know, if you look at the statistics, just Data Camp, they have over 3.3 million students. 3.3 million. That's huge. I mean, those are not just IT folks, right? All of those students of Data Camp are people who are within business units. They are the analysts in marketing, they are the guys in logistics, they sit in procurement, they are at risk departments and they need to connect those 1100 applications and, and they are in sales, right? And they want to do something meaningful. So if you can like think about this, for them, just creating better design or data warehouse just doesn't cut it, right? It's all whole journey, insights, data into insights, insights across the whole company. From Insights, there are actions and you need to automate, you know, you need to build machine learning models to automate those actions and the whole customer journey, whole human work, people journey inside the company and that's what we help them do. But we start with business and then we go to it and then it actually tends to love us very dearly because for them they are always thinking, well, they are very smart, all these people and they see, well, if we need to support these thousands of citizen users in the business department, how are we going to do it? We don't have enough people. We can't hire more people because first, there are not enough great people. Second, we don't know how to manage it. So for them, for it, we just become this great tool that enables them to scale business insights and to scale machine learning, creation, automation of processes into every single business department with full control, auditability, metadata. And that's why solving just for one Persona in the whole journey just doesn't work.

So for the benefit of anybody who's never seen Kabulu in action. Just walk us through what a typical development session would look like.

Well, thanks for that. I will just use the Looker Hackathon as an example. But first, when you say people picture, I like to use this analogy, right? Like I remember 20 years ago, you know, almost 30 years ago when I started with, you know, with the IT and development, when we wanted to send email, right, we would have to buy a server, right? Then we would have to install in an operational, you know, system on the server. Then we would have to, you know, install Service Spec one, Service Pack two, whatever, right, Patches. Then we would have to kind of like install the mail server and then blah, blah, blah. And before, before the end of the day when we would kind of like want to send an email, it was like three days of preparations, right? And that's kind of like the way the state of the market that we have in analytics, it's like very fragmented, a lot of different things. If you want to do something, send an email, do an Insight or Automate, you really need to be very technical and spend 80% of your time just putting together that stack, cleaning data. And then fast forward 20 years and then we have Gmail and just like Office 365 or whatever, you just come to a service, you say, I want to send an email. It's an address. You put in the code, your text of the email, you press send and it's serverlessly done for you. You don't have to do anything. And that's such a huge productivity booster or Google Docs. We are exchanging together notes through Google Docs. I see your changes, you see mine is done totally automatically. And now let's talk about our user journey. So for the Looker Hackathon, we came there and we're like, hey, let's do Hackathon as well. What are we going to do? Well, what can we do? Okay, well, what can we do? Where is the data? Well, there's a lot of data on Twitter and on social media and how people talk about this Looker join, right? Well, you know, typically we're like, okay, how are we going to analyze it? Well, I can get some Python library, maybe Hackett, you know. Well, I'm going to start our database. Well, what is the schema? How are we going to do it? You know, okay, well, I'm going to. So for us, you know, we were like, okay, we start from the end. So our end goal was kind of like we want to show how are people talking about Looker join. How is Looker talking about sponsors how are the sponsors talking about looker, what is the frequency, what is the quality of the text, etc. What are we going to need on this journey? Well, first we need to connect to some data sources at some restful API of Twitter, let's say. Then maybe we'll need to scrape some data sources. We need to take the data in, we need to put it in some BLOB storage because we don't know how much of it it's going to be down. Then somebody needs to spin a SQL Server so we can put it structure it from Blob into SQL. What about the coding of that? Well, it's a JSON. Who is going to materialize the JSON and then once it's in SQL Server, who is going to run transformation on that, who's going to clean it, who's going to join it? Oh, by the way, how are we going to know what is the sentinel data? Well, somebody needs to connect Google API for NLP or some other software. Who is going to do it? And before, kind of like you prepare the data for actual analytics, it's days and days, right? Because you need to prepare the whole stack. With us it's totally different. Still the same steps are needed to be done, right? You need to connect the data, you need to scrape it, you need to warehouse it, blah blah, blah. But with us you get one platform, we created a project and they are already prepared Extractors, right? So Twitter extractor. Yeah. Click boom. Two minutes and the data is being extracted. The data that we want, the form that we want it, it's not preset from Twitter and it's being automatically put into our BLOB storage. Then automatically the JSON is being materialized into CSV files which are being stored into Snowflake. So within half an hour you have the data in Snowflake and already somebody can actually, with all the metadata, with all the information, who touch it, who did it and somebody can start actually do analysis and create transformation on that. So actually we got people from other teams actually joining us in that. And so somebody said, well, I'm going to clean the data, I'm going to use SQL. And they went into Kibua, started with one click, a sandbox which actually gave them the data that was already warehoused in the Snowflake, which is connected under Kabula and it gave them separate Snowflake warehouse. So it's just sandbox for them. So they developed in the sandbox environment, they cleaned the data, they joined it and then they registered the code which was Production ready into our transformation folders. And then in the meantime somebody else was in the same project actually pivoting the data using Python. So what they did, they actually went into Sandbox. I want a sandbox, one click. It has to be like with Jupyter Notebook, it has to have a certain amount of memory for it and automatically our API gave them the data from that Snowflake instance. So here you go. At the same time, without touching all those underlying infrastructures, two people with just one click got two totally different sandboxes, they develop, they register it into our transformation layers. And then what about nlp? Somebody else actually meanwhile went into our marketplace where there's over 900 different apps and said, well, there is an NLP app from Genea. One click edit what is going to be the file that's going to go in and what do we want this sentinent scoring positive ok, entities click. And meanwhile data was sent to Genea and received automatically back through Kabula API into Snowflake. So within really just two hours, four people work on that together in one project. And Kebua kept track of every single action that everybody did in this environment because again, all of that was happening on top of the data API and all of the data actions and jobs. I want to run the SQL in the production environment with this data. Then Kebula created a job which was run through an API and we had all the metadata about who did it, what data it touched, how is the data tables, how are they connected together, the lineage and what was the start, what was the result? And so then we just went and just created a Looker dashboard on top of that with one click. We've automated this whole journey. So it would be happening every hour, for example. Right. And so that's how kind of like, you know, it was kind of like done, you know, like you didn't have to start anything, you know, you didn't have to integrate together five different pieces of technology because everything is just provided for you.

So go back to Looker Join In San Francisco last year, one of the major themes of the conference and product announcements by Looker was around packaged applications and building applications, you know, directly into Looker, creating marketplaces and so on. You know, is this, is this something that's kind of a threat to Kabulu? Is it something where it aligns with what you're trying to do? What's your thoughts on that?

No, we love them. We actually, with Looker team, we were preparing in the new marketplace, we are preparing several different applications with Kabula technology which we call Scaffolds. The idea is the Looker is great tool, it's a great platform and they, they have a very big focus on the front end, right? On the kind of like the insights and what you can see how you deliver, how deliver the data experiences to end users, right? Our focus is more on the platform side like one layer below and to automate all of these different, orchestrate all of these different tools, different processes and different people together. And so what we did couple of weeks prior to lookerjohn, we were actually using our scaffold which basically, you know, everything I described about that, you know, like Looker hackathon that we did all of those, you know, analytics you can actually now package together into one scaffold and with just one API call you can call it and just create a new Kabula project for you. It connects to data sources, it scrapes them, it warehouses them, you know, and it, you know, does all of that, you know, SQL code, Python code, calls the Genea and creates a Looker application and all of those dashboards. So now if you go into Looker Marketplace, you know, you can see several of these. For example, there is a whole subscription analytics, you know, with Looker powered by Kibble of Scaffolds, there is a whole, you know, like a user comment, a user behavior, you know, application in Looker powered by Kibula Scaffold. So I think these two are very powerful when combined and I totally subscribe to Looker way because when we want to democratize across the companies, we really need to allow the internal data drive people to actually prepackage certain things for their users so people don't have to reinvent the wheel all the time. That's a big thing. When we see companies go really up to 10% of their workforce doing advanced analytics, we see a couple of things. First, they need templates so they would not have to rebuild the stuff that's our Scaffold and Looker application. Second, there needs to be the automated analytics on the user behavior and in the sense that we want to help the users if they get stuck for that. We are using all of that metadata and activated data that goes from our data API and we have something we call predictive support. Imagine you are the data tribe, you own the data initiative and you see somebody going, trying something and then it just goes down. They don't finish their jobs, are still running with error. We will let you know automatically so you can reach out to them and you can just immediately jump start them. This Works really wonders at the companies. And the third is kind of like you need to play in a wider ecosystem because nobody's going to solve all those 1100 applications Enterprise on their own. So that's where I think Looker is doing a fantastic job and they are enabling that last mile, we are trying to enable the miles before that. And together it plays very nicely as we have experienced.

So another topic we talk about a lot on the podcast is this idea of scaling, analytics and democratization of analytics and I suppose analytics going beyond just dashboards and graphs to be part of a process and part of a workflow. What's your thoughts on this area?

Well, I would say that's the whole reason for being for kibble. Right. So again we did a count and on typical journey that goes beyond dashboarding, but creating the machine learning models and then using the models to actually automate the processes, there's over 17 steps on the complete data journey. From data is somewhere all the way to models are, you know, insights are actually done and the models are created, machine learning models and all processes are automated and then there is a feedback loop back into the system so it can get better and better. Right. And you know how we fit in. We care about the whole data operations alongside the whole journey. So we care about the user experience and scalability to 10% of workforce. And we really are thinking why when we go to companies like there is an example of large financial institution and we started with them and these institutions, they have everything, they have Oracles, they have Hadoop, they have everything. But somehow as you said, it doesn't work together. People were not able to actually scale those analytics or they were able to scale dashboards, but not the model creation and output of those processes. When we come there, we connect to those sources, we connect to Hadoop, we connect to Oracle Data Warehouse and we let the teams connect to their applications. But that's the first step. The second step, which I think is really important and was really undervalued before, is we need to allow the users to create agile tribes. And by definition in agile these are cross functional teams. So in one team you have a data scientist, data engineer, IT person and business person. And together they actually create the whole process. And at the end of the process there is a metric that is kind of like they are responsible for it, it's registered in a data catalog or something like that. And then anybody who wants to shop for data or use that metric in their dashboard or in their model, they can actually see who is responsible for it. How it got created and mainly in which other processes it's already being used and if the data is getting old or if it's fresh. And this kind of changes the logic from only tiering the layer on top of the layer, integration on top of integration, until everybody loses the context. This agile approach, on the other hand, gives people the context. They own the context and the technology is supporting their processes and the processes are supporting the people. So in typical the DevOps manifesto and when we go to this large filing transition, we actually introduced Kevila, we connected to Oracles, we connected to Hadoop, we let them connect to their, you know, like for example, Risk guys, to all of their, you know, external sources from, from, you know, out there. And within six months, people in 14 different departments, you know, started to use Kibura not only for dashboarding, that was the first time, but they started to actually create what we call business data apps. And business data apps is the, you know, like, yes, you can use the scaffolds to automate, you know, recreation. But mainly it's like what you talk about, right? The whole process from acquiring the data, putting some logic into it, enriching the data, yes, looking at the insight, but then creating action and using those actions to automate the processes. For example, one of these apps would be in the risk department. They wanted to kind of bring down the fraud. So they actually created a business data type on top of Kibua, which helped them to actually get from users the IDs, right? Then they would use the recognition software as an app on top of that which would say it's a male, female, what are. They would read the name, surname, they would read the exit files and all that they did to compare it with the database of stolen IDs, which were kind of like used for fraudulent actions. So they wanted to kind of, you know, decrease the probability that somebody is using fake id. And at the end, you know, they actually had, you know, the list of white labeled IDs, kind of like not used in fraud, right? And all of that, you know, they created within four hours. And you know, the result of this business data app or workflow automation is a clean data set that can now then be used, you know, in multiple other, you know, use cases within the company. And this is the power, you know, like another example is kind of like the data app, you know, people with CRM department, right? They would actually first connect the data from different sources, mobile, web, you know, there's CRM, erp. And they would look for people, you know, like insights, you know, looking through to dashboards, right? Hey, where are the groups? You know, how can we, what can we. You know, they would start thinking about questions, right? And then within the same environment in Kibbula, they would actually create, they would create the next best offer, right? They would invite somebody from data science department or they would already have someone or somebody external and they would create that. And within just a couple of clicks they would actually automate the whole journey. So now the data comes in automatically, it's clean, it's being compared with CRM, erp, it's compared with some credit, some scoring of their and then next best offer. And the system kind of model decides, should I contact this person via email, via SMS or should I give it to call center? So they would contact them and before it gets sent or orchestrated by Kibua, there is the risk model which we talked about previously, right? And that's always updated within a minute and it says, well, this is the risk portfolio, we can do it or we cannot do it on the fly. It has to go for, you know, recheck. And again, this is another example. So these are, you know, like things when you, when you ask me what is the secret sauce, how to actually change that scale of analytics, I really think it's kind of like think about the whole journey as you know, from a design perspective, from the user experience perspective. Right. And you know, I change into data ops mindset with agile teams, DevOps techniques and lean manufacturing processes in the production cycle. And you know, like, if you don't think about the whole journey, then you're just like optimizing for local maximum. You know, if you think about, oh, we can do the ETL process, you know, the best. Well, you optimize for local maximum, which is one of 17 steps of journey. So it's very helpful, it's very helpful, but it's helpful for that particular part of the journey and that particular Persona. So our approach is kind of like we look at the whole data operations and we care about the user experience and the collaboration of users and if they use in those 17 steps, if they want to use, let's say for the model creation R or Python or matlab or Julia or databricks, we don't really care. We care about what is their experience and what data intelligence we keep in the process and how we abstract the users from actually having to run the systems themselves.

So many of our listeners actually are consultants or working a consultancy or independents and they're probably thinking, well, is Kaboola something Actually that would replace us on a project. You know, is the whole point of a tool like yours to actually do away from the need of a consultant or a partner to help with the.

Implementation that Mark says? That's actually a very good question. We get it a lot and you know, like, no, totally no. It just allows you to do more interesting job because like what we have actually seen, you know, a lot of consultants would kind of like, you know, like start and help with integrations and stuff. And for that, you know, the budget would be kind of like used, all of that. And before they get to interesting stuff, the clients are like, oh, should we spend all the money with us, you get there faster, you know, you save that budget and actually you can do interesting stuff. You can move from that initial dashboarding to actually what you said. You have the money, resources and time to spend it on actually scaling the analytics across the organization. Just to give you a number. In our typical implementation, we are very, very partner focused. You know, our professional service has just six people globally. That's it. We do, you know, we do a lot of, we do a lot of architecture, but mainly we are there to support our consulting partners. And so like when we go, you know, in the first phases of the project, let's say first year in the large company, the amount of money to be spent on Kibua, you know, compared to amount to be spent on services is one to six. So actually we can see how much more it actually creates because we unlock the data into business department. That's a fundamental change because then business people actually go, they have problems, issues, challenges, they try something but ultimately they don't want to spend days and years, they want to innovate, but then take it into operations. They actually call on the consultants more and more and more. And that's been great, you know, like there are several companies, you know, around Czech Republic that started with us. You know, they were our clients originally and there's at least three, four companies I can think of now, and they actually scale their business from one to 20, 30 people within one and a half years, you know, and that, that is. No, we love, actually, we love consulting partners because they are the ones who can, you know, bring the context and who can keep the context and they have the fundamental skills.

So Pavel, just to wrap things up really, how would people find out more about Kaboola? Maybe download the product or find out some more data sheets or background information.

So we have a website, www.kebola.com. we actually, if you are technical, you might really like our nerdy blog which is 500.keboula.com internal server error there you can read a lot of things about how we actually program Kabula, etc. We have a GitHub Kabula where you can read a lot of code if you really want to read business. Kind of like a related blog post. It's blog.kibua.com, twitter, obviously Facebook and we are trying to do a lot of community events. A lot of hackathons we support, a lot of hackathons we create. We also have started several years ago with one women in tech group. We started the group for teaching females how to do data 101. It was originally called Data Girls because it was at little girls. It kind of grew and new initiatives started on top of that. She loves data in Asia and that initiative now has over 10,000 people went through the initiative, which I love. It's one of my most favorite things to do and stuff like that. Yeah, we try to be at the conferences and my Twitter is Pabu P A B U01 where I try to publish interesting stuff but yeah, really on the Internet. And you can also go to try.kabula.com and if you use the code guide mode you will actually get a free project for 14 days with guide mode already in it. So you can actually test all of this and see if it's. Yeah. What I say.

Pawel, it's been great speaking to you. Thank you very much for coming on the show and great product and take care and hopefully see you at some point in the future.

Hey Mark, it's been a real pleasure and thanks for inviting me here. I really love your show as I said and you know, you have a great weekend. Thank you. Sa.