Hey, 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 uh also share all the

learnings along the way. So, what is the

SaaS? It's called Clarivo. 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 en

masse 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're

trying to solve. And so, I'm going to

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 a lifetime

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 going to 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

100 calls an hour. These might be

outbound calls to try and close some

deals to strangers they've never met

before or 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, a salesperson's making 100

calls, only 40 people are picking up,

there's sort of a 2.5x drop-off right

there. And so, if you just do the math,

you have a salesperson working 8 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 10K a month. What

Clara does is allows you to make more

calls in the front end. So now we're

capable of doing what 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 dial multiple numbers

simultaneously and then also double and

triple dial if needed. And then

basically at the end result is you just

make more money. So in our case we have

more calls, we have a higher pick up

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 million dollars

per month, uh which is almost uh you

know, double their their revenue. And so

this is the sort of value proposition

that Net Clever has. So how do you

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 pick up 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-powered dialer for local

service businesses like HVAC, plumbing,

roofing, et cetera. Our core metric to

optimize is call pick up rate, which is

defined as the percentage of dialed

numbers that result in a live human

answering within say 10 seconds." So

here we have the current baseline, we

have the industry ceiling, and then we

even had our target. So what I told it

to do was spawn 10 parallel sub agents.

Each one should propose 10 distinct

mechanisms we can use to increase pick

up rate. I also want you to diverge each

of these wildly. So do algorithmic,

behavioral, infrastructural, regulatory,

psychological, time-based,

identity-based mechanisms. Don't

self-censor for any feasibility. I'm

going to do all this later. And so after

it comes up with all of these ideas, and

it's going to come up with a lot of

ideas as I mentioned, what we're going

to do is we're just going to take them

and then verify, "Okay, is this a like a

total BS idea or is it like an okay

idea?" And so here we go. We now have a

variety of results. 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

an optimal call window, aka when to call

people. So, this is legitimately

something that we do at Clara. We have

optimal call windows based off of

average pickup times per, you know, time

of day, essentially. But, at the same

time, some of these other ideas are

total BS. So, weather times pickup

regression, you know, can we run a

regression, which is a statistical

analysis, on historical pickup rates

versus hyper-local weather. Uh you know,

just off the top of my my head, that's

probably not going to be anywhere near

as valuable as doing some sort of like

call-based on time, let's say. And so,

you're going to get tons of ideas like

these, and yeah, the majority of them

are going to be junk. But, you're going

to 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.

Clara could definitely didn't invent.

But, you 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,

they actually call multiple people

simultaneously. Essentially, because the

amount of time it takes to dial somebody

is very fixed. Like, if you think about

it, you enter your phone number in, and

then you stand on the line, it goes

din-din-din, din-din-din.

What that means is if the person doesn't

pick up, you just wasted all that time

as a salesperson. So, if your your goal

is optimally to be more efficient, the

actual optimal play is not just to call

one person and have the din-din-din,

din-din-din. It's actually to call two

people and have the din-din-din,

din-din-din. Because if one of those

people doesn't pick up, well, no

problem, you've taken the total amount

of time it would have made to make that

dial, and then you connected with this

person anyway.

And so, this isn't just limited to two

people. We actually use an algorithmic

model that specifically imbues like

offsets into our multiple call thing

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 up

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,

Claude 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 this 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 the spec above. Here is

some historical data. I want you to

optimize for these things using, in this

case, Bayesian optimization." Obviously,

this is going to 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

the ways to improve what we wanted to

improve, and then actually implement

that the simulated environment. Finally,

you build the thing, which in our case

was this predictive pacer, and then you

roll it out in real businesses. And, you

know, I think this is probably the thing

that's going to trip up a lot of people

because they don't have real

pre-existing businesses that are

currently live right now that they can

test things out on. And that's why data

is ultimately the 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. Of course, you're

going to have Claude code help you do

the idea mining and the problem

definitions. That's okay. Um 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."

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 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 hundred 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 if 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 Claude code, usually

