How to build an AI SaaS: the service-to-software ladder

Building a B2B AI SaaS is one of the hottest things you can do in tech right now, and most developers who try it get the order completely in reverse. They go into their cave, work for six months on something they think is a great product, and then find out nobody wants it. The path I recommend, the one I've used for years to build and launch multiple software companies, flips that. You get paid first, and you get actual proof before you call it a product.

Quick disclaimer before we get into it. I'm not a software millionaire. No nine-figure exit, no unicorn. But I've built my fair share of software over the years, some products making a couple hundred per month, some a couple of thousand, and the pattern behind all of them is exactly the same.

The code was never the hard part

The hardest part of the software game was never the code. Now more than ever, with AI coding agents, the code is the easy part. The whole game of software has always been about finding a customer, especially your first one, then getting them to pay, and most important of all, getting them to stay.

This is where engineers and technical founders go wrong. They start with the code, build for six months, and then discover they can't find a single customer. Nobody is willing to pay, and even when someone pays, they don't stay.

The beauty of software is that if you get this loop right, customers paying and staying, you have product-market fit. That loop is the most important thing to work toward in the beginning, because once customers pay and stay, you have a beautiful business model. That's why software companies are so attractive in the first place.

The service-to-software ladder

If you don't start with the code, where do you start? You flip the script and start with the customer, which puts you on what I call the service-to-software ladder. Its three steps are done for them, done with them, done by them. Most people jump straight to step three, and that's where all the problems come from.

The ladder starts in a very unsexy, unscalable way. You begin as a freelancer, an agency, or simply a developer who builds something for one particular company, and they pay you to do the build. No fancy signups, no multi-tenant support. One customer, one problem, one paid build that proves the concept.

That's the entire model.

Step 1: done for them

In the first phase you do all the work, and the goal is to find one company with a problem worth solving. The word to optimize for here is breakage. Breakage is any kind of problem leakage in a business. They're either leaving money on the table by not solving it, or the problem is actively costing them money every week and every month.

The obvious breakage is already fixed. People need to send email, manage work, plan tasks, so you're not going to build the next Gmail or the next Slack. Good luck competing with those giants. The breakage you want is more niche and more subtle, the unsexy stuff happening in the background between certain departments, certain employees, and certain systems. You only find it with insider knowledge, and the only way to get insider knowledge is to go talk to people.

I know that for most engineers this is the scary part. It's why we hide in our caves for six months and build stuff. Trust me, that's a recipe for disaster.

Skip the cold emails, the mass pitching, and Upwork for now. Start with your warm network instead. That's anyone who already knows you to some degree, so that when you message them, the reaction isn't "who is this person?" With cold outreach you grind through a lot of nos to get one yes. With a warm network, getting an introduction and having a chat is far easier. And with what AI can solve today, there is breakage in pretty much every company, across admin, support, sales, marketing, and operations.

When you get those conversations, don't position yourself as the AI expert who already knows what they need. Position yourself as curious. That's probably the best tip I can give you. Run what sales people call discovery. Ask questions and dig until you reach the core problems people experience inside the company. Listen for something described as painful. Ideally also repetitive, costly, and unfixed. That's my working definition of breakage, and if you find a process that checks all four boxes, you have a serious opportunity to make a lot of money.

Propose a price, not a pitch

Once you've found breakage, propose a solution. Keep it simple, lean, and minimal so you can build it quickly. Position it as a proof of concept. With AI coding tools this keeps getting easier. In one to three days you can have something that works and shows tangible value.

The important part is attaching a dollar amount. Everyone wants their problems solved when you offer to do it for free. Ask "can I build this for you?" and you'll hear "sure, why not, we'll see what comes out of it." As soon as money is on the table, the dynamic switches. Now it's an equation. Is what we put in worth more or less than what we get out?

This is the proposal structure I use. If I built you X (the lean solution), given it solves Y (a guarantee, like saving a percentage of time or adding a certain amount of monthly revenue, depending on the unit economics of the problem), would you be willing to pay Z for the initial build plus W per month to maintain it?

Their willingness to pay is the true test. If this company won't pay for it, other customers probably won't either, which means the value isn't right and you don't have product-market fit yet.

Step one is unsexy, unscalable, white-glove service, fully custom to one client. Don't skip it, and don't treat it as below you. Stripe and Airbnb started exactly this way. And the beauty of phase one is that you get paid to do it. No cheap-founder mode, no months of unpaid work. You get paid to prove your idea.

The turn-it-off test

Before moving to step two, run one more test. If you have a product a business relies on and you turn it off, the phone should ring within the hour. The sooner that call comes, the better your product.

A concrete example from our own work is a customer support automation system. Tickets came into an email inbox, the AI processed them and replied to customers, with an escalation gate to a human agent when things went wrong. The support team only handled the roughly 25% of tickets the AI escalated. When the system went down (and early on it did, a model would become unavailable, something would break during onboarding), the team was suddenly back to 100% of the tickets. Do the math and that's a 4x jump in work for the same team. That's how you should think about the unit economics and ROI of software.

I'd make this conditional. Keep repeating step one until you find something that passes the turn-it-off test. Once you have it, you're in a really good spot.

Step 2: done with them

Step two moves from fully done for them to done with them. You still do some of the work, but you start including the client. The goal of this phase is three to five near-identical customers.

You now have a product skeleton. It's still a bit sloppy, no fancy onboarding, no multi-tenant support, but you take it into another company with the same breakage and rebuild it inside their business. You don't even have to onboard them onto the build you already created. Early on, another custom build is fine, because this phase is where you figure out which 80% of the solution is the same for everyone and which 20% is custom-tailored.

