Neil Patel has always been a hacker - electronics boards, radios, etc. - being interested in how things work, mechanically or digitally. He learned hard work at his Father's convenience store, while also reading every computer magazine on the rack. He is a pharmacologist by study, but landed in tech cause he is passionate about it. Outside of tech, he loves architecture and design. He also loves to read, in particular sci fi, and enjoys eating Gujarati food, which is purely vegetarian food with tons of flavors.Prior to 2020, Neil and his team was attempting to build tooling around understanding the data around events. After a while, they realized that no matter what was done on top of an event store, you couldn't realize value without storing all events. So they pivoted, and focused on fixing the data store problem first.This is the creation story of Axiom.SponsorsPermitCacheFlyClearQueryKiteworksLinkshttps://axiom.co/https://www.linkedin.com/in/njpatel/Our Sponsors:* Check out Vanta and use my code CODESTORY for a great deal: https://www.vanta.comSupport this podcast at — https://redcircle.com/code-story/donationsAdvertising Inquiries: https://redcircle.com/brandsPrivacy & Opt-Out: https://redcircle.com/privacy
So I've been working on my authorization service, and it's totally sweet. It's only taken me six months to build it. Just six months. I started implementing some basic RBAC library, but that wasn't enough, obviously. So I designed relationship-based, fine-grained authorization for the highest security possible.
And then, to make it super fast, I used a GPU tower, running in my mom's basement, of course, connected via optic cable to a bare metal server at my local esports lounge. Permissions, restrictions, and admin. Nailed it.
Wait, wait, wait, wait, wait. Whatever you did sounds cool, but there's also another option. Oh, really? Yeah, with Permit.io. Permit is the full-stack authorization platform created so you never have to build permissions again. Build and manage permissions for any application with policy as code, APIs, developer-friendly SDKs, and user-facing UI.
Permit is an end-to-end authorization platform built on top of open source policy engines. It's high performing, gets decisions in less than 10 milliseconds, and uses a hybrid approach where config is in the cloud, but data and decisions are made locally. Not only is it intuitive, it lets you implement fully functional authorization in five minutes, not six months, and in the code base you prefer.
Check out the link in the show notes or go to permit.io to learn more. That's P-E-R-M-I-T dot I-O. Sign up for permit and stop rebuilding off.
The data store we were building was very novel in architecture. And at the time, we felt like as long as we did these three things, we would have it done within a certain number of months, basically. And we were trying to go for the ingest will be brand new and we'll do it like this. Storage will only use object storage. Queries will only use serverless.
And exactly how you'd expect engineers to behave, we were like, and we'll get it done within six months, right? Or eight months or whatever it was. The reality, though, was that for the API and the front-end side, we just ate the tech debt and we just repurposed it to make it work in that timeframe. I'm Neil Jagdish Patel, and I'm the co-founder and CEO of Axiom.
This is CodeStory. A podcast bringing you interviews with tech visionaries. Who share what it takes to change an industry. Who built the teams that have their back. Keeping scalability top of mind. All that infrastructure was a pain. Yes, we've been fighting it as a group. Total waste of time. The stories you don't read in the headlines. It's not an easy thing to achieve.
Took it off the shelf and dusted it off and tried it again. To ride the ups and downs of the startup life. You need to really want it. It's not just about technology. All this and more on Code Story. I'm your host, Noah Labhart. And today, how Neil Patel is urging you to stop sampling events, but to cut to the chase and observe them all. This episode is sponsored by KiteWorks.
Legacy managed file transfer tools lack proper security, putting sensitive data at risk. With KiteWorks MFT, companies can send automated or ad hoc files in a fully integrated, highly secure manner. The solution is FedRAMP moderate authorized by the Department of Defense and has been so since 2017. Step into the future of secure managed file transfer with KiteWorks.
Visit KiteWorks.com to get started. This episode is sponsored by ClearQuery. ClearQuery is the analytics for humans platform. With their full suite of features, you can go from data ingestion to automated insights seamlessly. With Ask ClearQuery, you can find valuable insights into your data using plain English. Don't miss the opportunity to simplify your data analytics with ClearQuery.
Get started today at clearquery.io slash code story. Neil Patel has always been a hacker. Electronics boards, radios, etc. Being interested in how things work, mechanically or digitally. He learned hard work at his father's convenience store while also reading every computer magazine on the rack. He's a pharmacologist by study, but landed in tech because he's passionate about it.
But outside of tech, he loves architecture and design. He also loves to read, in particular sci-fi, and enjoys eating Gujarati food, which is purely vegetarian food with tons of flavors. Prior to 2020, Neil and his team was attempting to build tooling around understanding event data.
After a while, they realized that no matter what was done or built on top of an event store, you couldn't realize the value without storing all of the events. So they pivoted and focused on fixing the data store problem first. This is the creation story of Axiom.
Axiom is a event store essentially and when you have logs or trace events if you have events being generated from products or your services things like that and what it does is it takes it all in gets it stored for you and makes it immediately queryable however you want and so you may be making charts and analytics you may be just looking at that data raw or you may want to do something with that and you know export it somewhere else and
So essentially what we've been doing is building out the data store, which is brand new and it's something we built ourselves. And the whole idea is that so much of an organization's data is actually held in events. And those are the things that are happening with a timestamp.
And they actually bring up the history of what you do, whether it's a service doing it, whether it's a person doing it, etc. And so what Axiom does is allow you to store all of that for a really long time and then bring value out of that, whether it's for log analysis, tracing, whether it's for product analytics or anything related like that.
We actually started off with less on the data store side and more on the side of trying to build out more of like event tooling. So the connectivity piece around how do you make sense of all this data that's caught up in silos. So at the time, the data stores would allow you to have about 15 days, 30 days of data before it started getting really expensive, etc.,
And we were thinking and working on if companies want to do something with this, how do they build out event systems on top or have reactive states on top and things like that.
And actually, after diving into that for a while, what we realized was no matter what we did on the top of an event store, if you can't actually store all of your events, you couldn't get to the value of that we thought we would provide on top. Axiom essentially evolved from trying to do the product side of it down to first trying to solve the data store side.
And now we're coming back up to the product side, essentially.
Tell me about what you would consider the MVP. And that's going to be interesting because you had to go back down to the data store and now you're going back up to the product side here. And so maybe there's multiple or maybe there's the first one you want to start with. You decide and you take me where you want to go. But I'm curious about MVP. What sort of tools you were using to bring it live?
Excuse me. What kind of tools you were using to bring it to life and how long it was taking to build it?
We created the first MVP of this kind of system that you could run a shell script. It would install into your AWS and then bang, you had this kind of interface. You could query logs and metrics. You could do things with it in terms of attach their state to something else happening. And it was all very shaky.
And one of the problems we kept having was in trying to get the MVP out, we had to have a hard dependency on some kind of data store being available. So if we're encouraging people to send us data so we could make sense of it, you need to put it somewhere.
And so initially, when we were trying to give it out to people, they were like, but I want to use this, but I don't have Elastic available right now, or I have to wait to get access to our companies or whatever. My co-founder, he was like, oh, no, I can just build something internally where we won't need to ask for anything just for them to try it out.
And so he made this thing called EventDB, which was just like this demo store inside of our product. And it was just meant to be like this easy onboarding for people who we just wanted feedback of, to be honest. The feedback was like, hey, this is really cool. The problem is, though, what you're trying to do, we just don't have enough data for it.
We want to do it, but we don't have enough data for what you're trying to achieve. And when we do all the costings and stuff, it's not going to work out for us to have enough to make the second part viable. And then you talk to them a little bit more and they say, but what are you using for your data store? How come I didn't have to connect you to anything?
Why am I sending everything and being able to read it back so easily? And then the penny dropped and we quickly realized that's the thing we should be working on first and make that viable. So that was the first MVP. It caused the pivot to happen within weeks, essentially, of us giving it to people to try out.
And then the second one was about actually 18 months after that when we released our beta cloud around our data store. So we took this demo data store and we made it real during that time. And so that was the second MAP.
Maybe stick in the second MVP part because I get there was a decision point to go and build the second MVP to focus on the data store to fix the problems there. Tell me about some decisions and tradeoffs you had to make within the second MVP, maybe around like technical debt or approach or things like that and how you cope with those decisions.
It was interesting because you have already built a bunch of things up from the front end to API services back down to how those API services talk to a data store. So the new part was the data store. The old parts were the API server and the front end, which we were repurposing. The reality was the data store we were building was very novel in architecture.
And at the time, we felt like as long as we did these three things, we would have it done within a certain number of months, basically. And we were trying to go for the ingest will be brand new and we'll do it like this. Storage will only use object storage. Queries will only use serverless.
And exactly how you'd expect engineers to behave, we were like, and we'll get it done within six months, right? Or eight months or whatever it was. The reality, though, was that for the API and the front-end side, we just ate the tech debt and we just repurposed it to make it work in that timeframe. What happened was essentially we had made a data store.
And so there's endless things on the other side of you making that viable, as well as we needed our AWS. There were problems like the bandwidth between S3 and Lambda. We were getting caught on that constantly. So we were hitting the limits there. So you could get all the data in, get it into S3, but we couldn't query it fast enough because we just basically saturate everything.
And if we kept ending lambdas, obviously that has an issue around cost. And so we had all these issues. And so just even we ate the debt on one side. And then on the other side, if you went back, you'd be like, we didn't need to. We had the time to redo it from scratch, essentially, just because the data store was going to take longer than we thought.
This episode is sponsored by KiteWorks. Legacy managed file transfer tools are dated and lack the security that today's remote workforce demands. Companies that continue relying on outdated technology put their sensitive data at risk. And that's where KiteWorks comes in. KiteWorks MFT is absolutely the most secure MFT on the market today.
It has been FedRAMP moderate authorized by the Department of Defense since 2017. Through FedRAMP, KiteWorks level of security compliance provides a fast route to CMMC compliance, saving customers time, effort, and money. KiteWorks MFT makes it easy for users to send automated or ad hoc files via fully integrated shared folders and email.
administrators can manage policies in a unified console and create custom integrations using their API. Did we mention it's secure? The level of security with KiteWorks solution is rare to find. Step into the future of secure managed file transfer with KiteWorks. Visit KiteWorks.com to get started. That's K-I-T-E-W-O-R-K-S dot com. This episode is sponsored by CashFly.
The web is a competitive place, and if your site delivers its content pixelated slow or not at all, well, then you lose. But that's where CashFly comes in. CashFly delivers rich media content up to 159% faster than other major CDNs. Through ultra-low latency streaming, lightning-fast gaming, and optimized mobile content, the company offers a variety of benefits.
For over 20 years, CashFly has held a track record for high-performing, ultra-reliable content delivery. While competitors call themselves fast or use cute animal names, only CashFly holds the record of being the fastest and serves customers like Adobe, the NFL, or Roblox, where content is created by users and must be delivered in real time.
For the first time ever, CodeStory listeners can get a 5TB CDN for free. Yep, you heard that right. Free. Learn more at cashfly.com slash codestory. That's C-A-C-H-E-F-L-Y dot com slash codestory. So then you got the second MVP and let's move forward. How did you progress the product from there? How are you maturing?
And I think to wrap in a box a little bit, what I'm looking for is how do you build your roadmap and what sort of criteria are you using to decide, okay, this is the next most important thing to build or to address with Axiom?
The feeling we had when we released the beta cloud, our MVP, was we had felt we had now been much later than we had thought about bringing the thing we were building to market. It doesn't matter which thing we were building, but since the inception of the company to bringing it to market, it had elongated because we decided to pivot. And we were just desperate.
Like we had this massive list of things we could have done, but we were so desperate to just put it into people's hands. In a way, we pushed off anything that would have made like complete sense for us to be like, okay, of course you build this next or that next or whatever.
And instead we worked on just talking to as many people as possible, getting as many people to use it, getting that feedback and just working through feedback. And honestly, I'd say we probably did that for a couple of quarters where we didn't really work as much towards these are like the longer term goals. We worked more towards this thing is so new in so many places.
The last thing we wanted to do was continue to run without actually getting a feeling of what's happening around us. We put ourselves in the hands of our first users and then the growing user base, and we've focused on just making them happy. What happened from that was essentially we grew our user base, which is great.
We learned where they were, where we needed to be to get more people to use us, to get the right feedback and things, and also different kind of levels of usage between startups, between late stage startups, actual businesses, et cetera, et cetera, et cetera. As we grew into those, we could pick up things like off the shell of the back burner, which we knew we would want to do.
But we could blend them into what the customers wanted as well. And so even now we have this vision of when I like I carry this vision all the time of, OK, I know exactly what I want Axiom to be. But we're always trying to align it with the current needs of customers or like the three month or six month needs of customers. And then we don't try and make roadmaps as much.
We're just more in terms of here's what the quarter looks like. Here's what we absolutely know what we'll do in the next quarter. Otherwise, we won't overly define things right now.
So I hear you saying we tell me about how you built your team and what do you look for in those people to indicate that they're the winning horses to join you?
So the core team of Axiom has known each other for over 15 years. We've probably been working together for most of that time through multiple companies. So we're all nerds and we all are Linux nerds. So we actually met each other on IRC a very long time ago. And we were all building open source projects, tools and search and all these different things. And so we became friends like that.
And over time, I ended up at Canonical, where I was leading the desktop experience team for Ubuntu. And so essentially, as soon as somebody says, hey, you should hire some people, you obviously go to your friends. And so I had the opportunity to hire my friends from IOC over into Canonical, and we were spread out. there was somebody across, actually just across the world, they were everywhere.
And essentially, we always worked in those kind of remote setups, always being on ISC, talking a lot, discussing things, etc. And then going back and just executing those plans. And so actually, the core of Axiom is that we built a really amazing team at Canonical. When a group of us went over to Xamarin, when we could, we pulled a bunch of them over to Xamarin.
And then when we started Axiom, we knew on day one what probably the first seven or ten at least hires would be, who they would be. When you work with people for that long, they start filling the holes that you have. And so everyone is great at something, but you're going to have things which you just have blind spots, et cetera, which other people can fill.
And so once you get that harmony, you want to carry that forward because it just makes working so much easier. And then the culture is also there, like that remote culture being around for over a decade and a half that we had been doing it by then. The trust for that self-motivation, that get up and go on. Hey, anything on the floor I can pick up. I don't need to have permission.
I don't need to talk about it. I don't need to do those kinds of things. And so it actually helps on the hiring side as well, because. as people go through and new people want to join this group, you're looking at them with those eyes and you're like, hey, whether you're a junior, whether you're senior, do you have those same elements inside of you? And are you going to help make that team better?
Are you going to fill more gaps that we have in ability, et cetera, and also share and learn and all the things that we've been doing just naturally over this much time?
Hello? Welcome to the Data Analytics Club. Do you know the password? No, didn't know there was one. Do you know how to code? Uh, no. Do you know how to query data? Like, ask a question? I guess not. Hmm, I see. Then you can't be in this club. Sorry. Goodbye. Don't be left out of the analytics club. ClearQuery is the analytics for humans platform.
With their full suite of features, you can go from data ingestion to automated insights seamlessly. ClearQuery provides you with the information you need without requiring you to do the heavy lifting. Their Ask ClearQuery feature allows you to ask questions in plain English, helping you find relationships and connections in your data that may have previously gone unnoticed.
You can even visualize your data with presentation mode, taking your data storytelling to the next level. Pricing is based on storage, not licenses, and that ensures that you get the most bang for your buck. Don't miss the opportunity to simplify data analytics, your data analytics, with ClearQuery. Get started today at clearquery.io slash codestory. This episode is sponsored by CashFly.
The web is a competitive place, and if your site delivers its content pixelated slow or not at all, well, then you lose. But that's where CashFly comes in. CashFly delivers rich media content up to 159% faster than other major CDNs. Through ultra-low latency streaming, lightning-fast gaming, and optimized mobile content, the company offers a variety of benefits.
For over 20 years, CashFly has held a track record for high-performing, ultra-reliable content delivery. While competitors call themselves fast or use cute animal names, only CashFly holds the record of being the fastest and serves customers like Adobe, the NFL, or Roblox, where content is created by users and must be delivered in real time.
For the first time ever, CodeStory listeners can get a 5TB CDN for free. Yep, you heard that right. Free. Learn more at cashfly.com slash codestory. That's C-A-C-H-E-F-L-Y dot com slash codestory. Okay, this will be super interesting to hear. I'm curious about scalability. I'm sure there's lots of interesting stories, but was this built to scale from day one or with scale in mind?
Or are there interesting areas where you've had to fight it as you've grown?
Definitely built to scale and scaling in mind. So what I'd say is our data store, it's not one binary thing. It's pieces. And we've put those pieces together inside of a cloud. And that's really the way we always thought about building Axiom, where the ingest can be isolated here, storage can be isolated here, search can be isolated, etc.,
We looked at it at the time and when we were whiteboarding stuff, we had to kind of circle things away and say, this is okay to deal with when we have users. And then there was other parts which were very clear where if we don't deal with this well now, it's just going to be painful for every X terabytes we would have extra. Like we can see that is such a clear pain point that's going to happen.
And so on our side, we tried to plan it in that way, which was this was OK to scale later, maybe because you can just throw machines at it initially and you don't need to worry as much. Or maybe it's just going to be a problem and we have to defer it for a while until someone's actually using it in angle, right? Instead of just us theoretically thinking people use it.
On the flip side, I touched on this with S3 and Lambda, thinking about how are we going to scale our ingest so we can write as many objects as we want to write into S3? What is the partitioning that works best for S3 on read? How do we avoid getting hot partitions, etc.? There's one thing changing a schema in a table, something really different changing the way a data store looks up blocks.
for querying, right? It's one of those things where you don't want to come in afterwards and actually play around too much with that. You can always make changes but you don't want to completely change it, especially once you have users. We anticipated those issues, but we definitely ran into things which we didn't. We found the edges of Lambda.
We found the edges of using S3 in the way that we use it. We were lucky enough to be able to talk to the S3 teams, the Lambda teams, et cetera, and we were able to basically figure out what those issues were, work around them. Our own load testing and things like that got more sophisticated over time.
We started to learn about making sure that we tested not for the glorious, amazing batches the largest organizations were to send us, but also just hundreds and thousands or more of users of one app that's just sending data, individual events coming from the browser directly to Axiom, for instance. We also had to level up our testing, et cetera, as we kept on building Axiom.
Okay, as you step out on the balcony and you look across all that you've built with Axiom, what are you most proud of?
I think it's the architecture. I think now as we scale, the architecture is really showing off how pluggable it is and how reimagining what one of these data stores could be like by it being just parts inside of a cloud, AWS, Azure, it doesn't really matter. and how we can rip apart, piece it back together, put things in the middle.
All the challenges are so naturally challenges of any cloud kind of systems engineer. It's cheap mode at this point where you get to just pick a service from AWS and say, if I put that in the middle, we're going to automatically get something X, Y, Z happen and that solves this problem or allows customers to do something they weren't before.
We had on the whiteboard when we announced that we were pivoting and we did a sprint with the team and we were like, okay, we're going to build this data store. The first couple of things on the whiteboard were essentially the cloud exists with two underlines.
And the whole point was like, anytime we think that we're going to be special and try and build something ourselves, if AWS already does it or Azure does, There's no reason for us to build it. Instead, we should find how to make use of that and it will pay off in the long term. And I think we're seeing some of that paying off now.
Let's flip the script a little bit. Tell me about a mistake you made and how you and your team responded to it.
I'll be honest, I think like the one that sticks with me is we didn't get that initial product into the hands of people who would have given that feedback or advice to us fast enough. We corrected that so hard now where even features and things like that, we will try and get them into people's hands as early as possible for the earliest feedback possible.
I wish I had known how important that was with the product we were building then, because I think we could have reduced the time to this version of Axiom by maybe even a few years, to be honest.
That just sits with me because it's one of those things where it wasn't a clear thing for me because coming from open source, et cetera, I was so used to building and every commit would be built and put out somewhere. And so someone's always using it. And so you'd always be used to getting that quick feedback.
When we got our heads down and we were building this initial vision, we lost that connection. And I think my team, myself, we thrive on that connection with a user on the other side or someone to give us feedback. And that was time lost, I'd say.
Okay, this will be fun because I want to hear the passion and your voice and your excitement for what you've built. Tell me what the future looks like for the product and for your team.
The whole reason we made this data store and then we built the product around it is you can send everything to it. It's efficient and obviously that means that you're not going to have to burn holes in your pockets or anything.
You can essentially have a recorded history of everything that's happening inside of your startup from day one by just hooking webhooks or trace data, whatever it is, you can just send it over to Axiom. We don't force you to tell us what you're sending, a schema or anything like that.
The whole idea is that we think the future is essentially organizations that have this treasure trove of information as events across all these different streams, whether it's your customer support messages, whether it's product, whether it's traces, whatever it is. And the idea is for us is we then, Axiom's entire focus is we convince you to send us the data.
We convince you to store it for us for multiple years. You're getting some value out of that data yourself because you know the data and therefore you may be using it for logging or building Stripe dashboards or whatever you're doing inside of Axiom. But now the onus is on us to go and give you things you never thought about that you could do with it.
And so much of the rest of this year for us is presenting back to the user that, hey, you trusted us with this initial part of the journey. Here's now all the useful things you can do with this data, which you may have not even thought Axiom is a place to do it. But now you can do that. So whether it's
forecasting whether it's having functions that run on schedules or because of a reaction that happens inside of your data store an event that's created all these different things where actually the bread and butter of everything are these events but they've never been in a place where they're all together you can get cross like dimensional kind of context between the different streams and then be able to do new and interesting things on top of that and so that's what's the most exciting thing because we're finally on that
journey of bringing together ideas from the past ideas from the world we live in now putting them on top of axiom and then putting them out to customers as quickly as possible
As the team, that kind of efficiency, even as we build the org, as we use the things that we've made, dog food it, show how we're using it as a startup, as a company that's trying to balance these new technologies with this kind of full history of everything we've done, what can we learn from the past, et cetera.
I'm really excited about just giving that out to the world, but also showing the ways that we use it as well.
Okay, Neil, let's switch to you. Who influences the way that you work? Name a person or many persons or something you look up to and why.
I think it's changed over the years. Probably the most consistent, weirdly enough, has been Nat Friedman, who started Xamarin. But before then, he was also part of the GNOME project on the Linux side and things like that. I think I learned a lot from Mark Shuttleworth at Canonical.
He started Ubuntu, which of course is like immense, the impact it's had, both if you love it and if you hate it, essentially, but it definitely an impact one way or the other. And I think that's given me an entire life, which I didn't really know that I would have, which is incredible. But I think right now, probably the person that I think about in terms of what
do they do what would they do etc is probably not just because having worked with them at zamarin i got to see a lot of that close up and things i didn't actually understand then now being further into building axiom they make more sense to me and i realize like those that way of thinking the vision putting it together waiting for certain times to start doing certain things etc
I just feel like I lean on that a lot. And the other thing which I wish I could mimic from him, which I'm so bad at, is the communication style. I'm too wordy and he just has this very clean communication style, which I have to somehow get to at some point.
Okay, Neil, last question. So you're getting on a plane and you're sitting next to a young entrepreneur who's built the next big thing. They're jazzed about it. They can't wait to show it off to the world and can't wait to show it off to you right there on the plane. What advice do you give that person having gone down this road a bit?
Talk about it. Write about it. I think writing is important. I think because you have to build that kind of marketing muscle really earlier than I thought you did. You can keep building things, but it's not as useful if no one's going to actually know they exist.
If you can convert your passion into words or you can convert your passion into being part of a podcast or whatever it is, if you're passionate about it, there'll be others out there that will also be passionate about it, but they need to know you exist. I think after everything, I'd say that because I think that would also solve the, hey, do you get advice earlier or do you get feedback earlier?
Everything comes from the fact that can you just go out there and get people interested in what you're doing?
That's fantastic advice. Well, Neil, thank you for being on the show today. And thank you for telling the creation story of Axiom.
Thank you. Thanks for having me.
And this concludes another chapter of Code Stories. Code Story is hosted and produced by Noah Laphart. Be sure to subscribe on Apple Podcasts, Spotify, or the podcasting app of your choice. And when you get a chance, leave us a review. Both things help us out tremendously. And thanks again for listening.