based off some form of historical data,

and then we run a statistical model, in

our case the predicted pacing algorithm,

in order to actually have that perform

better. Then we iterate a simulator,

okay, we have Claude code just like

change the the the parameters of our

models so 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 going to 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 kind of 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 of

Clarvo that ultimately ended up making

us a fair amount of money. But the

pricing is 250 bucks a month, which is

not like a scientifically determined

price. We started by pricing close to

like 100 bucks 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 willing to

pay for it, increased the price. Uh 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. The

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. Um if

this is our spectrum here, at the very

left is basically what is called um low

touch. 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 is kind of done for

you. And, you know, these can be really

good, but my head cannon, my my personal

belief is in an era where Claude code

and other AI agents are capable of

whipping up basically any SaaS,

you know, like you got to 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, um and we

ended up solving a pretty big problem

kind of close to the enterprise

uh with what's called a high-touch SaaS.

So, Clervo sits sort of right around

here, and typically we don't just sell

individual licenses. It's not like uh

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 a

month, well, if you think about it kind

of mathematically, that's $25,000 MRR,

which is 300k ARR. So, that's more or

less what we've done. We've closed a

handful of deals with sort of like

mid-market uh uh to maybe larger uh

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, cuz we can all build it.

The the the bottleneck, the mode, 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. Now, we

tried a lot of agent frameworks for

Clervo. We tried Hermes, we tried Open

Claw, we tried a bunch of these context

libraries, uh basically made like vector

DBs of your memory. We probably tried

like 50 different approaches. And I can

definitively say for the purposes of

creating a software product that later

generates revenue, basically every

additional framework you use is

inversely correlated with the amount of

money you make. Cuz 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. Uh 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. 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 like a small little cloud and

MD. Uh 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. So, you know, rather than

jump around a lot and try and like

uh aim for that 100% quality uh or like

a 100% 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,

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

uh 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. Uh but, you know, you

cuz you want to be all special and and

new and stuff like that, uh put put your

little fuzzy steering wheel on and then

go like, "Oh yeah, this is way better."

It does not a genuine improvement.

That's just your subjective improvement.

And so, I think human beings, we want to

take credit for everything even if it's

not necessarily ours. And so, we do the

uh virtual equivalent of slapping on a

bunch of like fancy fuzzy covers, aka

all these Hermes agents and and and open

claw tools and stuff like that. Uh 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 like

created a lot of these technologies.

Like Boris Cherny for instance, who's

one of the creators of Claude code.

These people typically have like nothing

of substance in their Claude.md files.

They have nothing in their system

prompts. 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, Claude code's getting so good

so quickly nowadays that if there is a

marginal improvement that gives you like

a 5% a plus ROI, the next generation of

the tool, maybe like three or four days

later, will actually already include

that. Either hardcoded into its 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, okay,

you can build more or less anything. And

so, this left-hand side of the Venn

diagram are all of the things that you

could build, and every green dot is a

thing that you've decided to build.

You're not going to make any money.

What you want to do, okay, 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 niches that have big

budgets. It's people with a pre-existing

pain. And then what you want to do is

you just want to focus all your time

over here.

And so, with Clarabridge, that's what we

did. We saw just how inefficient a lot

of sales people were and how literally

just getting on a power dialer, cuz this

isn't a new idea to power dialer,

but we saw like the difference between

not having a power dialer and then

having a power dialer was like 3x

effectiveness. Then we're like, "Okay,

what if we could just make actual

pre-existing power dialers even better?"

And we're like, "Okay, if we can

generate even like a 2x effectiveness,

we'll be able to to take a large portion

of the value that we provide for

companies."

And so, that's that's the most That's

sort of where you need to sit if you

really want to 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.

And this is unfortunately where probably

like 90% of people spend their time.

And I'd built, you know, a a 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

uh you know, choosing your SaaS over

like building it all themselves because

as mentioned, software's now quite easy

to build. Anybody can just

uh convert tokens into product just at

some sort of exchange rate. You know, if

