WEBVTT

00:00:00.000 --> 00:00:40.950
And so we just hit a million dollars in ARR with our SaaS product, which we use Cloud Code to build. And I know a lot of people here are probably interested in using Cloud Code either independently or within an organization to put together some sort of SaaS app and then take it to market. So I figured in this video, I'd run you through basically everything that we did in order to get to where we wanted to and also share all the learnings along the way. So what is the SaaS? It's called Clarabo. It is essentially an AI enabled power dialer. And just to unpack those words, what this does is it allows us to make more calls per unit time and then have more of those calls picked up on the back end. And that works really well and is very powerful if you're in an industry that is traditionally pretty call based. So either you have some sort of funnel, where you have inbound leads and you need to call them very quickly and at mass,

00:00:41.190 --> 00:02:34.420
or, uh, you know, you're doing like traditional cold calling or outbound calling to try and acquire clients whom you don't have preexisting relationships with. And so anytime you're starting any business, whether it's a SaaS, e com, you know, service company, whatever, you need to have a very clearly defined problem that you were trying to solve. And so I'm gonna run you guys through exactly how we picked this problem later. But essentially, at a high level, we picked this because it has very high lifetime value, meaning that a single client that we get on our service will pay us a lot of money over the course of the next few years. Uh, it's very low churn because once we install it into a company, it's very unlikely that they're gonna just bow out. Their whole infrastructure depends on us. And then it's also very straightforward and easy to do in a market that didn't have a lot of, uh, other entrants. Cloud Code helped us come up with every single way, and I'll run you through a quick step by step on how to do it in a second. But just so that we're all clear, essentially, you know, an industry competitor might make a 100 calls an hour. These might be outbound calls to try and close some deals to strangers they've never met before, or it could be inbound calls calling a list of people that opted into some offer. From those 100 calls, because of dial times, connect times, people aren't present, people aren't picking up the phone from numbers they don't recognize, maybe only 40% of those will actually pick up. So if you think about it right off the bat, the salesperson is making a 100 calls, only 40 people are picking up. There's sort of a 2.5 x drop off right there. And so if you just do the math, you have a salesperson working eight hours a day, they're capable of getting 40 pickups an hour. It's like how many actual conversations are you having? Let's say they do that every day for a month, maybe they make 10 k a month. What Clarabo does is allows you to make more calls in the front end. So now we're capable of doing, let's say, 200 calls an hour instead. And then it also increases the fraction of people that pick up because the calls are more recognizable. We use a couple of cool cloud code based algorithms to, like, uh, dial multiple numbers simultaneously and then also double and triple dial if needed. Uh, and then, basically, at the end result is you you just make more money. So in our case, we have more calls. We have a higher pickup rate, and so there's significantly more people that are actually on the phone. And, uh, right now, we're capable of generating, you know, somewhere between 50 to 80% improvements to the companies that we work with. We took a pretty sizable business from Texas from somewhere between 3 to $5,000,000

00:02:34.420 --> 00:03:38.405
per month, uh, which is almost, uh, you know, double their their revenue. So And this is the sort of value proposition that NetClarbo has. So how do actually use Claude here? Well, I should note that we didn't actually know how to solve this problem when we started. Uh, we actually had Claude walk us through every possible way that it knew of to improve pickup rates and increase the total number of calls we could make per unit time. And, uh, most of the ideas were absolute trash. But after mining Claude for 200, 300 ideas, a couple of them were actually pretty good. And so the process, if you're interested, is we literally said, hey, we're building insert product here. You know, it is in our case an AI power dialer for local service businesses like HVAC, plumbing, roofing, etcetera. Our core metric to optimize is call pickup rate, which is defined as the percentage of dialed numbers that result in a live human answering within say ten seconds. So here we have the current baseline, we have the industry ceiling, and then we even had our target. So what I told us to do was spawn 10 parallel sub agents. Each one should propose 10 distinct mechanisms we can use to increase pickup rate. I also want you to diverge each of these wildly. Do algorithmic, behavioral, infrastructural, regulatory, psychological, time based, identity based mechanisms.

