These 60 Minutes Will Change the Way You Build SaaS

Timestamps

• 00:00:00 - Introduction
• 00:02:49 - What Am I Building?
• 00:06:31 - My Target Market
• 00:07:27 - Email Marketing
• 00:10:59 - Why I Decided to Build My Own SaaS
• 00:18:07 - Types of App Developers
• 00:20:30 - Finding a Problem
• 00:22:34 - My Problems
• 00:29:30 - Feature Differentiation
• 00:33:18 - Scope Creep
• 00:36:33 - Technical Challenges
• 00:41:33 - Decisions
• 00:44:19 - Customer Acquisition
• 00:46:43 - Course Catalyst for Devs and SaaS
• 00:49:23 - Agents and AI

I've posted very little on YouTube over the last 7 months, and that's because I've been building my own software.

Here's where I'm at with it so people know what stage this is coming from: the software is built and I have one paying customer (two if you count me, since I run my own stuff on it). That's it. So this isn't me teaching you everything I know about SaaS, it's more building in public, the stuff I ran in to and the stuff I'll probably run in to as it grows.

It's worth knowing the difference between users and customers too, because they are not the same thing. My app is in early access and already has thousands of users, but one paying customer. When you see people on Reddit talking about hundreds of users, or even lots of paying users, that could be free accounts or a $7 one time purchase, which doesn't really add up to much. My one customer was a purchase in the thousands of dollars.

What Am I Building?

I'm Caleb, I've been making YouTube content and doing software engineering for my entire adult life (I think my first videos were on database design when I was 15 or 16). I did co-found some software a couple years back, but a project at this scale entirely on my own is a big step up.

I definitely underestimated it. I figured a month, maybe two to get it polished. I'm 7 months in and I've worked way more hours than I planned on.

If you're 3, 4, 5 months in to building something and you haven't put it in front of anyone, there's a really good chance it never gets out there unless you decide to finish an MVP and ship it. It's never going to feel ready. Around month 3 or 4 I decided I was getting a customer whether the product was done or not, because I could see it going south otherwise. So scope it small, something you can build in about a month, and add features from there.

The product is Course Catalyst. In chemistry a catalyst speeds up a reaction, so the idea is getting a course out there fast to start collecting leads and making sales, pushing people to mid-ticket offers or to book a call for higher ticket ones, and doing all the email and lead nurturing in the same platform.

It's not only for courses anymore, and that was the biggest scope change along the way. It works for coaching programs, for SaaS, for creators who just want to grow a list. I might rebrand at some point, but for people selling courses the name makes it pretty clear what it's for, so I'm leaving it for now.

My Target Market

A big one is anyone running an online coaching or mentoring business. How people learn online keeps changing, and a lot of programs are hybrid now, modules plus some group or one-on-one components. They need to host modules and downloads, run nurture emails, and onboard people who join. Coaches are usually good at coaching, and might be good at sales, but they're often pretty terrible at content and marketing, so this is a place for the program and everything before it (free course lead magnets, email marketing, and so forth).

The other one is SaaS. When someone signs up for your app, that contact should be on a list you're nurturing, pushing them back in to the product or upselling them to a higher tier or another product. A lot of developers skip this part completely. They get free users and then do nothing with them.

Email Marketing

Course Catalyst does email natively, not as an add-on or an integration to some other email platform. I put a lot of work in to deliverability, which just means reducing how often email ends up in spam, through how the emails are structured, a bunch of checks, and the way authentication is set up.

On the list side, providing value to subscribers regularly doesn't have to take a lot of your time, and you can pretty regularly get a 35 to 45% open rate or higher depending on how aggressively you clean your list. That's 4,000 or more people opening your newsletter out of 10,000.

I think of email as the most owned platform. On YouTube or Instagram or LinkedIn you're kinda renting the space, and an algorithm change can take your engagement away. It can happen with email, but it's much rarer, and usually comes down to your domain getting reported for low quality emails. And people open their email to read updates, get coupons, and make purchases, not to be entertained by 10 second videos, which makes it a really good place to sell.

Why I Decided to Build My Own SaaS

Software as a service just means software people subscribe to, so you build monthly recurring revenue.

