The Only Right Way to Use AI for SaaS Right Now

0:00Right now, pretty much every SaaS founder uses AI the exact same way. To ship more features faster. And that's exactly why every SaaS looks the same. If you can build a new feature in an afternoon, so can every one of your competitors. They have the same AI you do. [music] We're using AI for something completely different. We're rebuilding the foundation of my entire SaaS portfolio

0:24from scratch. Leaner, more efficient, more sovereign, and agent-first. Because the ways we used to build SaaS were made for teams of humans. And AI removed a lot of those human limits. So, instead of piling more features on top, we're breaking three rules almost every SaaS is built on, which allows us to ship faster, build better products, and reclaim ownership

0:48of our business. In this video, I'll show you the three rules we're breaking, why they made total sense for years, and why breaking them now will take you from surviving to thriving. When I started building SaaS products, I did exactly what everyone tells you to do. Focus on the one thing you do well, and let someone else handle everything around it. So, for years, all of our

1:10products ran on AWS. These days, most founders would put the database on Superbase and the front end on Vercel. Same idea. You rent the essentials and let the experts deal with the rest. That's the first rule we're breaking. Renting your infrastructure. And for a long time, it made perfect sense. Running your own servers, databases, and deployments used to need a DevOps engineer, or in some cases, a whole DevOps team. A small dev team alone just

1:40couldn't do it. But, when you rent a platform, you get the whole platform. It's built for thousands of different companies with hundreds of features you'll never touch, and hundreds of compromises you'll have to live with. You typically only need a small slice of it. And you still depend on all of it. So, [music] when they change the pricing, add a new limit, or go down,

2:04that's your problem, too. And unfortunately, this has produced a whole generation of helpless founders who can launch in a weekend, but couldn't restore a backup on their own. Today, AI can build exactly that slice for you from scratch on open-source tools that are completely free, like Postgres and Kubernetes. You tell it what your product needs, and it writes the whole setup faster than

2:28you can click around in Vercel or AWS. And our agents watch the infrastructure, too. When something spikes, AI can fix it faster than the most experienced [music] AWS support staff. That's how our whole portfolio runs now. We rent bare metal servers at Hetzner, and everything on top of them is carefully tailored to our products, the apps, the databases, the background jobs, and the

2:52monitoring. No more, no less. It's saving us tens of thousands of dollars a year. But what I love most is that we own all of it, and there's nothing in there our products don't need. The arguments against self-hosting died with AI. Today, AI agents write pretty much all of our code. Our dev team is me and one developer who's been with us for a long time, and neither of us really writes code

3:17anymore. We plan, we make the decisions, and we review the work. But the code base those agents had to work in was built for a completely different team. Feed Hive is our social media automation tool, and most of it was built by individual developers and freelancers we hired on Upwork. We were four developers, myself included, but the other three were rarely the same three. There was a lot of turnover, and over the years, we went

3:44through a lot of different developers. So, I ran everything on least privilege. A new developer only We access to the one service they were working on. And apart from me, nobody ever saw the entire code base. Over time, Feedhive ended up spread across 19 separate repos. That's the second rule we're breaking. Splitting up your code. With people coming and going like that,

4:08it was the right call. If someone walked away with our code, they'd only walk away with a small piece of it. But for an AI agent, that setup just gets in the way. Almost every change touches more than one part of the product. So, the agent has to go and look things up across repos and piece everything together. It makes a change in one repo, opens a merge request, and waits for it to get merged and deployed. Only then can it install the new version in the next repo

4:35and continue. And then it does the same thing all over again. [music] It's tedious, it's time-consuming, and it puts blockers all over the agent's work. So, we started rebuilding the foundation for Feedhive. This is going to be Feedhive V3, and this time, we put everything into one mono repo. Something I used to hate, by the way,

4:57but today it makes perfect sense. 19 repos down to one. Now an agent can see the entire product at once. It makes the change everywhere it needs to go, runs one set of checks for the whole product, and ships it. No more waiting on other repos. Our agents still don't get the keys to

5:17everything. They can read the whole code base, but [music] they can't push to production or touch the production database on their own. We limit what they can do instead of what they can see. If your code base is still organized around freelancers you couldn't trust, your agents are paying the price for a problem you don't have [music] anymore. Last year, attackers hijacked some of

5:40the most popular packages on NPM. Packages that get downloaded hundreds of millions of times a week. and they pushed malware straight into them. If you installed them at the wrong moment, you installed the malware, too. And most SaaS products depend on thousands of packages just like [music] that. Because of a rule every developer learns

6:01on day one, "Don't reinvent the wheel. If someone already built it, install it." That's the third rule we're breaking. And for a long time, that was the smart thing to do. Writing something yourself costs developer hours. Installing a package costs you one line. So, that's how we built the old FeedHive. The app ran on Next.js with

6:23hundreds of packages on top. And a lot of them were tiny. We had a package to detect when you click outside of a box, one to make a text field grow as you type. We had a package for confetti. But every package is code someone else wrote, and you have to trust [music] it, patch it, and keep it updated. Each one pulls in more packages, and every major update can break something you didn't

6:45even know you depended on. For a product that's connected to our customers' social media accounts, that's a scary thought. Most of these packages only exist because writing 20 lines of code used to be expensive. That's just not true anymore. Our agents write a click-outside detector in a couple of minutes, test it, and it does exactly what we need. Yes, it's more of our own code, but it's small, it's ours, and the agents can read and fix every line of it. So,

7:15FeedHive V3 is React, Vite, and shadcn. And that's basically it. Almost everything else we wrote ourselves. Well, our agents did. And we made sure it stays that way. We now keep a reviewed list of allowed packages. If anyone tries to add one that isn't on it, me, our developer, or an agent, the checks fail until there's

7:37a good reason for it. Across all the services the old FeedHive ran on, we had over 12,000 installed packages to keep patched and trust. V3 has 706. Even the packages we picked ourselves went from more than 300 across the old code base down to 82. Most of them are linters and CICD stuff that aren't even

8:00shipped. That's a much smaller attack surface, way fewer upgrades, and a code base our agents can read from top to bottom. Everyone else is going to keep using AI to pile more features on top of the same old foundations. Let them. When your agents can build exactly the infrastructure you need, see your entire product at once, and read every line of your code, they move faster than any team bolting features

8:27onto a stack nobody fully understands. That's what lets you build the stuff your competitors can't copy in an afternoon. This is our new product portfolio. Our own servers and mono repos with a few dependencies. With half the developers we used to have, we're building faster than we ever have. So, here's what I want you to do. Open your project and ask your agent three

8:49questions. What do we rent that you could build a smaller slice of yourself? What slows you down every time you work across our repos? And which of our packages could you replace with a few lines of our own code? Then pick one answer and let your agent tear it out.