it's not a big enough problem, people

are just going to do that and the

longevity of your SaaS is going to be

significantly smaller than if picked up

a red-hot burning problem.

So, in our case, we picked uh something

that is currently costing organizations

millions of dollars a year. They'll pay

anything to fix their to fix their

pick-up 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,

I don't know, uh 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.

Uh people that actually have budgets and

typically also have many seats that

would need to subscribe to these budgets

in order to solve said problem. So, as

mentioned, uh we implemented this on one

of our eight-figure clients and it says

uh a year here, but it's it's literally

a month. I think the AI just didn't

believe me when I said it was

legitimately a month. Uh and we took

them basically uh we increased their

their monthly revenue by 66%.

And so, if you think about it, like what

did we do? The delta there is two

million a year in revenue.

And typically the way that it works is

if you solve a problem, okay, you are uh

I don't want to say entitled to, but you

can typically negotiate or ask for

somewhere between to 15% of the total

amount that you are providing. And so,

we provide two million dollars a month

to this company, 24 million 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.4 million

dollars a year. And so, this is the sort

of problem that ultimately you want to

solve. You know, you want to 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 or like human onboarding.

What I mean by this is, you know, if

everything that you do is entirely

digital, then it is 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, your onboarding your

tool into the company is nowhere near as

valuable just like, "Hey Claude, can you

do it all for me?" Claude will be able

to do that for most things fairly

shortly.

But the one thing that AI can't

currently do is it can't upend like

regulation. You know, if you need, in

our case, a bunch of numbers applied

for, you you need A2P 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 A2P registration, get me 5 million

phone numbers." Because both for moral,

ethical, and programmed-in reasons,

Claude will will say no. But also,

there's just no way to get the number

unless you actually go through this like

pretty bureaucratic process.

And so, what I mean by that is like in a

future where there's no moat to to

doing, you need to look for natural

moats that are created by regulatory

environments. In our case, things like

numbers, for instance. Another great

example of that is like in healthcare.

Everybody complains about HIPAA all the

time, myself included, because, you

know, it's it's quite the blocker to US

healthcare implementing any sort of or

building any sort of like cool

transcription service. It will 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 like 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, 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 some form of

human implementation, human onboarding,

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 SaaS's. Finally, one last tip

is to make whatever your code base is

model agnostic. So I know the whole

point of this video is that we built it

with Claude code. Um, I would say that's

like 90% true. In addition to Claude

code, we obviously tried a variety of

other models. We tried a deep seek to

arbitrage token costs on like constant

long-running 24/7 uh 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. Um,

our team is increasingly using Codex

just as we've run into like some um

token issues. And the the tokenomics

essentially are the main thing that that

are holding us back from going all in on

Claude code 24/7.

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 Claude code

base project to like 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 Clarifai, we just made our our

code base totally model agnostic. And

what that means is like, you know how

Claude code has like a skills spec and

it expects a Claude.md and so on and so

forth. Uh we just have like, you know,

an agents.md. We have the agents skills

spec. We have uh you know, the thing

things for Gemini, Gemini.md. Just in

case at any point in time we want to hop

over or maybe employ a different model

to see if maybe that model can solve a

problem that we're struggling with. Um

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

so on. And um 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 will uh you know, allow you

and other people within your company to

operate much faster. Okay, I hope you

guys like the video. Had a lot of fun

putting it together for you. Um as

mentioned, obligatory pitch for the SaaS

company. That was sort of a case study

for this whole video, Clearvo. If you

guys want to improve your pickup rates,

definitely check that out um because,

you know, we're experimenting with with

pricing and a variety of different

things. Um you know, I'll I'll add a

link to the top of the description so

you guys can give it a quick click and

go through if you like. More generally,

if you guys want to learn how to

monetize AI automation and SaaS apps in

this way, definitely check out Maker

School. It's my 90-day accountability

program where we'll 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 specific topic that

is trending, interesting, or just sort

of stream of consciousness, uh 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 video.