From Rave Promoter to SaaS Innovator: Revolutionizing Event Management with Ritesh Patel
In this episode of "How Many CTOs Does It Take?" podcast, hosts Scott Porad and Brad Hefta-Gaub sit down with Ritesh Patel, co-founder of Ticket Fairy. Ritesh shares his journey from coding and organizing raves to creating a powerful vertical SaaS platform tailored for the live events industry. Ticket Fairy aims to provide small event teams with the technological capabilities of much larger organizations. Ritesh discusses the platform's unique features, the challenges of scaling, and how AI and machine learning are revolutionizing their approach. The conversation also delves into the role of entrepreneurs in the tech industry and the future of SaaS products.
Resources:
- How Many CTOs Pod: https://howmanyctospod.com
- Scott Porad: https://www.linkedin.com/in/scottporad/
- Brad Hefta-Gaub: https://www.linkedin.com/in/bradheftagaub/
- Ritesh Patel: https://www.linkedin.com/in/riteshdpatel/
- Ticket Fairy: https://www.ticketfairy.com/event-ticketing
#TechPodcast #EngineeringPodcast #DevTalks #PodcastForDevs #HowManyCTOs #Podcast #CTOs #CTOPodcast #ChiefTechnologyOfficer #Technology #Engineering #SoftwareDevelopment #SoftwareEngineering #TechLeadership #EngineeringLeadership #EngineeringCulture #TechDebates #LiveEvents #Entrepreneurship #AI #AIIntegration #BusinessGrowth #TechInnovations #Startups #EventTech #SaaS #TicketFairy
Guest
Ritesh: Can we give a two person event production team the same execution ability as 20 people?
So the principles have they apply in other industries,
they just got done in coding agents first.
Brad: Welcome everybody to another episode of the How Many CTOs Does It Take podcast.
I am Brad Hefta-Gaub and my co-host is...
Ritesh: Scott Corrett.
Brad: And today we have a very special guest,
Ritesh Patel from TicketFairy.
Ritesh, why don't you introduce yourself,
tell us a little bit about the journey that brought you here,
and let's talk about whatever you want to talk about.
Ritesh: As you mentioned, my name is Ritesh. I'm a co-founder of Ticket Fairy.
We're a vertical SaaS platform for the live events industry.
We typically serve the creative industry that does not have internal.
tech resources so it's a really interesting product to build
Brad: Very
Scott: So
Brad: cool.
Scott: when you say live events, I immediately think Ticketmaster.
Is that your competitor or is it some other slice of the entertainment industry?
Ritesh: it's an entirely different slice so
The way we've been positioning ourselves recently is Ticketmaster is part of a larger group of companies. So Live Nation is a parent company.
Live Nation is the biggest concept promoter in the world.
So they actually run the events.
Then they have the ticketing platform.
They also own many of the venues that they put the events on at.
They might own the parking lots or have like, you know.
various different revenue streams um yeah
Brad: They own the t-shirt printing companies.
Ritesh: like you know and you know they they are allowed to give or they're not even allowed to they give funding to their internal companies whether it's a festival or a venue so really like it's it's a verticalized business that um many have thought they would try and break by offering lower fees to the general public without really understanding that
that that's not how the business works so um we've never tried to go into that part of the that slice because um it is a really good way to burn a lot of vc money and fail
Scott: Mm-hmm.
Brad: So what slice do you take on?
Ritesh: Everyone else.
So basically the framing for why we exist is that an events company,
be that a venue,
a festival,
just someone who runs events regularly,
it's not that different conceptually from a tech founder.
you've basically got a product you've got a brand you have an audience you have a vision for what you want to bring to the world it's really similar to being a founder of any company particularly a tech company the the difference is that you don't have access to venture capital most of the things you do will be in fact the same with startups but everything will be like learning by doing and seeing what worked and what didn't and iterating and it will take you five or six years minimum
to even just break even on your business let alone become healthy and and cash flow positive so lots of parallels and so most of these companies that are not in that kind of live nation slice are one two three people max full-time um they might be juggling a day job as well until the that the company can actually help
make their make their salaries which might not happen for five or six years what they don't have is like huge budgets that hire developers and engineers and a cto and data scientists and expert marketers like you know they have their creative vision that they're trying to execute and then most of their staff are freelancers and contractors in the week or two leading up to their event so for us it's like well there's a lot of knowledge and expertise in the industry
that they're going to maybe take a decade to learn well why wouldn't we just productize that and then build out all the layers of tech they need so instead of using horizontal software like you know generic task management platforms and google sheets and whatever else like why should we we just want to encode all of the best practices of the industry of how to actually make money from it into one platform and
allow these teams to do the same as teams that are 10 times their size.
Brad: Yeah.
Scott: So like for a way of example, my friend Maria, who lives in Portland,
Oregon,
she runs the film festival.
in a song festival in Oregon.
I think they've been doing it 20 years now.
So it sounds like she's the kind of person, you know, it's just her and her husband and she's full time and her husband has a day job and they run this thing and I'm sure there's a million people they work with.
It sounds like they're the kind of person that would use your platform.
Ritesh: Yeah,
and the thing is that even though it may be only one or two people doing something
like running an event or festival or venue that doesn't mean they can't do things at scale it just means that like the expenditure on staffing and resources is really weighted towards like the weeks leading up to the event and Mm the
Scott: -hmm.
Ritesh: weekend of the event right like an event might still spend five million bucks on production and talent and whatever else but it's really concentrated
into like a small space of time so
Scott: Mm-hmm,
Ritesh: two people can do things that are really big it's not that a small person team has to do a 500 person event they can do a 10,000 person event as long as they bring in a team closer to the time
Scott: Right.
Brad: Yeah.
Scott: Now, you've been doing this for like a decade.
Ritesh: Yeah, more.
Yeah.
Scott: Okay, so tell us how to just go to this go to the origin story. Like how did this come about?
Like and tell us about your journey. Like what's the story there?
Ritesh: Origin story.
Brad: Okay.
And I'd also love to hear, as you tell that story,
Ritesh, you said you were the co-founder and I'd love to hear about kind of like the, you know, like, what's your background?
What's the rest of your team's background like this? It's fascinating product you have.
Ritesh: sure sure sure so my co-founder is actually my brother so that's nice like no um all the founder squatters were done you know by the time we were like 12 years old so that's cool
and like my personal background i started coding on a commodore 64 in 1989 considering
Scott: Nice.
Ritesh: this is a CTO's podcast this is like maybe relevant uh started building
soft like software products in 93 when i was 13.
used as an excuse to learn C and build products on my high school adopted.
Did that a couple of times over the next few years.
By the time I got to university for computer science,
I'd already been building products for, you know, five years. I was like, well,
I've kind of done it. Why am I doing like, you know, linked, link tree algorithm exercises in computer science 101?
And at the same time, discovered the music scene and the rave scene in my college town.
and I kind of took over my life and we started throwing 300-400 person house parties with DJs and sound systems and you know like word-of-mouth marketing and about a year into that kind of or even though nine months into that realized that I wanted to like try try doing it professionally and approached venues with my with my housemate and got a Saturday night at the most prestigious venue in town and caught up the artist booking agency and
As a 19 year old kid, I asked if we could book the four biggest DJs on their roster and they thought we were crazy.
And they said yes.
And then we did this gig and packed out in the first 45 minutes.
But with my nerd hat on,
I.
this is like january 2000 someone i'd been speaking to in an irc chat room in a music chat room was a sysadmin and he said he was he was interested in coming down to the gig and i was like well can i borrow one of your servers because there was no cloud right this is like free cloud it's like can i borrow one of your servers and can i install the real server streaming software on it so
Brad: Nice.
Ritesh: that we can do a live stream
Brad: mm
Ritesh: it's
Brad: -hmm
Ritesh: like yeah sure and i'll come down and like you know i'll help you out and so i
Brad: now you're just pandering to me right Ritesh you know that that I was at Real Networks and helped build that software there
Ritesh: actually did not all right
Brad: you go anyway so cool real server love it
Ritesh: nice yeah so i so i asked him to install the real server software on this on this box um in 2000 that was like in some data center somewhere um and then put my massive pc tower and
no flat screen monitor these like the big days of the ER my big like
Scott: Yep.
Ritesh: huge huge monitors like lugged all of that into the back of my car took it to the venue and had to run like 35 feet of audio cables with couplers in the middle because there wasn't like take a cable long enough from the stage to the soundblaster card in on my in my PC and then um connected my 56k
modem to the venue's phone line and connected my dial-up account and
Scott: Wow.
Ritesh: um and uh yeah sent a real-time uh at the time mono 20 kilobit stream because i knew that like bandwidth wise you go highest quality first on the uplink and then everyone else can listen at higher quality than trying to like squeeze stereo stream into dial-up
And then promoted our news groups and chat rooms and people listened in real time all over the world and that was like my nerd meets rave promoter start
Scott: Wow.
Brad: Wow.
Love it.
There you go.
Scott: So how did you get from there to the beginning of Ticket Fairy?
Ritesh: To charisma parallel barely scraped through the computer science degree because I ended up
being obsessed with music so I ended up not really going into class and waking up at 5 p.m every day and I started running like five events a month all booking like professional DJs and
Scott: Mm-hmm,
Ritesh: built an events brand that started getting a lot of press and so and then when I graduated started working at the BBC and corporate IT still kept running the events company and did that in parallel for almost a decade and moved to Australia and did the same thing started working for
ad tech companies and eventually got into cloud architecture and started building like ad tech big data systems and click logging and all this kind of like you know fun stuff
and understanding how affiliate tracking worked in e-commerce there was kind of a light bulb moment where it was like wait a second i've produced 500 events and it's really hard for them to break even and i bet that everyone has that problem it's it's a super unpredictable business what
Scott: Mm hmm.
Ritesh: if we applied affiliate marketing principles to event ticketing and
Scott: Yeah.
Ritesh: so the light bulb moment was build a ticketing platform
that the moment someone finishes buying a ticket they get offered up to 100% refund on the price of that ticket if they can drive sales using a tracking link they
Scott: Mm-hmm.
Ritesh: were the first in the world to do it and then they would get an automated refund back to their card based on how many more people they got to this go to the same event as them and psychologically it was like well this makes sense if I'm paying to 50 bucks to go and see a DJ I love
I want to try and drag those people, like my friends, to see that same DJ because I love them.
Scott: Mm-hmm.
Ritesh: And this event organizer who's desperately trying to break even on their costs is looking for distribution and people that would go to that gig.
So why not incentivize the people that are already paying for the product to bring in more?
And now we know that that's the right way to sell anything online.
But it was a very new concept for events digitally anyway.
There was always like a bring 10 friends to the entrance of a club and you can come in for free.
But it was never done digitally in that way.
Scott: Yeah, very cool. That was the beginning of Ticket Ferry.
Ritesh: Exactly.
Brad: Obviously, with your tech background,
I'm kind of curious,
how do you describe like the.
The various hats you have to wear as a founder,
whether you're sort of solving the technical problem,
solving the product problem,
solving the business problem.
You know, one of the things that Scott and I often talk about is the job of the CTO to kind of be that bridge between the getting it done technically and the understanding of the business needs and the business stakeholders.
And it sounds like you're kind of all those things at once.
So I'm kind of just curious,
what's your experience in that space of sort of the balancing of the business needs from the technology,
getting the technology built?
Ritesh: My team hates it when I push code to the master branch without a pull request.
Scott: Yeah,
Brad: Bad
Scott: they should.
Brad: CEO.
Scott: They should hate it.
Ritesh: I mean, I still code every day, obviously.
So like, we noticed, for example, that our onboarding UX for new clients was very heavily broken and hadn't realized for a while that like people were making their accounts or setting up their organizations and then they weren't making their first event.
and you know it's very much a UX like that there's too many fields it's too overwhelming this product is too advanced I don't know what to do type thing right
Brad: because Yeah,
classic problem.
Ritesh: we've built like the way we build the product is listen to all clients and also like think about like business analysis and where their gaps are and can we fill those and also like what do we think the industry needs but you
every event is different right so like it could be a 20 000 person event or a 200 person event it could be multi-day it could be one day it could be music it could be sports it could be gaming like so you need to have the matrix of everything everyone needs but
obviously you can't have it all at once or that logic would clash so we we built like hundreds if not over a thousand feature flags that all can get chained in different scenarios and then a feature flag could either be on or off or it could be configurable and so that creates like hundreds of thousands of potential combinations of logic and so like now that's hard to put into a product in terms of ux last year we set a really big ux and ui overhaul
the whole project that we were going to launch in october and it's still not out yet and the other day i was just like i don't care i need it live right now we'll deal with it when it goes live and like you know that's my business brain talking rather than my you know tech perfectionist brain talking and it's really difficult to balance and sometimes there's a there's a deal that is like you know you're going to make 100 grand out of one deal
and you know our ACVs are way higher than standard SaaS so like it's not uncommon that we make $100,000 a year from a client just for the software so
Scott: Right.
Ritesh: when you have a deal that big but the client says well my press for my event announcements gonna go on March the 1st and that's not you can't that won't move and if you can't meet that deadline then you just don't get our business
Because there's a whole PR campaign attached to it and you know, like it's public right like with this the difference between us and normal software
is that when someone uses us it's a very public facing thing this event has been announced it goes on sale on this date at this time right
Brad: Yeah, classic.
Ritesh: like we don't have the liberty to say it won't be ready yet and so i have to then pull the team off what they're doing be like nope like you've got to stop doing this now and context switch to this
Scott: I'd be interested to know, I should say,
how you have designed the system to handle those spikes.
Which I presume you get when tickets go on sale or when events are announced.
Ritesh: Before doing this company, my most recent job was cloud architecture and infrastructure as code.
And so kind of there was a level of like,
hey, I know how to do load balancing and kernel level server optimization and understanding like,
you know, where all the where all the issues are like, you know, you can't just.
Roll out MySQL out of the box without configuring with the parameters because
you'll be using a fraction of the capabilities of the hardware it's on so
Scott: Mm-hmm.
Ritesh: I had a lot of experience with that and so like understanding horizontal scaling and vertical scaling was really important when when first building this company so the principles were there like fairly early on and then you realize well that's actually not enough right like then like you know there's race conditions in um inventory locking and you can't oversell an event or the same seat or whatever and so
you know then i had to think about okay how do we use redis to lock inventory across multiple servers in real time so that you can't oversell and then it was like wait a second um you know what could be made asynchronous and then you know i designed a whole job queue system and made and and you know then had to implement rabbit mq to have all these have things going into into queues and then it was like wait one queue is not enough we need 10 different queues so that
real type things that need to be near real-time going one and then longer running jobs going to another so you're not blocking and then you get you think you've done everything right and the client sends a massive spike and you realize there's a database index missing and the whole system went down anyway so
Scott: Mm
Brad: Yeah.
Scott: -hmm.
Brad: Yeah.
Ritesh: a lot of it is just like oh man
we should solve that we just found another bottleneck we should fix it and then think about what happens next time yeah
Scott: Right.
And those are only lessons you can learn from just being in the business.
Ritesh: yeah unfortunately like you know you could architect this stuff in a ideal scenario and still not understand that like oh this you know one component in the middle failed and um that create a stampede effect and you hadn't accounted for it
Scott: Mm-hmm.
Brad: Yeah, I've always had the sense that, like, the, you know, sort of the event ticketing problem is,
like,
that and pay-per-view are these two types of problems in sort of, like, digital media and computer science that are, like, very, very bursty in nature. And,
Scott: Mm
Brad: you
Scott: -hmm.
Brad: know.
it's it's totally different to deal with you know a burst like that that where where you cannot oversell it you like you have to account for every seat you have to account for every ticket then
Ritesh: Yeah,
Brad: many
Ritesh: absolutely.
Brad: of the other scaling problems that exist out there right like
Ritesh: Absolutely.
And the thing with the pressure where your client has spent six months leading up to putting their event on sale and they've done all this press and they announce and you crash and half of the buyers don't come back.
Brad: i just like i'm just picturing like uh the original rollout of the aca website the obamacare website or something like that right like like it's such a huge fanfare for something and then it doesn't work oh boy egg on egg on egg on everyone's face right
Scott: More germane to this is when Taylor Swift announced her tour.
Brad: yeah
Scott: But I think here's what makes it a challenging technical situation.
Often the way to handle these types of spikes or these types of scale is through distributing things and being asynchronous variety of techniques,
but all about spreading stuff out.
But when you have a very limited controlled inventory,
then it has to be very centralized.
So you have to find some way to like.
Ritesh: Exactly.
Eventual consistency is not an option.
Brad: Yeah, exactly.
Scott: Exactly.
Brad: Eventually is not the solution to this problem.
Exactly.
Scott: that's exactly right you know I always wonder like here's a question I always wonder like when I go on to buy an airline ticket and you're going in there and you you click you want the flight you put it in your quote-unquote cart and then you pick in your seat and so on and so forth are they holding that seat for me or is it not until I finally click checkout like could someone snipe me and get underneath there
Ritesh: So to the best of my knowledge, they're holding the fare.
Scott: Yeah.
Ritesh: um but they're not holding the seat but some airlines will when you click the seat they
Scott: Yeah.
Ritesh: will hold it because let's say you abandon your car and you come back a minute later and you know someone else hasn't picked the seat it's still held so i think they do a combination of the two
Scott: So how do you do it with tickets?
Do you hold the ticket or you just you must hold the seat?
Ritesh: yeah you have to hold both
Scott: Yeah, you have to do it that way.
Ritesh: You have to hold both.
Scott: Okay,
so can I go back and ask you about this big UX overview you're doing?
I mean,
the topic du jour,
it's all we can ever talk about in this podcast is AI.
It's all anybody wants to talk about.
Has that been part of your reworking or is that part of your world or is that not a thing you guys are doing yet?
Ritesh: Very, very heavily part of our world.
Oh,
Brad: Yeah.
Ritesh: tell us about it.
Brad: So we did Y Combinator in 2015 when some old man was running it.
Ritesh: Okay.
Brad: When the first GPT.
versions and API has got launched YC companies had early access and from memory that was like 2020 and so like since then I've been playing around with what's possible with LLMs I asked OpenAI like how like you know here's the persona of an event organizer
write a marketing strategy for them and um and actually posted that on linkedin as like you know this was a fully 100 llm generated article what do you think of it um and over time like
You realize that there's many,
many use cases, both internally and externally for LLMs. And so like one of our things, one of the things on my tech roadmap for the last four years was what I called the conversational dashboard,
because I realized that we had so many features that we needed our clients to be able to just ask the system in natural language what they wanted to do and also not rely on having to wait until like 9am the next morning to get an answer from an account.
from an account manager because sometimes you have like you know it's two in the morning and there's a thousand people outside your venue and the tickets aren't scanning and you need to know right now right like again like it's the it's the you can't have eventual consistency thing those thousand people are going to cause a riot if they don't get into a venue like you can't even wait 20 minutes my goal for for solving that was you know a fully
a conversational agent trained on every API endpoint every feature to be able to provide that like kind of 24-7 account manager on the on the event organizer side and then looking into there was kind of like oh wait the models aren't capable the frameworks aren't capable and we're only really going into a point in the last like two months maybe three months
where all the the llms and the agent frameworks are stable enough to give you something that's reliable and so you know like things we wanted to do for years now we can roll those out this year in the meantime it's been kind of experimentation with like internal scripts adopting coding coding agents adopting
AI workflows for code reviews,
being able to do sprints on features or, you know, like use something like V0 to process up a UI and figure out like, you know, what needs to get built.
And so like, you know, we've been really early in the adoption process for AI,
but, you know, like there's a lot of early AI companies that no longer exist because.
You know, like they were just very early like hey write an article using a prompt and
Scott: Yep
Brad: now you could build that in like five minutes
Scott: Right.
Has it been helpful with this? And from a coding perspective,
has it been helpful with this UX revamp that you're doing?
Brad: Yes, I think that like, actually,
here's a really concrete example.
Myself and one of the other guys in the team are very good with PHP,
but we can do front end vanilla HTML,
JavaScript,
jQuery,
but we can't do React.
Because coding in React is a completely different mindset.
And
Scott: Yeah,
Brad: it's
Scott: totally.
Brad: just like.
like it does my head in i haven't i don't understand the way react works but you asked me to build something in jquery and i could do it and
Scott: Yeah.
Brad: in that scenario it was like okay well you know i can either write my own php endpoints uh or write or ask an agent to like evolve what we have and be able to code review and say no that's correct or isn't which is great and then for the first time it didn't have to get handed over to a front-end developer that would manually build the ui
That we could both just be like,
hey,
adapt the UI to do this or adapt the UI based on this API endpoint.
And we did a lot of work on the UX improvements just having gained the ability to do that before it went to a professional design team to then make it look nice.
And that's because your front end was developed in React and as a developer yourself,
you weren't as confident in that particular tool set. And so the AI coding agent kind of.
gave you that confidence or that ability to basically write the React stuff for you. Yeah.
Exactly. Exactly.
Yeah.
I think that's like, you know.
There's non-coders who can build software now,
but for people who are very technical,
like I'm very technical,
right?
I can, you know, I once lost data on a hard drive and reconstructed the partition table using a hex editor and recovered all the data.
Scott: Yeah.
Brad: Like, so I'm really technical, but I couldn't for the life of me figure out how to do React.
Yeah.
Yeah.
I think that that's it's an interesting example,
too,
because.
React is a good example of something that's got a ton of the corpus exists around React.
Like it's been, it's been, you know, React has been out on the internet and has been sucked into all of the models.
You know, it's a quite large set of data, right?
And so it's, it can be quite good at it because it's got such a large exposure to ways of doing it.
And
and then because it's a more modern framework there's a lot of
lot of documentation right like there's there's so much
Yeah,
Scott: Mm
Brad: totally.
Scott: -hmm.
Brad: Yeah,
it's one of those things where it's whenever I think about like, you know, again,
Scott and I often are talking about how do we get engineers that might be, you know, recalcitrant or like unwilling to sort of like consider using AI coding? Like, how do you how do you convince them to do it? And I and maybe that's a good example where it's like,
hey,
if there's an area that you're not an expert in,
try to get it to do some of that.
Yeah.
Scott: Yeah.
Brad: Then you'll show like it would take you so much longer to become a React expert than it is for you to be able to code review work by a React expert,
right?
Like as somebody who's observing it from the outside and saying like, this is what I want you to do. I've given you the implementation plan.
Come back and implement it for me and then let me validate your work,
test it, verify that it's behaving the way I want it to.
That's a straightforward thing.
it is it is and if you code it in one language you can most likely read at least with some level of competency another language right or
Scott: Mm-hmm.
Brad: another framework or whatever it is the hard part is
writing it from scratch because you haven't got enough experience in it.
Yeah.
Scott: Yeah, you know, I think I've talked about this here on the podcast. One of my first experiments with some of the agents was getting it to write, try to write a React Native app for me.
And it came back, I said, just make me the framework.
And it came back with, you know, like 60 files.
And I remember thinking to myself.
I wonder if this is correct or not.
I didn't really know because it wasn't something I was familiar with.
But I have seen, we have seen at least where I'm working out a lot of success with what you're talking about right now, which is, hey,
I had to go and deal with.
this bash script and I don't know anything about bash and I asked whatever model a person was using to help me and it solved it right and that's been a big victory a lot of times for us for sure
Brad: Right. And,
you know, it's like it's also for people that know what they're doing,
it avoids the rigour of back and forth.
And here's an example.
2007 I flew myself out to Delhi to do to become Red Hat Linux certified like I'd been building Linux boxes for years and I was like let me get a certification because like I was still working day jobs for people right so I was like okay let me my company didn't this company didn't exist yet so I was like okay if I become certified that's another thing on my resume and if you're Red Hat certified that's a really good thing
And so, you know, you learn how to build a box from the ground up and all that, you know, how to configure the kernel and how to configure the file systems using text files like, you know, it's really technical how to configure web servers manually and all of this stuff. Right.
But the other day, like, you know, we had something where.
our production server was returning errors when it got too many cookies sent to it because the headers and the server software weren't big enough and that might have taken me a day of experimentation and getting the syntax right and trying to like you know reload the configuration and it'll be like oh semicolon's missing or this directive is in the wrong is in the wrong place and I could just say to a model look look in the nginx config
this is the thing that's happening there were already buffers in there but they're not big enough optimize it
Yeah.
Scott: Mm-hmm.
Brad: i know i'd like i know what it i know what needs to be done i know what the end result will be that's a successful result but i need need it to be done in two minutes not in two hours
Scott: I wonder if there's a world ahead of us, and actually I suspect this world exists out there already,
and I just don't know about it, where you basically,
I'm just going to try to paint a picture,
you basically plug data dog and your server configuration into some AI and say.
Keep these metrics within these tolerances, go forth and adjust and just let it kind of in relatively real time maintain those environments.
You don't even have to know anymore.
You just know that this is the outcome I want.
I want this kind of latency and this kind of response time and so on and so forth.
Brad: Yeah.
Scott: And just it does it magically.
Brad: And,
you know, AWS,
to their credit, have certain things you can do now where you can say, you know, if the average CPU usage on the database.
devices if they exceeds 15 then spin up another replica and try and get that pull the average down so you can definitely do that in an automated way but once you start applying to your own software then that becomes really powerful
Scott: Mm hmm.
Brad: Yeah,
I think that you said something earlier, Ritesh, that I was like, oh, yeah, that's there's a there's there's something to be dug into on the phrase.
I think you said something like if you know what you're doing, then the tools can make you really fast.
And I think this is what I've been saying for a long time, which is that I feel like there's going to be like this like K-shaped economy for good engineers,
like which is to say the effects of like AI assistance for somebody who's already a strong engineer,
they're just going to be skyrocket with it.
But if you're actually not a good engineer or you don't know what you're doing,
I think you're going to go fast nowhere or fast in the wrong direction.
Scott: For
Brad: Well, sure. I mean, you see a lot of examples relatively recently where like say someone's used,
say lovable or one of the other like, you know, like build your app using a prompt type systems and they don't have the.
principles of say database security or like open ports or unauthenticated endpoints and things like that where you know someone who doesn't know what they're doing
builds this thing and they're really happy with themselves and so they should be but they don't know what they don't know and
Yeah, right.
what they don't know is that the entire system is open for exploit exactly
All my keys are like literally just in the code or something like that.
exactly and that's where it's like both empowering as a technology and very dangerous because you're giving firepower to people that
Like what you know, what if you think there was a thing recently where like someone collected negative dating reviews from women and they must have vibe coded it and then someone leaked the entire database.
Scott: Mm hmm.
Brad: There you go.
Scott: It's like, you know, putting a gun in the chimpanzees of it. It's funny at first.
Brad: So how do you, as a...
business owner and a technology leader and a team leader,
how are you making sure that your team is not misusing the technology and it actually is being a force multiplier as opposed to a negative force multiplier?
So
the way we built engineering and this was kind of a necessity as well as a nice to have was that in the early days like for the first five years of ticket ferry i wrote every line of code and also sat down with clients and became the you know now palantir has a has a lot of um kudos on the moment for deploying before deployed engineers we
Forward deployed
were we
engineers.
were doing that from the very beginning like
Yeah,
like
that was your idea.
it's like
2009-10 let's sit down with clients and figure out like you know what they need and sit in their businesses and like for the first few years of Ticket for I would fly to the other side of the world to a festival that we were one of our early clients and sit in the box office for 18 hours a day and do the customer service and monitor all the bottlenecks and like any bugs and scanning and the whole thing right like we over optimize on the into on the architecture of the platform by making it
able to be in multiple currencies and multiple payment gateways and and all of that really early on like 2014 where like it was already or even earlier it was already multi-currency so you'd pick the venue of the event and it would dynamically choose the currency the time zone the payment gateway and then everything and there's like on in every api endpoint there's time zone maths on all the stats coming out the database so it's all local to the uh to the event
But because we had distributed clients,
we had to start putting teams into different time zones.
And so then we hired one of the first engineering hires was based in Australia.
So we started doing multi time zone engineering,
multi time zone account management.
And then over time, we built teams in different time zones that gives us the engineering capabilities in about 20 hours a day.
and so part of it is being able to do more than other companies who work on a nine-to-five and part of it is like hey this critical bug for a 10,000 person event just came in at one in the morning U.S. time but someone in New Zealand is still working and they can fix it and
Yeah.
so that was really important in terms of like how we structured the team.
The other thing was like, we have a dedicated role called client facing engineer that is, you know, the same principle as a forward deployed engineer that works really closely with clients and kind of looks at individual feature requests that are not like long term platform roadmap, but like individually what does a client need,
spec it out.
hide it behind a feature flag roll it out in a pilot refine it make it more generalized and then roll it out everywhere else so there's a lot of like disciplines we've had to bring in really early on that are now you know like considered industry standard best practices
Yeah.
that we were just like forced into doing
Yeah.
Scott: Yeah, do the nature of those live events.
Brad: yeah yeah so but it's so it's tough so like so like going back to answering your question how do i how do we stop the um ai process from being um misused or not used correctly because there's multiple teams when a team when someone in the team um sends out a pull request other devs in their local team do a peer review once it's peer reviewed by their local team it goes to a team in another time zone to do their own peer review
Scott: Mm.
Brad: then it goes to a QA team to actually test that and then it goes into production and then in the last six months we've also now added three or four different AI code review bots as well to catch anything that the manual code review process doesn't.
Yeah.
Scott: Which ones have you been trying out that's been most effective?
Brad: Graphite was a really good one, Graphite and CodeRabbit, like that was like, you know, very, very early on, really,
really good.
And then Anthropic rolled out a Claude Code Security GitHub action.
So that was really good as well, because that could catch a different type of thing.
And then there's like Cursor Agent and GitHub Copilot, but like, I would say Graphite's still really good.
Scott: Mm-hmm.
Brad: And CodeRabbit's still really good.
And sometimes it's a false bug report,
but most of the time it will catch something that just got overlooked.
Yeah.
Scott: That the cloud code security is that what it's called I
Brad: Yeah.
Scott: think that's pretty clever. I think I like that innovation.
That's a valuable innovation
Brad: Yeah,
it's really nice because it's not just like a lint passer or a pattern matcher, like it's like actually an LLM going,
oh, what do I know about best practices and bugs that have been reported and exploits that have happened over the years and like, does this match any of those real life things that happened?
plus whatever's documented in terms of like standard exploits i
Scott: Mm hmm.
Yeah,
that seems like that kind of thing almost might start to become deep, like a default to people's build pipelines.
Like, why wouldn't you have that?
Brad: mean it really has to be and like you know sometimes you can get overloaded with those code review comments but wouldn't you rather that get picked it gets picked up now than you know you lose a client over it
Scott: Mm hmm.
Brad: It feels like a no-brainer to always have an AI coding agent do a code review.
Heck, have multiple of them, you know, CodeRabbit and Copilot.
Why not?
Scott: Well,
there's the code review,
but I think the security piece is especially interesting because
Brad: Sure.
Yeah.
Scott: of just how much risk it can reduce.
You know, look,
there's a difference between my mind between a vulnerability that could lead to an exploit that leads to using all your customer data.
versus we ship the bug,
which that's a type of bug.
But having been on the other side of a security, every time I get a letter in the mail,
you know you guys get letters in the mail that says such and such a company had an event.
And now you get to have your credit score watched for two years.
You ever get one of those letters?
Brad: Yeah, how many?
Once a month.
I've not had that yet,
but I have only been living in San Francisco for about four months,
so this might be a new thing.
Scott: Well, you wait,
you'll get it. So some company in the United States, I don't know exactly what the law is, but there's some criteria by where under certain circumstances,
a company is required to notify you if there's a data breach.
breach right and so i would say i get three of them a year three of these letters such and such a company had a data breach your data might not even been taken they don't even know they just know they have to disclose to everybody and then typically what they do is they say now here's two years of credit score monitoring software for free okay i always think but the point is i always think to myself
I know the guy who was on the other side of that letter,
and it was a really stressful day for him.
Brad: The CTO or the CSO or the, yeah.
Scott: Yeah,
because I've been that guy once.
I've been like one time in my life, there was a real data breach at a company that was at,
and it was, thankfully,
I don't mean this to come out the wrong way.
Thankfully,
it was software I had inherited and the data breach.
So it wasn't totally my fault is what I'm trying to say,
but that's what we're sharing.
But I still had to clean it up and it was really stressful and expensive.
In fact, here's a funny thing about it.
It was in the summer and on a Friday we were dealing with some sort of production issue.
I can't even remember what that was.
And it wasn't a huge thing, but it was a thing.
Whatever.
Friday wound down.
We all left and said we'll deal with this on Monday.
And I got a phone call on Sunday midday.
And I was out at a music festival, as a matter of fact.
And I thought it was going to be somebody calling about that saying,
hey,
we really shouldn't have put this down on Friday because it turns out it's been a bigger problem over the weekend and we're going to have to deal with it.
And it was totally different.
It was this security incident,
which is like,
hey,
we just got an email from somebody saying they have access to all of our systems and they want this much Bitcoin.
And you can only imagine,
I can't even recreate the emotion,
but I can, the emotion, I mean, at the time, I probably someone saw me, the blood drained out of my face.
And I was just like,
oh,
that's bad.
Brad: Yep.
Scott: So my point coming back to the Claude secure,
is it Claude?
Ritesh: security
Brad: Yeah,
Ritesh: is that what I'm
Brad: because
Ritesh: speaking
Brad: it's
Ritesh: I just think that's that's a no-brainer to stop those things because they're so painful that cost us
I had the cost of a million dollars to solve that problem that happened.
Scott: As we're starting to kind of approach the near the end of our conversation,
I am thinking,
Ritesh, I would love to hear more from your perspective as someone who clearly built this business you are incredibly passionate about. You took your technical expertise,
you took your passion for, you know, live music.
And you built an incredible business out of it.
I have been saying for a while that I think AI coding agents are going to make the solo entrepreneur or the two guys in the garage or the really small scrappy team so much more likely to succeed because they basically have this force multiplier of AI assisting them.
Agree, disagree.
How do you what do you think about that that thesis and how would have it applied to ticket fairy had had the AI coding agents been around 15 years ago?
I mean, look, massively agree.
I mean, there is, so my co-founder is
tech savvy but he's not a coder and in the last week he has built a really complex product to manage a bunch of internal processes and it integrates with a bunch of different apis and like systems that we have and google workspace and a bunch of other things and he's just been iterating 100 times a day and he's really detail-oriented and he's really smart but he's just he can't code
And it's given him and he's using Replit and it's given him the ability to roll out this super complex system that's way better than things we pay for and
Yeah.
that's very bespoke to what our requirements are and we will be using it and it's like and if you then build a product if you would a product person you come you're going to start a company from scratch and you use those same principles.
then absolutely that you can do the work of 20 people even though you're only two people and to be honest like what we're building on the ticker very platform side we're looking at that same force multiplier for the events industry you know can we give a two-person event production team the same execution ability as 20 people
Yeah,
there
So the principles they apply in other industries, they just got done in coding agents first because tech serves tech. But when we really start applying this to all industries,
it still applies.
you go.
There you go, Scott.
That's the AI bullish argument.
It's great for it's great for entrepreneurs.
They're going to just build
Ritesh: It is.
Scott: incredible stuff.
for the right entrepreneur i mean look at the end of the day you could build a product but you still need a business you need the business documents to be able to sell it you need to business documents to know what to build right so that doesn't stop you from it doesn't prevent you needing to know what you're doing or know like your industry or your subject matter or whatever it is like or your audience like that's
something an AI agent won't, I mean, it might teach you some of it, but it won't teach you all of it.
Right.
Ritesh: It's true.
Yeah,
it's true.
You know, I think, Brad,
you're right.
It's going to.
It's going to accelerate the solopreneur or the duopreneurs, right?
But it also takes a mindset.
I think there's a mindset that you still have to have.
I can't describe all that mindset other than to say curiosity is a part of it.
Willingness to explore and be curious and try and figure it out.
And it will help those people. But I think there's probably many people who, you know.
If you don't have that, it's still not going to help you.
Scott: Well,
also, if you don't have that curiosity,
that insatiable quest for learning more and open mindedness, you're probably not an entrepreneur, right?
Like entrepreneurs are driven by like they wake up in the morning and they go to sleep at night driven by the idea that they're going to solve a problem,
learn something new,
Ritesh: Yeah.
Scott: build something compelling.
Yeah, agreed,
agreed.
And there's also a constant thirst for learning, right? It's like I ingest.
as much information as humanly possible every single day but
Yeah.
that's i mean like i think that you should you need to do that if you're gonna have a unique insight because the more different areas of information you ingest
the easier it is to suddenly have that light bulb moment and be like oh wait i've just seen an overlap in an industry that's underserved or i've seen something where like this i can stitch these three things together and that results in something that's 10 times as big and that happens all the time my dev team hate me because like i'll go integrate with this and build this but build this in a certain way and don't use this library use this one and then like six months later they're like they realize that there was
There was a plan all along to play all together and they thought it was crazy at the time.
I love that story.
I love that.
I am curious about one last thing, and hopefully you can speak to this.
What about the death of sass?
And I feel like I wonder with you clearly have a sass product,
but it's clear that what you're bringing to the table is not just the software, but it's all the insights you have.
have from decades of doing this yourself and being a promoter and I just I just wonder is there is that part of the magic of successful SaaS companies or like Ticket Ferry are going to be based on deep insights into a particular vertical or a particular problem space
I'd say 95%.
yes there will be those outliers that know nothing about their industry and still succeed like the ceo of boom bumaro the company that's making supersonic planes he had no experience in aviation and aerospace before he did it and they're killing it and there are there are people that and then there's another guy that i forget which company is but it's a legal tech ai company and you know i think he just sat with a bunch of lawyers for a year or you know got a job as a
as an intern whatever it was but like you know just really learned about the the requirements of the industry so there will be those people but obviously like if you have the domain expertise and you have done it before and you have been in whatever industry sector you're trying to serve you have a way higher likelihood of succeeding because you have that deep like it's the one of the questions in the Y Combinator application is what do you know that others don't know and it's that
Yeah.
Ritesh: Mm hmm.
Scott: Love it.
Ritesh: That's fundamentally how startups and entrepreneurs should happen,
right, is that you well,
that's not all entrepreneurship. I mean, you could start a hair salon or something. But from in terms of innovation,
it is understanding something,
seeing something in the world or that others don't see and often being told you're crazy.
Scott: Oh, everyone thought we were crazy.
Everyone was like, and everyone misunderstood what we were trying to do.
You know, one of the first questions.
first questions you ask is are we competing with Ticketmaster and everyone thought that for so long that they were like we're gonna we're not gonna fund a company that would do this like it's too hard and then I was like well we're trying to build these 10 different modules in the software and they're like but you're only supposed to do one thing and do it well and I was like yeah but we're gonna we're trying to make people money and you have to do all of these things that's the one thing
So I wonder why you had to answer so down pat when Scott asked you if you would like Ticketmaster.
Well,
this has been super fun, Ritesh. I love the story. I love everything you've done to drive you've shown to get Ticket Ferry where it is. And it's super cool to hear your story.
And thanks for coming on the pod.
Appreciate so much.
Yeah, and we'll obviously include links to Ticket Ferry in the show.
in the show notes and stuff like that but um other than that anything else you want to say to the to the audience of the how many cto
I just want to say that it's been really nice having this conversation because I don't I don't get to go as technical as I would as I know I can on on most.
panel was a podcast or whatever it is now you talk about like conceptual products and you talk about business and music industry and whatever but like i've got to really go in like on some of the more tech concepts and that was really nice and
Yeah.
Ritesh: Perfect.
Scott: Awesome.
that real networks link from back in the day is
There you go.
didn't even know
Awesome. Well,
to our listeners,
remember to rate,
review,
smash that subscribe button,
and we'll see you on the next episode of.
of HowManyCTOsDoesItTakePodcast.
What's up?
Ritesh: Bye, everyone.
Scott: This episode of HowManyCTOsDoesItTakePodcast was edited by Saffron Epigal.
Our theme song was AI generated by Brad.
Please follow us on all the social media platforms at at HowManyCTOsPod.
You can find us on YouTube,
LinkedIn,
Instagram,
Facebook,
Threads, X,
TikTok,
and Patreon,
or at our website at HowManyCTOsPod.com.
And remember to rate, review, and subscribe on the podcast platform of your choice.
Thanks for listening.