In this episode of How We Made That App, host Madhukar chats with Jack Ellis, CTO and co-founder of Fathom Analytics, about their revolutionary approach to web analytics prioritizing user privacy. Jack discusses how Fathom's platform, which omits personal data post-processing, challenges traditional cookie-based tools like Google Analytics. Jack touches on technical challenges faced in building a privacy-centric service, alongside insights into web development practices and the evolving landscape of AI integration.
In this episode of How We Made That App, host Madhukar welcomes Jack Ellis, CTO and co-founder of Fathom Analytics, who shares the inside scoop on how their platform is revolutionizing the world of web analytics by putting user privacy at the forefront. With a privacy-first ethos that discards personal data like IP addresses post-processing, Fathom offers real-time analytics while ensuring user privacy. Breaking away from the traditional cookie-based tools like Google Analytics. Jack unpacks the technical challenges they faced in building a robust, privacy-centric analytics service, and he explains their commitment to privacy as a fundamental service feature rather than just a marketing strategy.
Jack dives into the fascinating world of web development and software engineering practices. Reflecting on Fathom's journey with MySQL and PHP, detailing the trials and tribulations of scaling in high-traffic scenarios. He contrasts the robustness of PHP and the rising popularity of frameworks like Laravel with the allure of Next.js among the younger developer community. Jack also explores the evolution from monolithic applications to serverless architecture and the implications for performance and scaling, particularly as we efficiently serve millions of data points.
Jack touches on the convergence of AI with database technology and its promising applications in healthcare, such as enhancing user insights and decision-making. Jack shares intriguing thoughts on how AI can transform societal betterment, drawing examples from SingleStore's work with Thorn. You don’t want to miss this revolutionizing episode on how the world of analytics is changing!
Key Quotes:
Timestamps
Links
SIN008 _Jack Ellis_Transcript
[00:00:00]
Madhukar: Welcome to this episode of How We Made That App. I'm your host, Madhukar Kumar. I started off my career as a developer and then eventually moved to product management and finally into marketing. I love to talk about technology and software engineering. Today, we have with us Jack Ellis. The CTO and co-founder of Fathom Analytics.
And we are going to talk about Laravel, Generative AI, and the importance of databases in building applications. Welcome Jack. So first and foremost for starters, somebody who doesn't know, could you explain what Fathom is and what's your role at Fathom?
Jack: Fathom Analytics is a privacy first Google Analytics alternative.
We run our analytics without cookies and we still allow marketers to [00:01:00] see what's going on without invading user privacy. That's the top tagline of what we do.
Madhukar:And your role is you're the CTO and co-founder, is that right? How long ago did you start Fathom?
Jack: Wow, I think we're six years now. It's been a long time. Yeah, that's weird to think about. But yeah, about six years ago.
Madhukar: And given that for web analytics, mostly people tend to use Google Analytics because it's free. What made you jump into this? And, you know, build out FADM.
Jack: Lots of things were happening with regards to consumer privacy, and people were learning that if you're not paying for the product, you are the product quite often.
You need to see that there's something that is perhaps going on there. Why is Google giving it away for free? Google is an advertising company. It's not doing it out of the goodness of its heart. And people were starting to see this. And so when we started selling analytics, people, you know, they were a bit hesitant to pay for analytics, but over [00:02:00] time, people have started valuing privacy over everything and they would prefer to use that than to use Google.
And so it's just, it's compounded from there as people have become more aware of the issues and people absolutely still will only use Google analytics, but the segment of the market that is moving towards using solutions like us is growing, which is very exciting.
Madhukar: And do you typically compete mostly with Google Analytics or are there other paid tools that you compete with as well in terms of privacy and web analytics?
Jack: That's a great question. We are focused 100 percent on competing with Google. We have obviously noticed that some of the bigger players have seen Fathom Analytics growing and getting lots of publicity. And they are, from a marketing perspective, they are, They're bringing in similar positioning to us.
So suddenly they're GDPR compliant, but those competitors are often GDPR compliant in their marketing, but not actually in their DNA. Whereas we are, we're at privacy first from the start and yeah, Google's our main focus. We're going after [00:03:00] their entire market share in the analytics space.
Madhukar: And to be honest, I am a customer of Fathom Analytics as well as a marketer.
I love it because of two things. It's simple, and it is extremely snappy and fast. Simple, I like the fact that, you know, I can see it in real time. I can see by the pages. I can see it. The traffic by the different UTM parameters, but talk a little bit, and by the way, I love the fact that a few months ago, you also added the feature where I can just import all my Google Analytics data as well.
Jack: Yeah, that was fun.
Madhukar: So one thing I'd I wanted to understand a little bit more is when you say privacy first, what is it that's different in the way you collect data? data. Is it, I'm assuming it's still through a tag that you put on the website or could be through any tag manager? And do you specifically not pick up certain kinds of data? Like how is it connected to privacy first?
Jack: Yeah, so this is a great question, very technical question too. People became used to Google's opaque ways of processing data. They weren't sure what data was being stored, how long were they keeping the IP address for, all of these other personal things as well.
And we came along and we basically said, we're not interested in tracking Person A around multiple different websites. We're actually only interested in person A's experience on one website. We do not, under any circumstances, want to have a way to be able to profile an individual IP address across multiple entities, and so we invented this mechanism where the web traffic would come in.
And we'd process it and we'd work out whether they're a unique and whatever else. And then we would discard the personal data. The only time we actually kept logs would be if we were attacked like a DDOS attack, we would then keep those logs. And so we produced this very GDPR friendly solution, which just hasn't been a thing on the market and people can now use [00:05:00] us and still remain GDPR compliant and not have to use cookies, which people do not want those cookie banners, right?So marketers hate them.
Madhukar: Yeah, and in that case, so if I am understanding this correctly, you do have the session variable, and you know if it's a brand new session or a existing session, but at the same time you don't Tied to an ID. So you still manage to see what are the unique sessions, as well as the visits, without tying it to a specific IP address. Is that correct?
Jack: Yeah, we fully anonymize that. So you can't even brute force to get who that was. We get rid of the IP address as soon as possible.
Madhukar: I remember when I started off in my career as a developer, in fact, fun fact, I, Started off as a database developer, and then the first web application that I wrote was on PHP MySQL.
So, I'm very intrigued, and I'd love to talk to you more about Laravel and PHP and [00:06:00] so on. Yeah, sure. But let's take a step back. Like, you created Fathom Analytics about six years ago. Like, what was the architecture, or how did you go about thinking about how you're going to build? Because this is obviously a non trivial challenge.
You have Millions and millions of data points, hopefully coming in from different customers. You have to normalize that data and then you do have to produce it to show it to the different users and at the same time maybe maintain some multi tenancy so that you have some barriers across the data. So how did you think about it?
Like, did you think about okay, I'm going to have a Backend and I'll have a front end and you chose the stack for a certain reason. Help me get through your mindset of how did you go through that journey?
Jack: the truth is that we were focused on getting to market. From day one, we wanted a highly available solution, so we were looking to pay extra for that standby or for that, whatever it was, just to have that [00:07:00] high availability.
There was never one database machine. We really just stuck with what we knew and that was. PHP and MySQL and we went with RDS and we'd be scaling it up and trying to get it to handle our workload as it grew, but the breaking point was, I still remember this, we had a universal basic income campaign go live in Germany and So much traffic hit our servers that the IOPS became completely saturated and in RDS you've got to, you know, either you buy provisioned IOPS or you scale it up and then you have to upgrade the disk to get more IOPS and then you can't downgrade.
It was a mess and it was a horrible day for me to just see RDS struggle. And then we upgraded that all thinking, Oh, we've solved this problem. We've got more IOPS. We then couldn't do high cardinality aggregations. And to illustrate this to the people listening, I know they're probably database people, but for those who aren't, we had a customer called JS Fiddle, and it was a [00:08:00] JavaScript snippet sharing website.
They had Millions of unique path names. So when you ran select some, and then the path name group by path name and order, MySQL couldn't handle it. It's just not built for this kind of workload. And we ran into huge problems there. And the final piece that really kicked us, and it's not, it's a non issue.
Now we use SingleStore. That's a whole other story, but a customer. Churned and so we tried to delete their data and deleting millions of rows in MySQL. You don't want to do that. You know, people come up with all these ways of batching it. We struggled and our database lagged and it was late at night and we were having problems.
Yes, we to think about that now, but that was a huge problem. MySQL caused us so, so much pain.
Madhukar: I think the key takeaway of what I'm hearing is when you do group and, you know, [00:09:00] sum, those kind of aggregation functions, that's when typically the data volume and the scale starts to get out of hand.
Do you feel like for people? You know, when I start building any application, my default is, okay, let's just go get Postgres or MySQL, and then just like you would go with PHP, I'll probably go with either Python and then React, right? So, we'll get to the front end side of the things in a second, but typically in MySQL or Postgres, other than what you just mentioned, which is the aggregation functions, is there some sort of a scale that starts to break?
Is it like 100 terabytes or? 100 million rows, or is that not a standardized way of looking at when to scale or when to break out?
Jack: It's funny, and we weren't, I don't believe we were at even 100 million rows. We were at a small amount of rows, and just doing these basic aggregations group and group by, we had all kinds of problems, and then we had to [00:10:00] introduce these background tasks just for these customers because they had a few million rows.
It couldn't do it. And this is before we added filters. If you were to filter that data as well, even with the best indexes possible, we still had issues. And so, it's You know, nowadays I don't look at it as how much data is it going to have? I mean, sure, if it's a really small application, use whatever database, but if you're planning on growing this thing, I think I would start off with a database that's suited for the mission from the start. That's just my view nowadays.
Madhukar: Yeah, I remember I used to work for a company called Optimus, which incidentally were all, they were also doing A B testing and had web analytics as well, and there was a team of five people. That were just there for optimizing MySQL. That was their full time job. And all they did was partitioning, and sharding, and redistributing workloads.
So I [00:11:00] painfully remember, but I could never figure out, okay, where does it go? Break. And I've heard from different people that it also is about multi tenancy. So, for example, if I have a very large table and I have 500 different customers, I have a different ID for them, and as soon as I filter by the customer ID and one of them is a bigger one, it starts to slow down.
So let's move to the front end side of things. You said PHP. One of the interesting things that I've heard quite a lot, and I don't know if that's changed or not, is 25 percent of all the website is built on WordPress or PHP. Is that still correct? Do you still see a lot of PHP for new applications?
Jack: Do you know, for PHP, I mean Laravel is Arguably one of the best frameworks in the world right now.
Even if you are, I mean, Next. js is absolutely incredible too, but you add them together, Laravel is, it just has everything, including front [00:12:00] end tooling as well, such as Inertia. js to use React and Vue. js. The WordPress dominance is still quite substantial. I know that gets grouped into PHP, you know, it's a different, Subsection of the PHP community for sure the Laravel community and peer and the WordPress community are very different communities.
But PHP is a very popular language. You definitely have different sections. You have the, what I think of as the professional PHP developers who have really fancy with structuring their code. And then you have the people that want to ship a WordPress website and bring in some plugins and get going.
They're very different people, but PHP is still very popular.
Madhukar: One of the things that I remember when I was coding and PHP, was the fact that you can mix and match code as well as the front end JavaScript in the same page. Oh yeah. Is, I'm assuming that's no longer true because there's clear separation, but what do you love about PHP, both in terms of performance, but as a [00:13:00] developer, what are certain things that it gives you, which probably you don't get in next Js or even in React?
Jack: Yeah, and I suppose I should clarify that. So the PHP, the language. I'm not that interested in that. I'm interested in Laravel. To me, Laravel and Symphony, those are where it's happening in the world of PHP. And I don't believe that PHP would still be as strong as it is now, if Laravel hadn't come into the picture.
From Everything, the whole ecosystem is so powerful. You want to have background workers and defer your workload to not destroy your database or to destroy external services and work with rate limits, put it into the background, put it into a background job. You want to have authentication and have it set up within five minutes.
Laravel has something for that. It has things for everything. Basically the founder of Laravel is Taylor Otwell. He runs a multimillion dollar company, Laravel LLC. And so what happens is. As he runs into real world problems in his own SaaS, [00:14:00] he then brings them into the framework for free. And so it has this cycle that then improves our lives.
Because we run into things, oh, Taylor's already run into that when he was growing his SaaS. And that continuation has just been beautiful and is what I think has driven the framework forward.
Madhukar: So would you say that the Laravel community is as big as maybe Node or JavaScript? Or do you think it's, A different approach with a different set of community members.
Jack: Oh crikey, I am not sure on the sizes of those communities. I think a lot of the younger dev, it's tricky to not, a lot of the younger developers are going into Next. js. I think company, some of the JavaScript companies have got very good marketing and are getting in front of them. I think, you know, I look at Rails, Rails feels like this sort of old school approach to website applications and you've got the older generation using that.
We see a mix in Laravel. You know, I'm in my 30s. I'm relatively young, I [00:15:00] suppose. I'm using Laravel and have been for years. We are still seeing people 18, 19 coming into Laravel. But I do think Next. js does dominate the market in terms of awareness, I think. Would you agree with that?
Madhukar: Yeah, I think so. I mean, from a marketing perspective, every company that I worked with till about five years ago, or four years ago, they usually start off with WordPress.
They would have a PHP developer building plugins or using off the shelf. And then I started to see the shift with Gatsby, Netlify, and then and then, of course, Next. js. So now I see more and more. Companies, at least the startups, they use Next. js because they usually have a developer that knows React.
And then now it gives you both the server side as well as the front end as well in one package. But you mentioned something about Laravel and Symfony. I'm not familiar with Symfony. What does Symfony do?
Jack: It's also a framework and Laravel does use components of Symfony [00:16:00] to deliver Laravel framework. It's a very old framework.
It was around when Zend framework, I don't know if you're familiar with Zend framework. So it really goes back and Laravel came after Kohana and Kohana was a great framework which came after Codeigniter, which I'm sure you're familiar with. And yeah, it's been, I think Next. js, it's tricky to get a true perspective because Twitter is dominated by.
People talking JavaScript, but I still have people messaging me asking for help with Laravel things, but then I'm also in the Laravel community, so I'm going to have a skewed view on this. It's hard to be objective here for sure.
Madhukar: And what about in terms of, so there's of course the features, but also in terms of performance, in your personal experience, do you find Laravel more performant, less performant, about the same as JavaScript frameworks?
Jack: That's a good question. I don't think that Node. js is anything special on the server side. So I think if you were to say, oh, I'm going to run some C or some Rust, then yes, that's going to destroy [00:17:00] Laravel in performance. But I actually wrote an article called, Does Laravel Scale? And I concluded that the bottleneck for most applications is not your web framework.
It's always your database. And I ran through Wikipedia's numbers, Facebook's numbers, and I said, it doesn't matter. We can add compute. That's easy peasy. It's always the database every single time. So stop worrying about what framework you're using and pick the right database. That's actually going to has proven that it can actually scale.
Madhukar: And in terms of the architecture, then like the deployment architecture. So do you end up doing like. Multiple EC2 instances of Laravel, and then one common API gateway that talks to the database, or do they all talk to the database, or are these microservices? How have the, how did you start off with, and has that evolved over a period of time with the things, how architecture has changed?
Jack: Okay, I love your questions. This is so fun. [00:18:00] Okay, so, We started off Monolith application, Laravel, it was running on Heroku, I believe, fully managed because we don't want to manage EC2s. We progressed towards using Lambda. At this time, we are currently using Lambda for each page view that comes in. And I know people are going to be confused about that, but it is economical for us.
It comes in, we process it fast and it's working well right now. However. If you'll allow me to talk about what's coming up, we are currently prototyping, this is so exciting, we're prototyping Ingest to be able to handle 1 million requests per second with zero provisioned infrastructure and we're going to be doing that All with AWS's managed services, and limit increases where we need them, and S3, and SingleStore.
And it's the functionality that our database provides us with the pipelines is going to make this [00:19:00] incredible. We can scale this to the moon. And I said to my co founder, we're not going to have to worry about scaling anymore. SingleStore has been Can scale up to some ridiculous amount of requests or entities per second, read them in from all of Amazon's managed stuff.
We're going to be laughing. And then we're just left with the monolith on Lambda, which is much lower scale and it's doing that, you know, the custom dashboards and the API requests and aggregations. So we're going to be in a great place.
Madhukar: And that's so many more questions based on what you just said. So you mentioned Lambda.
Now the front end. Is that somewhere else? Because I'm assuming the Lambda is your kind of the back end, which is talking to the database SingleStore in this case. But what about the front end? Like Is that something else altogether?
Jack: Yeah, so we're currently using InertiaJS with VueJS. Ah, okay. We are going to be moving back to EmberJS though, which is a, it's an interesting decision.
I have a lot of [00:20:00] experience with it. The other engineer that works on that has a lot of experience. experience in EmberJS and it feels like it's going to be fun and help us deliver the fastest application. Right now, we are serving the initial page load from us east 1. We want to reduce that time to first byte for all of our users, so we can serve the EmberJS compiled app as a static asset and it's just going to feel faster.
You know, if you're in the EU, this came from me, I flew to the UK. Oh, Fathom's. And then I realized that it was waiting for that time to first bite. So we're going to start serving that via a CDN with no server side request to get that initial state.
Madhukar: Very cool. And you mentioned, of course, the fact that you're looking to scale up to a million.
Requests per second or million rows per second for ingestion. What's the typical use case for that? Are these very large customers who are bringing in data or is it streaming data? Or is [00:21:00] it just website but they are just generating that much request per second?
Jack: Our workload is the sum of all of our website's traffic, right?
So we, it just keeps going up. Every time we see however many new trials, that's going to then compound whatever growth we currently have. And the big customers do stay around for a while, you know. We're expecting that to go into the tens and hundreds of billions of requests a month, and we have to be ready for that.
And it isn't all nicely spaced out. If it was nicely spaced out, that's easy. But we have moments where multiple sites can go viral at the same time. And then in addition to that, we have to be able to handle various DDoS attacks that may come our way. And we don't want to, we would rather absorb that attack.
Get credited on Amazon or whatever they do, then go offline. And this is why I'm so stoked about this new infrastructure that we're doing.
Madhukar: Very cool. And do you, you know, in, in terms of also the progression of how engineering and engineering practices have changed, [00:22:00] of course, one of the things that really excited me a couple of years ago was when we were building out this entire Marketing website, we built it first in Gatsby and then moved to Next.
js. I love the fact that you could just do deploy on demand, or you could, you know, publish on deploy, where I have a bunch of, you know, feature requests, and then instead of waiting for a release, I keep deploying, and then Continuous integration, yeah. Is that something you have also adopted and started to do, and at which point?
Jack: Yeah, we have that. We can deploy within minutes. We definitely don't do the release approach. I'm very grateful for this continuous integration thing. That has been most of my development career. You know, In the early days, we would FTP or SFTP into servers and copy around the files. We're now at continuous integration where we can run tests as we deploy, but still ship it really fast.
Madhukar: Yeah, that's phenomenal. I remember I used to do this in Dreamweaver. [00:23:00] And I don't think Dreamweaver even exists anymore. And it had its own in built FTP and SFTP and fun times. They're good old days. So one thing I wanted to understand was in terms of the team structure, right? Like when you work with very large teams, and I've seen the teams become leaner in certain places.
How did you structure your team over a period of time? How big is your team? Is that something you can discuss?
Jack: Yeah, our team's very small. So our team is two full time engineers and then a handful of freelancers and then privacy law wise. Yeah, it's very small and we're very focused on individual things, you know, to be able to move as fast as we do.
And then outside of that, we have full time customer success. That's something we invested in because we think that's important. I suppose with my co founder, his background is working with big companies around their marketing content and design. So we've got that handled from him. And then we prefer to work with contractors as [00:24:00] we run into things that we need.
I have, we've discussed this about scaling our engineering team. I think right now we're so one thing at a time focused and trying to scale out a development team, an engineering team would be something. We're not experienced in doing and I think it would cause more harm than problems it's going to solve.
Madhukar: We've had so many discussions with other people and we have often wondered, do you think we'll ever get to a place where somebody builds a unicorn when the one person is the CEO as well as the engineer or whatever is the definition of engineer at that time?
Jack: You know, and I think we're more likely with AI that's going to change a lot of things I think.
It's got to, right? I mean, this is going to be. The age of the two person or one person unicorn. And so, yeah, we're not building a unicorn. You know, I know it used to be a sort of dismissive term, but I'd say we're more of a lifestyle business. And we've grown every single month since we started. But our growth isn't, we're not trying to get [00:25:00] millions and millions of users.
It's quite a slow growth, a slow and sustainable growth. Although I wouldn't necessarily call it slow by We've grown fast, but we're not doing VC growth, and it's very calm, and yeah, we enjoy running it that way. It's different to most tech businesses.
Madhukar: And it looks and feels like it too. Like I said, it feels so snappy, easy, elegant.
It almost has like an Apple like experience to it. And, you know, it's, it doesn't feel like, oh, I have 20 different reports, and what do I do to do this versus that? I think that's a, that's one of the things I'd love to hear your thinking about user design. I've seen that the more features you add, the more complex it becomes.
So, over a period of time, you're building for new users, not your existing users. How do you think about features and product design in general?
Jack: So I can tell you, and thanks for that by the way, I can tell you that we are currently building a new version, a named version 4, because we've been adding features to [00:26:00] the current user interface.
And it's become very overwhelming in certain areas. I know the dashboards, You know, nice and calm, but the settings and people are wanting more things. We've got a brand new version coming and it's specifically designed to house these new features. And so we're going to keep what we've had, what we have currently, combine it with the feedback we've been receiving from existing customers and new customers that are coming.
Aren't quite convinced they need something more such as the marketers that want to see funnels, right? How do we bring in things like entry pages, exit pages, and that sort of thing. My co founder is an excellent designer and he is a kind of a minimalist at heart and he will just design such a beautiful and simple thing to use.
And then my job is to make it as fast as possible. And I'm not, it's no secret that I love SingleStore and it's going to help us make things very fast. There have been a few new features that we're excited to use that is going to speed up our dashboard even more.
Madhukar: So let's linger a little bit [00:27:00] on that, on the database side of things, from your perspective, given your background and your experience.
What do you think are some of the key defining features of a database when a developer is choosing it? Like, if, like I said, today, when somebody goes and builds an application, it breaks my heart that they use MySQL. Why would you think somebody should choose MySQL? should choose a different database like SingleStore and what are the main reasons for them?
Jack: Yeah, it's funny. I, and I used to think that, you know, you're doing analytical workloads. That's when you use SingleStore, but my opinions changed because if you're using an exclusively OLTP database, you might think you're fine. But when you're trying to make mass modifications, mass deletions, mass moving of data, OLTP databases seem to fall over.
And I, you know, In my course, I still remember the video, I had RDS side by side with SingleStore, the same cost for both of them, and I was showing people how [00:28:00] quickly SingleStore can do stuff that makes a huge difference, and it gives you confidence, and I think that you need a database that's going to be able to do that, so I mean, I would use SingleStore for any new project that I'm doing, that's just where I'm at, it's going to scale on the OLTP side, the OLAP side, and it's got bucket loads of features.
That it's just there when you need them. We've never used pipelines and we stumble across this. Oh, what's this feature? And it's now going to help us grow and scale. It's got the things that you need once you get there, but it's also a fantastic starting point as well. And the pricing is reasonable, especially when you compare it to RDS.
So I'm excited and very enthusiastic about choosing SingleStore for most use cases. And that's me being completely truthful. Yeah,
Madhukar: I mean, for me the key exciting part was about a month or so ago when we actually had the first free version, which is free for life. So you can build a Next.
js app or you can build a Laravel app and now keep it in your developer environment forever and you [00:29:00] get the same or better bang for the buck if you were to do it with any other database. So speaking of, you know, no other, no. Conversation about technology or anything these days is completed without generative AI.
So let's talk about that. How are you thinking about generative AI, both using internally and then also from a product feature perspective? What are some of the things going through your mind?
Jack: Yeah, so. After version four is really when we can start stepping into this. I think that a lot of people like to collect their analytics data, but they want to be told what to do next or given some ideas and they can go and research that, but how good would it be if we had complete, what we do, complete insight into how people are using their website and what people might want more of, and we can then bring that in and help give them ideas.
So I think that's going to be a huge unlock for us. We haven't spec'd it out yet, but I'm excited to try and do that. I don't know how that's going to look in terms of how data moves around and where it goes. Does it [00:30:00] get sent over to OpenAI? This is a new area for me, but I'm trying to keep an open mind and think about what's possible.
Madhukar: And when you think about how people might engage or interact with that data, again, from maybe a design perspective, do you think it's more conversational or is this something that is Pushed by the application to the user in a highly personalized way, depending on what they have done so far.
Jack: Yeah, and I can definitely share this.
I was talking to my co founder about this. He likes the idea of surfacing emails, which is what's going on, what's working well, what's not worked, what's changed and those sorts of things. And you can start to do some of that with the right database without AI, but as you want to get more creative with what they can do, that's really when I think AI steps into the picture.
Madhukar: And in terms of you using. Generative AI as well. Have you started looking at things like CoPilot or anything that does code generation, but maybe even debugging and something
Jack: beyond that? You know, [00:31:00] yeah, I have used it and I do like it. I'm a sort of love hate with this. I find CoPilot is great for predictable.
Coding. A lot of my workload recently has been solving complex problems where there isn't someone has not written about this on Stack Overflow. It's where I need to start talking to experts to get them to help and it hasn't helped me on the more complex stuff, but people talk to me about What's it called?
Cursor? The IDE? Yeah. And maybe, I'm trying to keep an open mind, but I have a kind of mixed relationship with those tools.
Madhukar: Yeah, I used cursor quite extensively because it's a fork of VS Code and you can bring in your own OpenAI key. But I have to say, I've now moved back to the JetBrains. And they have some really good AI features as well, because it's in context.
It can look at your repository and code, and you can, you know, engage with it. Speaking of going back to the web analytics piece, one [00:32:00] thing as a marketer I would love to see is if I can talk to my web analytics data, or any data for that matter, in natural language, like, hey, tell me how many people are on my website right now, and how many are Currently engaged or things like that would be really cool.
Jack:Will you tell me, I mean, what's SingleStore doing with AI? Where do you see, it's no secret, I love SingleStore and we're continuing to use it. Where do you see what SingleStore is doing, fitting in to help our customers? Yeah, I
Madhukar: mean, of course, the first one is around semantic and vector search, where we had an exact K and N vector.
Search support since 2017, and then more recently, we added a few other, which is exact, not exact, but ANN, with PQ, Product Quantization, IVF, Inverted Index, and HNSW, which is Hierarchical Small Navigable Word. So it gives you, if you bring in unstructured data, you can get back like [00:33:00] incredibly fast results on meaning based search.
But what. What is, I guess, even better is that you can combine that with the SQL group by and filter by. So instead of going to a vector only database like, you know, Pinecone, for example, then doing the search, getting back the ID, and then looking at that metadata from another database, you do it in one single thing.
SQL. So you do both SQL plus Vector. So that's one. But what's been really recently on my mind, which we are still looking at and working through, is so far everything has been in the database world has been around taking the data to the large language models, right? And it's typically through unstructured curation of the data.
And what's been intriguing and on my mind and there's been a lot of discussion is what if you brought the LLM inside the data? And what are some of the crazy things you could do with it if you put [00:34:00] like a very natural but an extremely fast API layer? So, in short, a bunch of different things that we already have and a few things that we're looking at.
So, from your perspective, Jack, I'd love to hear from a developer perspective, from a maker perspective, what are some of the things that excites you with GenAI, which could be part of the database? Or the overall
Jack: stack. So where I actually get really excited about AI and especially the database stuff that's going on, I get excited for healthcare.
I know that's away from what I'm working on, the future of healthcare. I have all these visuals. I speak with my doctor friend who's also a biochemist. And I imagine using something like SingleStore somehow modeling. Human health, biochemistry, and everything else and think of the developments we can get from combining it all that's honestly where I get excited.
I think there's huge advancements that can happen there. I think there's so many other areas that I haven't even thought about, but [00:35:00] healthcare is something I get passionate about that diagnosing correctly and that sort of thing. And I see SingleStore as. It's something that can help out in the future.
I mean, the work that Singlestore does with Thorn, with protection of children, I mean, my wife has worked in that area that's huge! This is changing the world for the better. And you guys are launching features to help that. So I get excited about that stuff, about improving the world in that way.
Madhukar: Thank you, yeah again thanks for saying that. One of the things that blew me away And when I joined was we have a customer and that customer now, yesterday I was talking to him, they have two petabytes of data in signal store. They're still using object storage. And the crazy part is they're building an entire knowledge graph.
using simple joins and groupby, filterby. And they're like, well, I don't even need a graph database because this is 70x faster. Like, forget 1 or 2x [00:36:00] that's saying 70x. So based on that, I feel Personally, I'm very excited, just like what you said, like, you know, if you could do a lot more in, like, orders of magnitude, lesser time, it helps you with, you know, designing new medications or just improving the amount of productivity for doctors.
Like, here's a crazy statistic. Somebody told me that a 70 percent of the time taking notes. And inputting it into some system because of insurance and whatnot.
Jack: So that industry is ripe for disruption, and I think technology and databases, SingleStore, are going to be a part of that combined with AI.
Doesn't mean that doctors are going to go, but I think it's going to enhance the doctors. So I'm Really excited about that. Some of the things that doctors miss as well. They'll miss things and then people will die and this is people's lives. And if we're able to use data and database, powerful databases, powerful AI [00:37:00] to solve that, that my whole body is filled with excitement when I picture a future.
Madhukar: Yeah, absolutely. I'm looking forward to what are some of the things that we'll be able to do. All right, last three questions, Jack. What are some of your favorite Other than Fathom Analytics, what are some of the things that, that you really love?
Jack: Oh, crikey. Okay. So, I mean, this is really boring, but I like Fastmail is an incredible email app.
The SPA they've built is absolutely awesome. Oh, this is a weird one. I don't, I use business apps. They're all really boring. I mean, like, the Stripe dashboard is fantastic.
Madhukar: Yeah, that's great. Well, second question. What does a typical productive day look like for you? Like, do you, are you an early riser? Are you a night owl?
What does a typical productive day look like for you? So,
Jack: productive [00:38:00] day for me, wake up, Lower carb breakfast, you know, eggs or something come into my office. My phone is over there. My computer is locked down to the things I'm going to focus on and then a clear agenda for what I'm going to get done.
And then I'm going to focus on that until it's done. That is my. Best possible day. No Twitter, no nothing. Out of the way and focus.
Madhukar: Those are my best days. That would be my dream day. If that only lasted for two hours, it would be great
Jack: for me. You're a CMO. You've got loads of things going on that you're juggling.
Madhukar: Alright, last question. So, if you were to tell a developer who's about to go build out a brand new App, Gen AI or otherwise. What would your advice be? Both, you know, it's a little bit much larger question, not just a tech stack, but where would you say pay the most attention
Jack: Make sure you're validating the problem.
Do not build for months. Get some feedback as soon as possible. I made a mistake when I was younger. I left my job, [00:39:00] worked on my app, and I never got a single customer or a single payment. I actually made more money from some random thing I created and sold in a few hours than I did on that. So get validation as soon as possible.
And with regards to your tech stack, I'd advise going for things that are tried and tested. And one of the things that I liked about SingleStore. Was you've got some huge customers. Some of the customers using SingleStore are doing more volume than we ever will do. And that brings confidence. And I know it's tried and tested the same goes for the framework.
Try unless you're really excited and it's a hobby, try to use more mature frameworks that have been around for a while that people have been building with, not just on Twitter. In the hype bubble, but also the companies that the law firms in the UK that I know are using Laravel and everything else that aren't shouting about it.
Tried and tested is the way forward,
Madhukar: I believe. Very good. Thank you. And where can people get in touch with you?
Jack: So Twitter, or sorry, X is [00:40:00] Jack Ellis. And then the usefathom. com slash blog is where I write my technical blog posts as well.
Madhukar: Awesome. Thank you so much, Jack. This has been an amazing conversation.
Jack:Thank you. This is great.