00:03:38.565 --> 00:04:19.945
Don't self censor for any feasibility. I'm gonna do all this later. And so after it comes up with all of these ideas, and it's gonna come up with a lot of ideas as mentioned, what we're gonna do is we're just gonna take them and then verify, okay, is this, like, a total BS idea or is it like an okay idea? And so here we go. We now have a variety of results. Uh, a lot of them are hard duplicates as well. But just going top to bottom, the first is a temporal propensity model, which is basically using AI to determine, um, an optimal call window, aka when to call people. This So is legitimately something that we do at Claro. We have optimal call windows based off of, uh, average pickup times per, you know, time of day, essentially. But at the same time, some of these other ideas are total b s. So weather times pickup progression, you know. Can we run a regression, which is a statistical analysis

00:04:20.290 --> 00:04:56.930
on historical pickup rates versus hyper local weather? Uh, you know, just off the top of my my head, that's probably not gonna be anywhere near as valuable as doing some sort of like call based, uh, on time, let's say. And so you're gonna get tons of ideas like these and, the majority of them are gonna be junk. But you're gonna find a couple that work. And so in our case, this is literally what we did. We ideated over all of the possible ways to improve something. After you're done with that, we shortlist one of these ideas. And so in our case, predictive pacing was actually a pretty well known idea. It's not something we invented. Uh, ClockCode definitely didn't invent. But, know, it's an idea that we wanted to explore and see, okay, what sort of alpha would there be if, you know, rather than just call one person, we have to call multiple people simultaneously.

00:04:56.930 --> 00:05:13.295
Essentially, uh, because the amount of time it takes to dial somebody is very fixed. Like, you think about it, you enter a phone number in and then you you stay on the line, it goes ding ding ding ding ding ding. Uh, what that means is if the person doesn't pick up, you've just wasted all that time as a salesperson. So if your your goal is optimally to be more efficient,

00:05:29.615 --> 00:05:33.535
And so this isn't just limited to two people. We actually use an algorithmic model

00:05:33.535 --> 00:05:34.815
that specifically

00:05:34.975 --> 00:05:38.575
imbues, like, offsets into our multiple call thing

00:05:38.815 --> 00:06:34.955
that is proven, and we've seen it in our data, to call and get picked up by the optimal amount of people per unit time. Do some people pick up at the same time, and then that results in kind of an op a weird awkward situation? Yeah. But we also have a built in call routing so that if, you know, we make multiple dials here, one of them doesn't get picked up, it actually goes to an agent that might actually be available. So it's a queuing system which, you know, Cloud Code obviously helped us build. But it all started like right here. This is the exact same approach that we use in order to figure all that out. And so once you have the simulation harness, you know, you feed it in a bunch of data on historical call times, which we accumulated through our own businesses and then businesses of other people. Now we have something we can run stats on. And we can figure out, okay, what's the optimal offset for this, you know, batch of 50,000 calls, let's say, in order to determine, you know, what our what our offset needs to be. Once you're done with that, you feed it in another prompt that says, hey, I want you to now implement this predictive pacing simulation from spec above. Here is some historical data. I want you to optimize for these things using, in this case, Bayesian optimization.

00:06:35.275 --> 00:06:41.195
Obviously, this is gonna depend on the specific problem you're trying to solve. But what I'm trying to say is, we just had Claude code, you know, figure out

00:06:41.770 --> 00:06:51.370
the ways to improve what we wanted to improve and then actually implement that in a simulated environment. Finally, you build the thing, which in our case was this predictive pacer, and then you roll it out in real businesses.

00:06:51.610 --> 00:07:33.755
And, you know, I think this is probably the thing that's gonna trip up a lot of people because don't have real preexisting businesses that are currently live right now that they can test things out on. And that's why data is ultimately quite the moat. If you have the data and then you also have the means to deploy something and do, you know, parallel testing, you can you can usually get through this sort of thing way faster. Okay. And that takes me to this general sort of loop. In order to do this sort of thing effectively, what you always start with is you start by defining a problem. And of course, you can have Claude code help you do the idea mining and the problem definitions. That's okay. But in our case, we just knew this was a problem that a lot of people were willing to pay a fair amount of money for. Then you say, hey, Claude. How can we solve this problem? I want you to enumerate aka list all possible solutions to, you know, the problem of, let's say, call pickup rates.

