How to transition to a SaaS model after building automations, including needed components like auth, storage, DB, billing, and scaling to 1k–10k users.
I think it's a good question, but I'm not a software engineer—I'm okay at it but not the most qualified. Still, I'll answer. First, I'd build a serverless backend using Make.com and Nadn (or similar), meaning you don't manage server infrastructure—you just send/receive events to webhook URLs. Once you have that automation, I'd build a front end with Bolt or Lovable (you get a free year of Bolt in Maker School). You'd vibe‑code the front end and connect it to the backend via webhooks. For authentication/storage/database, I'd use Superbase, which works out of the box with vibe‑coded tools like Bolt and Level. Then I'd add payments via Stripe, again trying to vibe‑code it with Lovable/Bolt, though I'd likely need help. Regarding scale, the hard truth is you shouldn't rely solely on vibe‑coded solutions past about 50 customers; they tend to have foundational security issues unless an actual engineer reviews them. I cited the Cluey hack as an example. So, get it off the ground quickly, but then invest in an engineer to secure customer data and prevent leaks—you have that responsibility when running a SaaS.
I think packaging automation as a SaaS product is cool. I've done this before for many viewers. You can view it as a way to improve consolidation, but essentially you can treat SaaS as either green or blue—just a label. SaaS product growth over time is tricky at first, then you hit product-market fit and scale rapidly. For most of the lifetime, especially the first couple years, you make basically no money, unlike an agency or service implementation where you can earn a fair amount right away. Agency revenue tends to be up and down and hard to scale; after 2-3 years, an agency might still be where it started, while a SaaS product could have completely overshot it. So there are pros and cons depending on the time scale you plan for. Market dynamics also help—SaaS is becoming easier to build with no-code tools. Additionally, you can package an automation as a SaaS but still sell it as a service implementation. For example, take your automation workflow and have Lovable or Bolt create a simple front end for it. If you want more nuance, check out a video where I actually built one. I don't recall which specific video it is, but there's an example: me wearing a backward baseball cap, turning a 2K automation into a 10K SaaS no-code product using Lovable to package the automation I built as a SaaS product resembling a little proposal generator. You can try that approach, but still sell it as a service. Hopefully that answers your question.
I think vibe coding could genuinely be the next big business model — you can build apps, software, or websites that solve niche problems with enough time invested. Between automation services and building software: I'd favor automation services, because building software means putting a lot of upfront capital and time into something in an era where the value of that knowledge is dropping fast — tools like Bolt, Lovable, and Cursor are increasingly capable of replacing exactly the kind of thing you'd have spent all that time building. On the tools themselves: I've used Bolt and like it (they even invited me to a boat party once, so take that with a grain of salt); I've used Lovable too, a cool product I covered in a video; and I've used Cursor for myself but haven't built anything major with it — it feels a bit different in nature from Bolt/Lovable, and it's hard to firmly recommend just one.
My vibe‑coding workflow starts with a voice transcription tool where I state three things: my objective (what the app should do), the context (my business, existing tools, clients), and the constraints (what I can or can't use, like needing N8N or avoiding certain platforms). Then I define what 'done' looks—for example, being able to send a request and get a nicely packaged JSON response within 500 ms. After that I just keep working, using the voice tool to feed the AI my goal, and verify my own work until the definition of done is met. Consistency matters: feeding the same structured prompt (objective, context, constraints, definition of done) yields reliable outputs, so I stick to that pattern rather than constantly changing how I prompt.
Sure. When a new client signs a contract and the invoice is paid, the first step is a kickoff call. In that call you thank them, clarify the problem you’ll solve, reiterate the value you’re delivering, and cover timelines, communication channels, account sign‑ups, and any two‑factor‑authentication requirements. You walk them through signing up for every platform you’ll use, making sure all 2FA is set up, and you aim to have every account, email, and password ready by the end of the call—ideally stored in a password manager like 1Password, LastPass or Dashlane. Then you invite the client to your communication hub (Slack, email, WhatsApp, etc.) and establish a cadence for updates, such as a brief status every couple of days. From there you proceed with the automation build. The client pays for everything: the automation platform (Make.com), any niche tools you use (Naden, PandaDo, Instantly, Mailfinder, ClickUp, Slack, Apollo/Amplify, etc.). Because you have affiliate partnerships with most of these services, you include your referral links, which typically give you a 3‑5 % margin, providing a small side‑income that continues even after the project is handed off.