I've enjoyed building software my whole life, and being able to create something other people can't has always felt a bit like a superpower. I've also always had the entrepreneurial thing going, and I've never loved the 9-5.

My last job was senior software engineer, writing Rust. I quit, turned down another really good offer at a different company, and went all in on YouTube, courses, and a software engineering mentorship program. The mentorship helped a lot of people land senior roles, get promoted, or get hired after years of not being able to get interviews, and I'm really happy with that.

But after 6 months, a year, all I was really doing was mentoring. I wasn't building my own stuff beyond what I made for tutorials, and it felt like I wasn't doing what I was preaching. A lot of the people I worked with wanted software engineering jobs, and in my soul I didn't even want one myself. Over 50% of the mentoring ended up being mindset work too, bad thought patterns, study habits, consistency, which was way beyond what I originally planned for the program. I liked it, but it wasn't what I wanted out of my life.

This app had been an idea for years. I'd scoped it out and talked to people about it and never jumped. The biggest reason was that software takes a lot of time and it's hard to make income from it. Marketing, sales, and product market fit are the hard parts, and you can build the best software in the world and if it's not something people have enough pain about to pay you, it doesn't matter. Probably some fear too, because it's a lot easier to think you have a good idea than to build it and find out. People running their own businesses kept asking me why I didn't just build my own stuff, and eventually I sat down one day and said we're starting today.

Types of App Developers

People usually land in one of two buckets.

The idea people: "I have an app idea that will make millions, can you build all of it and I keep 90%?" And the coders who can build anything but can't come up with an idea or execute unless someone hands them the task. They'd be perfect for a regular software engineering job.

I talk to developers all the time who say they can code but don't know what to build, and to people with an amazing idea who are never going to actually build it. If you're mostly in one bucket, find someone from the other one to pair with (co-founder, founding engineer, whatever you want to call it). If you're going solo you need a bit of both. I'm okay at ideas and decent at coding, not a genius at either, and so far I haven't hit a roadblock I couldn't get through on my own, so I'm staying solo for now.

Finding a Problem

Most software solves a specific problem for a specific type of person, and this is the hard part, because you don't know ahead of time if people will pay for your solution.

My thinking was, if a company thinks it's worth paying me this much to write code, there's got to be more money in building the software myself.

There are two good ways to find the problem:

• ask people or do research
• your own pain

I went with my own pain and did very little user research. I think that's fine in my case because I have years of experience with this exact pain, and if I solve my own problem I can probably solve it for people in a similar spot.

My Problems

I've run courses on Kajabi, tried Teachable and Podia, used marketplaces like Udemy and Skillshare, and had courses on more exclusive platforms like Course Careers and O'Reilly. Here's what one free course sale looked like on my own site:

Someone enrolls in a free course. It's free, but it's a lead magnet, you get the product in exchange for your info. That enrollment triggers Zapier (automation software that connects different tools), which enrolls them in a Kit sequence. Then for the evergreen funnel with deadlines, a separate deadline service holds a personal deadline for that one person, so the offer expires a certain number of days after they signed up.

And that whole structure was duplicated for every lead magnet. A back-end engineering roadmap, a free preview of my fundamentals course, a free React course, probably 10 or 15 of them. Too many, but that's not the point. Each one needed its own setup on the Kit side and its own automations, and it was very easy for things to fall through the cracks. If any piece paused or disconnected, the whole thing stopped working the way you'd expect.

Then there's the cost, roughly:

• course platform, maybe $300 a month
• Zapier, maybe $60
• email, maybe $250
• deadlines, maybe $99

Sometimes I was paying twice on purpose, because the course platform had email but it was atrocious, so I moved it to a better tool.

The bigger problem was the gap. The deadline was tied to the email, not to their course account, so the course platform had no idea the deadline existed. And the sequences counted days forward from signup, 1 day after, 2 days after. It works, it's what I did, but it's backwards when you're working toward a deadline. I think in 5 days before, 4 days before, 3 days before.