00:07:34.155 --> 00:08:51.550
Then what you do after that is you apply your little human brain, your little sponge, and you say, okay, which one of these are total bullshit? And which one of these are actually somewhat feasible? And so in our case, we had a short list of maybe five or six out of several 100 that were actually feasible. And, you know, over time, we're going through the the the the rest of them as well just to verify that this is something that can actually add some alpha, some delta to, you know, call pickup rates. But the vast majority of the time, it's one of those things that you'll just read and you'll be like, okay. Yeah. This is obviously the one. Once we're done, we design some simulations with clog code, usually based off some form of historical data. And then we run a statistical model, in our case, the, uh, predictive pacing algorithm in order to actually have that perform better. Then we iterate in some sort of simulator. AKA, we have Cloud Code just, like, change the the the parameters of our models that it gets better and better and better. And then finally, we have, like, a real life stress test where we actually roll it out. And, I mean, it can fail at any step along these lines here. We've had a variety of, you know, pretty cracked out approaches that we thought were gonna work really well in the sim because we saw better improvements in our stats. But then when we rolled them out to real life, we're like, oh my god. Wait a second. There's actually this third variable here that confounds and kinda ruins everything. So, you know, it's not easy. If it was easy, you'd have everybody doing it. And if everybody was doing it, nobody would be making any money. But this is how we ideated on the set of core features, uh, of Clarvo that ultimately ended up making us a fair amount of money. But the pricing is $250

00:08:51.255 --> 00:09:01.895
month, which is not like a scientifically determined price. We started by pricing close to, like, a $100 a month, and we figured out that people were willing to pay for it. So then we increased the price, figured out people were still wanna pay for it, increased the price.

00:09:02.295 --> 00:09:20.140
You know, I think people that are trying to use these big statistical pricing models or have AI, like, determine what the best price is are usually just wrong. A much easier and simpler way is just like pick a price and then sell it to a bunch of people. And if it's easy and they say yes, then just keep increasing the price until eventually it gets hard. In general, with SaaS companies, there's a big spectrum of possible prices.

00:09:20.655 --> 00:09:24.735
If this is our spectrum here, at the very left is basically what is called

00:09:25.295 --> 00:09:26.255
low touch.

00:09:26.495 --> 00:09:47.340
Low touch SaaS businesses, generally speaking, are like self serve. What that means is it's like a self guided onboarding. There's like maybe a video from the founder. You pay like $5.10, $15.20 bucks a month. And then everything's like kinda done for you. And, you know, these can be really good, but my head canon, my my personal belief is in an era where a cloud code and other agents are capable of whipping up basically any SaaS,

00:09:47.820 --> 00:10:05.825
you know, like, gotta ask yourself, at a certain point, any business owner will be willing or able to make the trade off of just paying money for tokens to actually just rebuild the whole thing. So rather than us sort of going really cheap and really small and solving a tiny problem, we decided to go the exact opposite direction. And we ended up solving a pretty big problem, kinda closer to the enterprise,

00:10:06.480 --> 00:10:08.320
with what's called a high touch SaaS.

00:10:08.560 --> 00:10:24.635
So Clarivos sits sort of right around here. And typically, we don't just sell individual licenses. It's not like, you know, a single user can't sign up if they want to. But in general, we work with companies and then roll this out to a pre created team of people that are doing calling. So for instance, you know, we sign a 100 seat deal at $250

00:10:24.635 --> 00:10:28.235
a month. Well, if you think about it kinda mathematically, that's $25,000

00:10:28.235 --> 00:10:33.195
MRR, which is 300 k ARR. So that's more or less what we've done. We've closed a handful of deals with sort of, like, mid market,

00:10:33.595 --> 00:11:18.990
to maybe larger businesses that operate in a variety of very call heavy industries. Only takes a couple of those people to say yes, to roll it out to their team, and then make a fair amount of money. On the pricing point, my big take on a lot of this is nowadays, anybody can build virtually anything. If you look at the total number of commits over time, okay, they are skyrocketing, and that's because AI is doing the vast majority of the intellectual heavy lifting now. So it's no longer can you build insert software product here because we can all build it. The the the bottleneck, the moat, like the value that you have is what should you build and, you know, essentially, how should you price. So what you quickly realize is that the vast majority of frameworks are total fluff. You know, we tried a lot of agent frameworks for Claro. We tried, uh, Ermies. We tried OpenClaw. We tried a bunch of these context libraries,

