What I Learned Launching an AI SaaS (in 30 days)

Last week, I launched my 2nd AI SaaS (called Ghst). Although I avoided many of the mistakes made from my first product, I learned many new lessons this time around. In this article, I’ll share my key takeaways and what I plan to do differently next time.

Here's the video: https://www.youtube.com/watch?v=i6yd-mezhro

$600k/mo solopreneur Pieter Levels said that out of 70 ventures he pursued, only 4 of them made money and grew (~5%). His takeaway from this experience was simple: ship more [1]. The more shots you have on goal, the more goals you make (even if you suck). But also, the more you do the thing, the better you get at it (so more of your shots actually go in). This is why I set out to build 20 AI SaaS products. Here I’ll share my reflections 10% of the way to my goal.

SaaS 1: What Worked 10 months ago, I launched my first AI SaaS, y2b. It turned YouTube videos into blog posts. While I made many mistakes building this app (which I’ll share in a moment), here are a few things I think I did right.

• Built with that I knew: Instead of trying to learn an entirely new tech stack (e.g. JS, React), I built the entire app with what I knew: Python [2].
• Solved my own problem: Big mistakes I’ve seen other founders make are 1) building something that doesn’t solve a problem or 2) solving a problem they have little context about. Solving my own problems avoids both of those.
• Used an Easy-deploy Service: While deploying software can get complicated, using Railway made this process almost trivial.

I Built an AI App in 4 Days — here’s how I did it. (as a data scientist with no web dev experience) medium.com

SaaS 1 → SaaS 2 Coming from a data science background, my coding experience was primarily running experiments and doing analysis, not building applications. Consequently, I made many basic (yet painful) mistakes when building SaaS 1. Here are the three main ones.

Mistake 1: Two Codebases The biggest mistake I made was having two separate codebases for development and production. This introduced unnecessary complexity in the deployment process. When building SaaS 2, I resolved this by using a .env.local file to automatically put the app in “dev mode” when present. The code to do that looked like this. from dotenv import load_dotenv load_dotenv(".env.local", override=True)

Mistake 2: Poor Project Structure For SaaS 1, the code mostly lived in 3 files: main.py, functions.py, and style.py. While this was fine when it was a prototype, after I added authentication, a user database, Stripe integration, and multiple web pages, this became a nightmare to maintain. That pain motivated me to spend more time thinking about how to architect the app before diving into writing code. The final project structure is as follows.

├── assets/         # webiste assets
├── components/     # UI components
├── data/           # sqlite database
├── pages/          # website pages
├── prompts/        # LLM prompts
├── utils/          # python functions
├── pyproject.toml  # project dependencies
├── main.py         # main file
├── sandbox.ipynb   # notebook for ad hoc debugging
└── uv.lock         # exact dependencies

Mistake 3: No Deploy from GitHub Although Railway significantly streamlined the deployment process, there was still unnecessary friction in how I shipped code. I’d push code to Railway using their CLI, which required a few steps. For SaaS 2, however, I deployed the app from GitHub, which not only made the initial step-up super fast, but adding features was as simple as running git push.

Spec-driven AI Coding Beyond learning from the mistakes of SaaS 1, there were a few big lessons that came up while building SaaS 2. The first of which was learning how to code with AI 10X faster. Before building SaaS 2, I primarily used AI to code by asking it to do a task with (maybe) some guidance and then editing the result. While this often works well, there are a few times this goes completely wrong and I end up spending hours debugging and fixing the code (which takes longer than just writing it from scratch). However, my approach fundamentally changed when I started using Claude Code.

Claude Code Halfway through my 30-day launch window, I hit my usage limit for Cursor’s AI panel. This prompted me to pay $20/mo for Claude Code.

Initially, Claude Code was a big shift from Cursor’s UI. That’s because it 1) lives in the terminal and 2) overwrites code instead of showing diffs. However, there was one feature that made the change worth it.

Instead of Cursor’s Ask vs Agent modes, Claude Code has Plan vs Auto Edit modes. The key difference is that in plan mode, Claude won’t make any code changes. Instead, it will create a detailed spec sheet outlining the changes it wants to make. This has two key benefits. First, it helps avoid generating misaligned code that must get rewritten. Second, and most importantly, it keeps me informed about how the code base is actually working, which significantly reduces the technical debt I accumulated while building with AI.

Committing Little and Often Another good habit promoted by Claude Code was doing small, focused git commits more often. Without Cursor’s convenient diff UI for code changes, I had to be much more careful about preserving the working version of the code base. Ultimately, this forced me to implement one change at a time and create code checkpoints via Git commits.

GTM ≥ Coding Coming from a technical background, sales and marketing are by far my biggest deficits. This, admittedly, caused me to underestimate the importance of these skills. My original plan for the 30-day launch was to spend the first 3 weeks building the app and the final week selling it. When the time came, however, I realized that 1 week is not nearly enough time. Looking back, I should have started with go-to-market (GTM) and then promoted during the build process, so that when the app was done, there was a crowd of people ready to try it.

My GTM Plan Since I can’t turn back time (and I need the practice), I’m going to spend the next 6 weeks getting customers for Ghst, instead of building another app. While the launch campaign is still under development, here’s the checklist I’m using to create it.

• Avatar: Who is this for? Where are they?
• Dream Outcome: What does the avatar want/need? (Note: forget about the app when writing this)
• Customer Journey: What is the journey the avatar must take to achieve the dream outcome?
• Pain Points: What challenges and problems come up along the way?
• Messaging: What are some key terms, phrases, and taglines that speak to the avatar and their pains?
• Launch Summary: Campaign title, length, goal, channels, and volume for each channel.

Final Thoughts While I still have a lot to learn when it comes to building a successful SaaS, I hope the lessons here help you avoid some of the mistakes I’ve made along the way. If you have any questions about my process (or feedback), please let me know in the comments :)

Read the full article here: https://medium.com/the-data-entrepreneurs/what-i-learned-launching-an-ai-saas-in-30-days-ab9a49d38689