The best way to find that next customer is to literally ask client number one for other companies in their industry. People network, and people know their branch. Go as niche as possible here. Anyone can build a generic task manager or a generic marketing app. When we built the support automation, we focused on e-commerce stores using Gorgias as their ticketing system. That combination was already very specific.

As you land these customers, shift the work toward them. Give them simple dashboards they can see, onboarding steps, forms, settings they fill in themselves.

Shift the pricing model too. Phase one was an initial build cost plus a maintenance fee. For the ticketing system, the original client paid a 10k sprint and then a follow-up of about 15 grand, so roughly a 25k build, straight-up cash for us. Follow-up clients paid purely per ticket processed, because the more tickets flowed through our system, the more value they got. One software hack always holds. Whenever possible, tie the pricing to the value, so the price goes up as customers get more out of the software.

The ideal outcome of step two is three to five near-identical customers who are happy, paying, and giving you testimonials. Get there and you're in a better position than 99% of the people who try to start a software company.

Almost nobody warns you about one thing as you start selling to bigger companies. Once you have product-market fit, they stop asking "will this work?" and start asking "is it secure, and can you prove it?" That's when frameworks like SOC 2 and ISO 27001 come into play, and whether you have them can make or break a deal. Know that compliance starts to matter more as you scale.

Data Freelancer

Technical skill was never the bottleneck

Most developers can already deliver work clients pay $150/hr for. What they're missing is an offer, a pipeline, and the first client. That part is learnable.

Learn the System

Step 3: done by them

The final stage turns the work into an actual software product with self-onboarding and self-checkout. The goal is that a customer can get results without you in the picture. While you're on a beach somewhere, someone should be able to visit your website, create an account, and get results as quickly as possible.

Only at this stage do you spend serious time on the engineering around the product. That means onboarding, multi-tenant support, the funnel, the website. People need to understand the product, log in with email, and yes, they want the sign-up-with-Google button too. The complexity grows fast here, and most people underestimate it. Coding agents let you build an MVP quickly, but everything around it is where people get stuck, from onboarding emails and password reset flows to account creation, magic links, two-factor authentication, and signup follow-up emails. This is what it really takes to run and scale a software company.

What you optimize for at this stage is speed to result. You're already making money and you have customers, so the question changes. What happens in the first 5 minutes after someone onboards? Can they figure it out themselves and get a quick win? I'd say 90% of products lose right there. People don't stick past the trial or the first month, they churn, and you lose them forever. The faster you get them a win, the better.

The other big focus is distribution, how you get the product in front of more people. This isn't a marketing video, but here's one tip. The most successful products don't rely only on paid ads, which are the easy option but usually too costly to run profitably in the beginning. The best products have built-in distribution mechanisms like referrals, sharing, and bonuses. Early Facebook grew because a social platform is only as good as the people on it, so they incentivized inviting others and got a network effect. Skool, the community and course platform, pays a 40% lifetime commission on every referral, so on the roughly $99-per-month plan there's real money in promoting it. A built-in distribution mechanism is always the best one; expand to other forms of marketing from there.

You can jump off at any level

You can stay at any level of the ladder, and not everyone will make it to level three. Let me rephrase that. Almost no one makes it to level three, by definition, because building a sustainably growing software business is really hard.

Here's the part I like. Even at level one and level two, you have a great business and you can make great money. You may not get the multi-million dollar exit, but let's be real, the chances of that were very low anyway. By following this process you greatly reduce the risk, you don't need external funding, you keep 100% of your shares, and you get paid to prove your idea instead of disappearing for months, earning nothing, and then learning it wasn't worth it. That's why I love this model and keep using it with my own software development company. It's the exact process we run over and over to spot opportunities and turn them into products.

Next step

Most people reading this will click away and think "maybe someday." For the small percentage who want to take it seriously, the way into step one is to position yourself as a freelancer and land that first paid build. That's the skill that starts the whole ladder, and it's the focus of the freelance tech roadmap, which covers finding your first project, running discovery calls, and pricing your work. If your background is in AI engineering specifically, the freelance AI engineer guide maps the same path to AI offers and buyers.

The full walkthrough of the ladder, including the whiteboard version, is in the original video.

FAQ

Do I need funding to build an AI SaaS?

No. The point of the service-to-software ladder is that your first customer funds the build. You charge for the initial proof of concept plus a monthly maintenance fee, so you're profitable from the first project and you keep 100% of your shares.

How do I find the first customer for an AI SaaS?

Start with your warm network, not cold outreach or Upwork. Ask for conversations, position yourself as curious, and run discovery until you find breakage, a problem that's painful, repetitive, costly, and unfixed. Then propose a lean build with a price attached.

How much should I charge for the first build?

Base it on the unit economics of the problem you're solving. Our first customer support automation was roughly a 25k build (a 10k sprint plus a 15k follow-up) with maintenance afterward, justified by the workload it removed from the support team.

When should I turn the service into a product?

After two gates. First, your build passes the turn-it-off test. Switch it off and the client calls within the hour. Second, you've delivered it to three to five near-identical customers who are happy, paying, and giving testimonials. Before that, you don't know which 80% of the solution generalizes.

Is staying at the service stage a failure?

No. Levels one and two are great businesses with great money in them. Level three adds self-serve onboarding, multi-tenant support, and distribution work that most people underestimate, and almost no one gets there. Jump off the ladder wherever the business works for you.