00:11:19.445 --> 00:11:23.925
basically made, like, vector dBs of your memory. We probably tried, like, 50 different approaches.

00:11:24.085 --> 00:11:27.445
And I can definitively say, for the purposes of

00:11:27.605 --> 00:11:30.245
creating a software product that later generates revenue,

00:11:30.485 --> 00:11:58.055
basically, every additional framework you use is, like, inversely correlated with the amount of money you make. Because every time you jump on a different framework, you are not only distracting yourself and pulling away from, like, the thing that you're trying to build. Um, typically, you have, like, regression within whatever the code base is because now the prompt is being understood or mediated a little bit differently than it was before. And for those of you guys that don't know, regression is just where, you know, you had an approach previously that worked really well. Let's say, some vanilla thing with, a small little CloudMD.

00:11:58.135 --> 00:12:09.760
But because now you're you're doing it through a different framework, like a lot of the assumptions and memories and and and things that the model used to know about your code base no longer works, uh, which is quite unfortunate. And so, you know, rather than jump around a lot and try and like,

00:12:10.000 --> 00:12:13.760
uh, aim for that a 100% quality, uh, or like a 100%

00:12:13.760 --> 00:12:29.200
score, uh, IQ test of the model, I would rather have the model work 90% as well of like its total potential, let's say. But I'd have it work consistently and be the same every single time. The real value that I think not a lot of people understand is that, you know,

00:12:29.760 --> 00:13:27.790
the intelligence comes from the model itself these days. It does not come from the shiny framework that wraps around it. You slapping on some new framework to, you know, the way that your your team is building on cloud code is kind of like people that put a fuzzy cover on their steering wheel, and then they pretend that that's the reason why their car works so good. Like, obviously, that's not the reason why your car works so good. Your car works good because it has wheels. It has an engine. It has a chassis, and so on and so forth. It's the craftsmanship of the person that built all of that. But, you know, you, because you wanna be all special and and new and stuff like that, put put your little fuzzy steering wheel on and they go like, oh, yeah, this is way better. That's not a genuine improvement. That's just your subjective improvement. And so I think human beings, we wanna take credit for everything, even if it's not necessarily ours. And so we do the virtual equivalent of slapping on a bunch of, like, fancy fuzzy covers, aka all of these Hermes agents and and and Open Claw tools and stuff like that. Um, when in reality, the thing that's making the car go is is the is the base model. And so that's why if you guys look deep into the people that actually created

00:13:27.950 --> 00:13:31.710
a lot of these technologies, like Boris Terni, for instance, who's one of the creators of Cloud Code,

00:13:32.030 --> 00:14:50.085
these people typically have, like, nothing of substance in their Cloud. Md files. They have nothing in their system prompts. They they're literally just using the vanilla intellect of the model. And the vanilla intellect of the model is usually, for all intents and purposes, pretty damn good. You'll only get marginal improvements applying one of these frameworks. And what you find is, you know, Cloud Code's getting so good so quickly nowadays that if there is a marginal improvement that gives you like a 5%, uh, plus ROI, the next generation of the tool, maybe like three or four days later, will actually already include that. Either hard coded into that system prompt or maybe actually just part of like the training of the model. The second thing is to pick problems that actually pay. And so the idea is, k, you can build more or less anything. And so this left hand side Venn diagram are all of the things that you could build, and every green dot is the thing that you have decided to build. You're not gonna make any money. What you want to do, k, is find that small little slice of the Venn diagram on the right hand side that people will actually pay for. So these are things like red hot problems. They're industries and issues on a big budget. So it's people with a preexisting pain. And then what you wanna do is you just wanna focus all your time over here. And so with Clarivo, that's what we did. We saw just how inefficient a lot of salespeople were and how literally just getting on, um, a power dialer, because this isn't a new idea of of power dialer. But we saw, like, the difference between not having a power dialer and then having a power dialer was,

00:14:50.760 --> 00:15:01.640
three x effectiveness. Then we're like, okay. What if we could just make actual preexisting power dollars even better? And we're like, okay. If we can generate even, like, a two x effectiveness, we'll be able to to take a a large portion of the value that we provide for companies.

00:15:02.040 --> 00:15:15.405
And so that's that's the moat. That's sort of where you need to sit if you really wanna crush it in SaaS nowadays. And so everything exists on this problem value spectrum. You know, on the left hand side, you have a bunch of lukewarm problems. These are things that are nice to have, but they're not necessary to have.

