You've probably tried to build a SaaS before. You likely have tons of failed projects, like I do. It's starting to

become apparent that building a SaaS, although people say it's easy, it's actually pretty difficult to do.

There are boilerplates you can buy; yes, there are a ton of templates you can use. But what usually happens is those

solutions fall apart. You didn't code it, so now you're not familiar with it. It requires a ton of support; you're stuck

in a Discord group chatting with people. It can be a long slog. So I'm not going to sit here and tell you it's easy to do,

but it's definitely possible. And one of the first reasons why building a SaaS is so difficult is this

analysis paralysis that happens to most people. You're overthinking a lot of the technical decisions; you don't know what

choices to make, so you're stuck in this gridlock, always continuously evaluating tools. You're overwhelmed by these

tools. There's a lot—like Bolt, Supabase, Vercel—what do they do? What are they good for? Constantly trying to

compare back and forth. You're also stuck in this start-and-stop cycle where you start something, you have some early wins,

but then you can't really finish or follow through at all. And finally, you're scared to commit to these ideas, right?

They're sometimes—the idea sounds good at the onset, but as you start working on it, you feel like there's another idea

that's a little bit better, so you want to switch gears and go into something else. Now these are the classic mistakes

I've made while trying to build a couple SaaS products throughout the year. You've seen them on this channel; I've had four

or five that I've tried to launch. I'm finally launching one, but these are some of the mistakes I've made. The first one

It's like the Eternal Hacker Syndrome. This is the idea where I was constantly switching between frameworks. I was

trying LangChain, LlamaIndex, ControlFlow—a ton of AI frameworks I was trying before I decided to ditch the frameworks

and just go with coding things from scratch myself. And it just resulted in me being definitely happier rather

than trying to always keep up with those frameworks. The second one was zero process. I didn't have any process in

place to go from idea to something live on a link. So every time I had a new idea, every time I wanted to start something, I

was basically starting from scratch with no templates, no anything, and then trying to figure my way out through the entire

process, which took a really long time each time. And then blind development. I didn't have a tracking system in place. I

would just sit down and think, all right, what am I going to code today? And then start coding. Having a well-defined

process now, I actually know exactly what I'm going to do well ahead of time—weeks ahead of time—before I actually do it.

And then rushing implementations. I would find myself constantly trying to rush to get something done, but there was like no

deadline. It was just like a thing where I wanted to finish my app in 15 minutes. But you have time; you definitely

have time to get things correct. And I found that when you do it right up front, or you take a little bit of extra time

up front, it just saves you a ton of maintenance time on the back end. Whenever I rushed, I got something out the door

really quick. It was super buggy on the back end; it took forever to maintain and what ended up leading me to scrap some

of these projects. Okay, so with all those mistakes I was making, why am I still sticking with this idea of building out

agents, especially putting them into a SaaS product. I think there's a unique advantage with using agents combined

with the SaaS model, and it's really the underlying architecture. Looking at the architectures I was building before

using agents, they were really complex; they had a lot of moving pieces to them. One particular component is like the

state machine of a system, and also the event management of a system was really complex to do before using agents.

Basically, you can swap the agents out for those two systems. Now you can also go vertical with your agents; if you give

the agents a specific task in a specific industry, they perform really well out of the box instead of you

having to hardcode all that knowledge upfront. And then the rapid development: so not only throwing your agents into the

architecture makes it easier to build these more sophisticated systems, you can also use the agents to build the system.

So now with tools like Cursor, uh, Bolt, LangChain, these are really taking a heavy lift away, and you can

essentially move as quickly as a team of 10 people. Now the other part of this is like outcome-based pricing; instead of

looking at per-seat or looking at trying to charge people on usage, you can just define upfront a specific structure,

return that from your agents, and charge people based on that structure. Now a lot of data processing has to happen before

you give people back those things, but I can go into a couple of examples later. And the final thing is: one person multiplied;

I mentioned this before, but one person could essentially function like a team of 10 in multiple domains. For example, if

you are someone who is running a lean operation, you only bring on contractors when you need to; you can effectively

Give one contractor in the marketing area access to agentic tools, and they are able to effectively run campaigns.

For you, write the emails, write all initial drafts of content, summarize things, do posting—that one person can do a lot more now.

So the same applies to folks like you who are building out these SaaS products. You don't need to

have an entire developer team just to build out the initial version of your project, maybe even the second version of

your project. The question then becomes, can you build reliable and adaptable architectures over time, on a repeated