So the idea was to collapse all of that in to one thing. In Course Catalyst you have the product, the contact, the offers given to that contact (that's the deadline), and deadline-based sequences written from the deadline backwards: an hour before, 4 hours before, a day before, 2 days before, back to when they enrolled. The enrollment triggers are cleaner too, any free enrollment, any brand new contact, or enrollment in one specific product. Replacing that stack saves me almost a thousand dollars a month in random software.

Feature Differentiation

Features on their own are weak differentiation, especially now that AI can help anyone build features. You usually need something more:

• how fast you develop
• the community around the app
• service and support
• data other companies don't have
• economies of scale, buying in bulk to get prices a smaller competitor can't match

As the small guy, you can't win on scale, but you can give every individual customer white glove service, which a big company probably won't care to do.

Built-in deadlines are a feature very few course platforms and marketing systems have, and I'm not confident that'll always be the case. But because the deadline lives in the same system as everything else, I can put it anywhere: on the student's library page showing which offers are available to them, or in the course player saying you can upgrade to the next tier at a discount and here's how much time you have left. You can't really reproduce that with an external deadline tool plugged in to another platform, because that tool can't give anything back to the platform. So even if you can plug features together with an integration, you don't always get a one-to-one match with something built in natively.

Scope Creep

Try to get your app out within about 3 months, and try not to go past 6. I don't know the actual stats off the top of my head, but the further past 3 months you go, the more likely it never gets finished or never reaches a customer.

The biggest thing that stops you is scope creep. You start with something cute, built-in deadlines, then add features that build on it, and eventually you have a monster that never gets out the door. I knew about this problem and even made a video about avoiding it, and I still did it. Sometimes building something exposes other features you could build, and sometimes building for a real use case shows you features you actually need.

My first customer wanted a community feature. I'd experimented with one and archived it on purpose to keep the MVP focused. But I also didn't want them leaving for a competitor.

What I'd recommend is to figure out what you do, and for anything you don't do, have a reasonable alternative ready. Right now I have some CRM capabilities, every product a contact bought, every lead magnet, every email they got, all in one spot. Emailing an individual directly or texting would be nice, but that's a lot to build, so in the meantime I point people to a specific CRM as the recommended integration.

Technical Challenges

The other reason apps take way longer than 3 months is you don't know what needs implemented until you build it. "Set up a landing page and process some payments, no biggie" hides a lot.

I don't process payments natively, I don't think that would be wise as a one person show. It goes through Stripe (and a lot of the big players with their own payment systems are really just white-labeled Stripe). Someone hits buy, pays, and gets redirected to a success page. But what if they leave before that page loads? Or the payment succeeds on Stripe's side but your server fails to store it? That's what webhooks are for, Stripe also sends a request to your server, and you need handling where the redirect and the webhook can both run without causing a problem.

Email providers do the same thing for opens, clicks, and delivery data. Then you have to know the sender's behavior. Do they retry? What if your service goes down for a while, or you handled webhooks wrong for a stretch, and your database drifts out of sync with the provider? You need a way to get the data back in sync, even if ideally your webhook handling is resilient enough that it doesn't happen.

A few more that came up for me:

• storing videos, do you track the state server-side (uploading, processing, done, failed)?
• analytics, do you build them in your app or use what the streaming service gives you for views and retention?
• time zones. It's multi-tenant, so multiple businesses run on it. Do deadlines anchor to the main service, UTC, the tenant, or each user so everyone sees their own time zone? That one took me a lot longer to think through than it should have.

Decisions

The hardest part of building an app now is making decisions and designing a system that isn't garbage, way more than the coding. Google login, email and password, passwordless, which auth tool, and on and on. Every one of those decides whether the product is good and what the user experiences, and it's by far the slowest part.

For a lot of things you can just not care as much and pick one. For the important ones, instead of asking "what do I choose?", ask how hard it would be to undo. Most things can be undone, and if the cost is low, decide and keep moving. The sooner you make decisions, the sooner the bad ones show up, and that's when you have the fewest users and the least data to worry about.

Once you have real user data, changes get harder. A migration that changes the data structure might need a script to update real data, or you move the data to a new column, run off the new column, and sunset the old one once everything works.

This is a big reason I like having a few high-paying customers. If a breaking change hits, I can work with them directly and fix it by hand, instead of writing custom scripts and checking everybody's data across tons of accounts.

Customer Acquisition

Since I have one customer, I'm obviously an expert here 🙂 It's a similar structure to what I've done with this content and my courses and coaching though.

It starts with a lead magnet, and I think a free course is the best lead magnet there is. It's great for nurturing, engaging, high value, easy to consume, relatively easy to make, infinitely scalable, and people usually want a lot of watch time with you before they buy.

My funnel:

free course lead magnet → book a call → sales call → customer

I feed the top with social media, reels on Instagram with the free course in my bio, and later probably ads, plus inbound messages or follows to find business owners. My first customer actually found me organically because I was talking about mid-ticket funnels.

For a mid-ticket product, you'd swap the call for a purchase with a personalized deadline based on when they signed up, and the sales call becomes buying the product.

Course Catalyst for Devs and SaaS

Most people who watch my stuff are developers, which isn't exactly the Course Catalyst customer, so I'm working on developer features: being the marketing platform for your software, and documentation. A lot of bigger software has a doc site or a learn site or an academy. The course player isn't just videos, it supports markdown, programming languages, embedded media, search, and it's easy to update through an LLM over MCP, so you could host your docs or examples there.

I think the biggest challenge with developers is they're cheap, and they might not see the value in landing pages and product offers. Business owners, creators, and coaches are easier to justify because there's a clear path to more calls booked or more sales.

I'm still trying not to market to everybody, though. Instead of splitting developer vs coach vs creator, I'm focusing on people who need digital products and want to do email marketing, so it's more about what they need than who they are. We'll see if that works.

If you want to check it out, it's at coursecatalyst.com. It's early access, so the landing pages might not be fully polished, but if you work with me directly I build everything out with you.

Agents and AI

This is basically the origin story of the app. I was making an AI course and was going to build a small iPhone app that would take a week or two, and then decided to finally build the app I'd been putting off. I documented a lot of that in the course: research on what stack to use, product differentiation, pricing strategy, and how to do customer support and service, since I wanted to pair it with a white glove service where I build out your products, landing pages, funnels, and deadlines for you.

At first it was about 50/50 AI and me coding by hand, and I read most of what the AI wrote. Anything sensitive or back-end heavy I stayed involved in, so I built the payment processing myself, while the UI I didn't care how it was implemented as long as it looked okay.

That went from "this is cool, a pretty good prototype" to really annoyed. It kept reintroducing bugs I'd already fixed and couldn't get past a medium level of complexity. I literally went back to coding pages by hand and almost restarted the app from scratch. Then I spent a lot more time learning agentic AI properly, which I should've done from the start, and things turned around:

• building my own workflows, agents, and skills, and using hooks
• converting as much as I could to static checks, TypeScript, Prettier, ESLint
• orchestrating multiple agents for speccing features, research, implementing, verifying, UI design, and testing
• using the right models for different jobs instead of the defaults

Now on a bigger feature it might code for 3 hours and I review it against the spec.

Start clean and enforce the rules from the beginning. My code base was sloppy from the early phase, with a ton of TypeScript issues that didn't break anything (implicit and explicit anys, unknowns I didn't want), so I spent a week going from garbage to high quality. I added a bunch of static checks, including custom ones to protect cross-tenant access, require every endpoint to define its authentication expectations and validation, and block certain unsafe database access patterns. Now it's very hard for the AI to write sloppy code in the repo, and everything is anchored in a vault describing the features and domains of the app. I go through the whole approach in These 90 Minutes Will Change the Way You Use AI.

I also went mobile first. Every feature gets checked in the mobile preview in the browser dev tools before I build it out for desktop, and that alone sets you apart from a lot of complex apps that lag behind on mobile.

For the MCP server and the API, I did what I'd call outcome-focused implementation. I'd ask the AI to do something that wasn't possible yet, like "import my Kajabi contacts", and have it build the MCP and API endpoints needed to make it work, then deploy and iterate. So any workflow I can picture a customer using, I know the endpoints exist. Another one is drafting coupon emails to certain segments from Claude Code and having it send me a preview. The whole platform is designed to be AI native, so you can do everything through an LLM, and I already migrated all of my own stuff over to it using those same MCP workflows.

Next for me is polishing and adding features, running ads for the platform itself (the pixel is already built in so customers can run their own), putting a lot more time in to YouTube, and getting new customers. I'm also playing with some micro SaaS ideas that could use the platform but be separate products, smaller projects that don't take 6+ months. More on that in the future.