00:15:15.965 --> 00:15:18.925
And this is unfortunately where probably like 90% of people spend their time.

00:15:19.580 --> 00:15:32.140
And I built, you know, a bunch of demos showing you how you could put together to do apps and simple browser extensions and simple productivity tools and so on and so forth. But the harsh reality is, you know, if the problem isn't big enough to justify somebody,

00:15:33.165 --> 00:15:39.165
you know, choosing your SaaS over, like, building it all themselves, because as mentioned, software is now quite easy to build. Anybody could just

00:15:39.885 --> 00:16:05.915
convert tokens into product just at some sort of exchange rate. You know, if it's not a big enough problem, people are just gonna do that. And the longevity of your SaaS is going to be significantly smaller than if you picked like a red hot burning problem. So in our case, we picked something that is currently costing organizations millions of dollars a year. They'll pay anything to fix their to fix their pickup rates or improve it if they know that it's an option. And, uh, so this is more or less what what we've done. So instead of solving a, you know,

00:16:06.315 --> 00:16:18.460
I don't know, marketing for dog walkers, where it's like the average dog walker probably makes, like, a thousand bucks a month or something like that, you know, solve a core need for a large, usually mid market and up style company.

00:16:18.620 --> 00:16:34.775
Uh, people that actually have budgets and typically also have many seats that would need to subscribe to these budgets in order to solve some problems. So as mentioned, uh, we implemented this on our HVAC clients, And it says, uh, a year here, but it's it's literally a month for the AI. Just didn't believe me when I said it was legitimately a month. Uh, and we took them basically,

00:16:34.935 --> 00:16:38.535
uh, we increased their their multi revenue by 66%.

00:16:38.855 --> 00:16:57.355
And so if you think about it, like, did we do? The delta there is 2,000,000 a year in revenue. And typically, way that it works is if you solve a problem, k, you are, uh, I don't wanna say entitled to, but you can typically negotiate or ask for somewhere between 10 to 15% of the total amount that you are providing. So And we provide $2,000,000

00:16:57.355 --> 00:17:06.875
a month to this company, 24,000,000 a year. It is not unreasonable for us to ask for or at least be in a position where we can negotiate a tenth of that or $2,400,000

00:17:06.875 --> 00:17:26.395
a year. And so this is the sort of problem that ultimately you want to solve. You know, you wanna find people that have the means to pay for, uh, this red hot burning thing, but you also need the problem itself to be quite valuable. If it's not, probability of you, you know, getting anywhere with that is quite low. Another hack is to pick an industry or a SaaS type that requires some form of human implementation

00:17:26.555 --> 00:17:28.555
or, like, human onboarding.

00:17:28.715 --> 00:17:33.515
What I mean by this is, you know, if everything that you do is entirely digital,

00:17:33.835 --> 00:17:35.035
then it is

00:17:35.275 --> 00:17:49.490
pretty reasonable to expect that in the next couple of years, AI will be able to do it better than your team. And so, you know, you're onboarding your tool into the company is nowhere near as valuable as just like, hey, Cloud. Can you do it all for me? And I think Cloud will be able to do that for most things fairly shortly.

00:17:49.970 --> 00:17:53.825
But the one thing that I can't currently do is it can't upend, like, regulation.

00:17:54.065 --> 00:18:17.100
You know, if you need, in our case, a bunch of numbers applied for, you need a two p registration. And that's just like a fixed thing. That's like a law. That's like a regulation. You can't just say, Claude, screw screw the ATP registration. Get me 5,000,000 phone numbers. Because both for moral, ethical, and programmed in reasons, Claude will will say no. But also, uh, there's just no way to get the number unless you actually go through this like pretty bureaucratic process.

00:18:17.735 --> 00:18:40.080
And so what I mean by that is like in a future where, uh, there's no moat to to doing, you need to look for natural notes that are created by regulatory environments. In our case, things like numbers, for instance. Another great example of that is like in health care. Everybody complains about HIPAA all the time, myself included, because, you know, it's it's quite the blocker to US health care implementing any sort or or building any sort of, like, cool transcription service.