basis? One of these architectures I look at—this is how I designed my APIs these days—is meant to be

flexible. It's not meant to be something that's easy to set up, at least on the front end, but it's really

easy to update. So let's say I want to add a new feature; all I need to do is

put in a new queue here, maybe add something to this agent plane, maybe add something to this agent plane. Usually, my

control plane isn't changing much, and it's interacting with all my billing providers, my identity providers, and my

model providers. All that stuff is interacting with these different planes, and I know exactly where to go to

make edits. Before, when I was working on some of my projects, I would try to do one big monolith thing and then try to

make all my changes; everything was on top of each other. It was very difficult to do. And now I also have something where

it's like a SaaS identity—this isn't a concept I made up, but it's a very well-known

concept in SaaS land—and that kind of handles all my billing, all the stuff for the user. So every time I set up

a new system I basically just plug and play this and it works. To make this concrete for you, I'm going to walk

through how an AI tool would interpret this, and my tools of choice are Cursor. I'm also using OpenAI's GPT model. Now it

just recently dropped, so we're also going to see how this performs as well. But the overall point I want to make is

this is a very general infrastructure pattern here, and what I'm doing is applying a specific use case to it, or

something that I'm going to implement for my code base. But this pattern translates across any type of SaaS that

I'm building at this point. And the specific prompt I'm using today is: explain how I would add an endpoint

POST /score with adjacent body, video URL. And then I'm adding specific components of the architecture: the infra, the

orchestrator, and the agent plane. I'm also throwing in a library just to see how well it performs. And then I describe

how I want the code written. One of the things to call out, too, is the guidelines that I'm using. This is where I, ahead of

time, wrote out what are the different responsibilities and the descriptions of the different folders, the folder structure, and also listing out where to

add things. So I took the time to do this a while back, and I just copy and paste this in the project, or I put them in the

Cursor rules as well, just to help the model along. We're going to do like a mini code review, similar to how I would

look at this in my real workflow. I'm not going to implement anything today; I'm just going to critique what the model's

written. And so the first step here is adding something to the infrastructure, which makes sense. I'm using SST on the

back end, which I really like, and they have a very specific way of adding in routes, so this looks correct to me. Next,

It's going to attack the orchestrator adapter, and this is where I would want to see it interact with the SaaS identity.

And we do get that here, so it's basically getting a valid user from the event that is sent in the request itself.

Making sure that: one, the user has paid—that means they've gone into Stripe, they've paid for the service—and then,

two, that they're authenticated. Whatever identity provider I'm using—I tend to use Clerk on the backend—so that will

ensure that the user is actually authenticated to use the rest of the system. And from here, it creates this

scoring task as well, and then it publishes the task. Now, I would like to see the topic publisher only happen in

the secondary, but that's okay; that's something I can change later on. And then it just wires up the new orchestrator; it

does get correct that it needs to hit the orchestrator API, but it doesn't really wire it up correctly. I would have

to come in and fix that. And it does call out creating a new queue message filter for the topic, which is good. Then some

instructions here on what to do next. I do like that it creates a primary adapter in the agent plane; this looks

almost spot-on to what I would write as well. And then it does go into getting the actual transcript, so it does a use

case for the transcript and it does a use case for analyzing the transcript as well. So this is good; it split it up and

made it easier to edit later on. And then finally, it does make some more updates to the queue—so this is the actual queue that we

would need here; it's not just the filtering message—and then it writes a handler for using the agent plane

scoring. So it didn't get the final piece all the way; I would like to have seen some OpenAI code in this, but overall,

It's definitely a good start here for something that's very custom to me, and I can see that if I made some updates to some

of the prompts and some of the updates to this prompt as well, and I went back and forth with it. I could probably get

it to work really well. But overall, if this was something I just spun up real quick, I definitely would just be able to

edit it and work on it for maybe 20 or 30 minutes; I'd get it working at some point, or I

could refine this as a specification and throw it to Devon, and then use Devon on the back end to iterate with it if I was

like going out to get a coffee or doing something else with my day at this point. But overall, yeah, this pattern

applies, and the more you use this, the more you'll see exactly where the model is missing and messing up, and you can

also just tweak and fine-tune this, especially if you're implementing something that's a lot more complicated

than just a single endpoint. It's going to take a lot more work to make these models understand your code bases, and

the key part that I want to come back to is the SaaS identity that I got right. This is all wired up pre-model, going

I used AI Agents to build a SaaS, Everything I learned In 23 minutes

I used AI Agents to build a SaaS, Everything I learned In 23 minutes