00:18:40.160 --> 00:18:56.935
We'll require you to, like, fastidiously adhere to HIPAA principles, and that can slow you down a lot. You need to anonymize your data and so on and so forth. But viewed another way, that's actually a major opportunity in, an AGI world because that's the only thing that is currently stopping us from being able to, you know, do things. Legitimately having some sort of, like, certification,

00:18:56.935 --> 00:19:03.480
let's say, or some sort of board approval of rolling something out. And so as a as a company, as a SaaS, if you could build

00:19:03.480 --> 00:19:06.200
some form of human implementation, human onboarding,

00:19:06.440 --> 00:19:32.710
you know, a human responsible for maintaining the relationship between you and the advisory board that needs to to rubber stamp the thing, then you'll go way further. And so in our case, you know, we have a bunch of relationships and connections with people that know how to do these things and facilitate them a lot faster, and that that's one of the moats that I think will actually carry us forward in the next couple of years as opposed to, you know, big AI just pulverizing the vast majority of these low touch, low ticket SaaSes. Finally, one last tip is to make whatever your code base is model agnostic.

00:19:32.710 --> 00:19:45.115
So I know the whole point of this video is that we built it with Cloud Code. Um, I would say that's, like, 90% true. In addition to Cloud Code, we obviously tried a variety of other models. So we tried a deep seek to arbitrage token costs on, like, constant long running twenty four seven,

00:19:45.515 --> 00:19:57.450
uh, like, restructuring and refactoring and stuff like that. Constant, like, bug fixes and and and so on, and, uh, that worked okay. We tried Codex a number of times. Our team is increasingly using Codex just as we've run into, like, some

00:19:58.090 --> 00:20:46.805
token issues and the the tokenomics essentially are the main thing that are that are holding us back from going all in on Cloud Code twenty four seven. But also, I think, uh, over the course of the next few months, you'll probably see fluctuations in the quality of each of these models and the availability of each of these models because, uh, you know, like the major AI companies are starting to get very compute restrained because everybody on planet Earth wants one of these models now. They're realizing how economically effective they are. And so you need to be able to just, like, hot swap your code base at will from, let's say, like a Cloud Code based project to, a Codex project. And this isn't really that hard at all. It's just like a a little bit of friction that I think slows people down. But, uh, Clarivo, we just made our our code base totally model agnostic. And what that means is, like, you know, Claude code has, a skills spec. It expects a claude.md and so on and so forth. Uh, we just have, like, you know, an agent's MD. We have the agent's skill spec. We have, uh, you know, the same things for Gemini, gemini.md.

00:20:46.820 --> 00:20:53.940
Just in case at any point in time, we wanna hop over or maybe employ a different model to see if maybe that model can solve a problem that we're struggling with.

00:20:54.340 --> 00:21:10.715
You know, it's just like that. And anybody in our team has the ability to to do so. And so the real actionable tip here is just duplicate everything and then probably have Claude go through the specs of each of these models and just like make sure to prepare the workspace so that at any point in time, you have the ability to, you know, instant preload all of your system prompts and and so on.

00:21:11.035 --> 00:21:48.200
And MCP specs and then skill specs are actually currently understood differently from, like, Claude versus other, uh, platforms. Like, not all platforms do the YAML front matter tuning, for instance, where they'll only preload, uh, like, the name and the description of the skill. Um, some of them will actually load the entire thing. These are just slight little model differences that you can optimize around that'll, you know, allow you and other people within your company to operate much faster. Okay. I hope you guys liked the video. I had a lot of fun putting it together for you. As mentioned, obligatory pitch for the SaaS company. That was sort of the case study for this whole video of Clarivo. If If you you guys guys wanna wanna improve your pickup rates, definitely check that out because, you know, we're experimenting with with pricing in a variety of different things.

00:21:48.760 --> 00:22:21.965
You know, I I'll add a link to the top of the description so you guys can give that a quick click and go through if you'd like. More generally, if you guys wanna learn how to monetize AI automation and SaaS apps in this way, definitely check out Maker School. It's my ninety day accountability program where it will guarantee you that you get your first customer for an AI or automation related service within that time period, or I give you your money back. And if you guys have any ideas for future videos, or if you guys want me to record something on a specific topic that is trending, interesting, or just sort of stream of consciousness, feel free to let me know. I take most of my video ideas at this point from people in the comments. Okay? Thank you again for watching, and I'll catch all y'all in the next