How I Vibe Coded My Entire SaaS — Step by Step

Two years ago, my most technical skill was a nested IF formula in Google Sheets. Today I have built three production SaaS products using vibe coding. Not prototypes. Not demos. Production software that handles real users, processes real payments, and generates real revenue. I did this without knowing how to code, without a technical co-founder, and without raising a single euro in funding.

This is the case study nobody asked me to write, but the one I wish had existed when I started. Three products, end to end — how each was built, what it cost, what went wrong, and the honest numbers.

Product 1: Soulin Social — The Content Multiplier

What it does: Takes a single raw thought (50-150 words) and generates 35+ platform-ready posts in my voice. LinkedIn posts, tweets, tweet threads, Instagram captions, Substack intros, email snippets — all formatted for their respective platforms, all sounding like me.

Why I built it: I was spending 15-20 hours a week on content creation. I tried every repurposing tool on the market. They all produced generic output that sounded like AI — not like me. I needed a tool trained on my specific voice, my specific rhythms, my specific quirks (em dashes everywhere, no exclamation points on serious sentences, short-short-long-short sentence patterns).

Time to build: The first working version took one weekend. Getting it to production quality took two months of iteration.

The build process:

Week 1 was the core engine. I sat down with Claude Code and described the system: "I want to input a raw thought and get back formatted posts for LinkedIn, X, Instagram, Substack, and email. Each platform should have its own formatting rules. The voice should match samples I provide."

Claude built the initial pipeline — a Node.js application that takes input text, passes it through a series of AI prompts (one per platform), and outputs formatted content. The first version worked but the voice was terrible. Generic motivational content that could have been written by anyone. I described my voice in painstaking detail: the vocabulary I use, the sentence structures I prefer, the topics I avoid, specific examples from my actual writing. I pasted twenty of my best posts as reference material.

The voice improved dramatically. Not perfect — maybe 70% accurate. But the remaining 30% was the part I could edit quickly by hand. Good enough to ship.

Week 2-3 was the interface. I built a simple web front end with a text input, platform toggles, and a generate button. The output displayed in cards — one per platform — with copy buttons and character counts. Claude built the entire front end from my descriptions. I iterated on the design through conversation: "make the cards wider," "add a preview mode that shows how the post will look on LinkedIn," "the copy button should show a checkmark for two seconds after clicking."

Week 4-8 was the iteration loop. I used the tool every day and every day I found something to improve. The LinkedIn posts were too long. The tweets lacked hooks. The Instagram captions were not using the right hashtag style. Each discovery became a prompt, each prompt became a fix, each fix made the tool slightly better.

By month two, Soulin Social was generating content that friends could not distinguish from my manually written posts. That was the benchmark — when the output passed the "could Cathy have written this?" test.

Tech stack: Node.js, Claude API for generation, Supabase for user data and content storage, Vercel for hosting, Stripe for payments.

Lines of code: Approximately 4,200 across all files. Estimated 95% AI-generated, 5% manually edited (mostly configuration and environment variables).

Monthly cost to run: About $45 (Supabase + Vercel + Claude API usage).

Revenue: Soulin Social generates recurring revenue from subscribers who use it for their own content. I will not share exact numbers publicly, but it covers its costs many times over and is the product I am most proud of building.

Biggest mistake: I launched with too many platforms. The first version tried to generate content for eight platforms including Pinterest and TikTok captions. The quality was thin because I was spreading the voice-training effort across too many formats. When I cut it to five core platforms and did each one well, the quality jumped and users actually preferred the focused version.

Product 2: KINS Sales Agent — The AI Closer

What it does: Handles initial sales inquiries for the KINS wellness hotel brand. Potential guests ask questions via a chat interface. The agent responds with accurate information about healing protocols, room availability, pricing, and logistics. When a conversation reaches booking intent, it escalates to me with a full conversation summary.

Why I built it: I was spending 2-3 hours a day responding to the same fifteen questions. "What protocols do you offer?" "How long should I stay?" "What does it cost?" "Do you accept insurance?" The answers were consistent and factual — exactly the kind of work an AI should handle, freeing me for the conversations that actually require human judgment.

Time to build: One week to first version. Three weeks total to production quality.

The build process:

The sales agent was architecturally more complex than Soulin Social because it needed to maintain conversation state, access a knowledge base, and make judgment calls about when to escalate.

Day 1-2: I built the knowledge base. I wrote a comprehensive document — about 8,000 words — covering every aspect of KINS: the healing protocols, the properties, the pricing, the booking process, the FAQ. This document became the agent's brain. Claude Code helped me structure it for easy retrieval.

Day 3-4: I built the conversation engine. The prompt to Claude was: "I want a chat application where a user sends a message and an AI responds based on a knowledge base document. The AI should be warm, knowledgeable, and direct — like a concierge who genuinely cares about the guest's healing journey. It should never make up information. If it does not know the answer, it should say so and offer to connect the guest with me."

The first version was too robotic. It answered questions accurately but felt like talking to a manual. I spent a full day refining the personality — adding specific phrases, adjusting the warmth level, making it ask follow-up questions that demonstrated genuine interest in the guest's situation.

Day 5-7: I built the escalation logic. This was the hardest part. The agent needed to recognize when a conversation had moved from "browsing" to "ready to book" — and the signals are subtle. Questions about specific dates, questions about payment methods, repeated visits to the pricing topic, explicit statements like "I want to book."

I described the escalation rules to Claude in natural language: "Escalate to me when: the guest mentions specific dates, asks about payment or deposit, asks about cancellation policy, explicitly says they want to book, or the conversation has been going for more than ten messages and the guest is still engaged." Claude translated this into logic. I tested it with fifty simulated conversations and adjusted the thresholds.

Week 2-3: Integration and polish. I connected the agent to my Telegram so escalations came as messages with the full conversation history. I added analytics — how many conversations per day, average conversation length, escalation rate, most common questions. I built an admin panel where I could update the knowledge base without touching code.

Tech stack: Node.js, Claude API for conversation, Supabase for conversation storage and knowledge base, custom chat widget embedded on the KINS site, Telegram for escalation notifications.

Lines of code: Approximately 3,100. Estimated 90% AI-generated.

Monthly cost to run: About $30 (API usage varies with conversation volume).

Impact: The sales agent handles roughly 70% of initial inquiries without my involvement. My personal response time to booking-ready guests dropped from 24-48 hours (because I was overwhelmed) to under 2 hours (because I only see the qualified leads). The conversion rate from inquiry to booking improved because guests get immediate, accurate responses instead of waiting for me to find time to reply.

Biggest mistake: The first version was too eager to escalate. It sent me every conversation where a guest seemed even mildly interested. I was getting fifteen Telegram notifications a day, most for conversations that were just browsing. I tightened the escalation rules significantly — now I get three to five notifications a day, and almost all of them convert.

Product 3: Soulin LifeOS — The Operating System

What it does: A personal operating system for solopreneurs — task management, habit tracking, business metrics, content calendar, financial dashboard, all in one interface. Think Notion meets a business dashboard, but designed specifically for people running a one-person business.

Why I built it: I was using seven different tools to manage my life and business — Notion for tasks, a spreadsheet for finances, Google Calendar for scheduling, a separate tracker for habits, three different analytics dashboards for three different products. Context-switching between tools was killing my focus. I wanted everything in one place, designed for how I actually work.

Time to build: Three weeks to MVP. Ongoing iteration since.

The build process:

This was the most ambitious project and the one where vibe coding proved its limitations — and its surprising strengths.

Week 1: I built the dashboard. A single page with four panels — today's tasks, business metrics (revenue, signups, churn), content calendar, and a habit tracker. Each panel pulled data from a different source. The task panel connected to Supabase. The metrics panel pulled from Stripe's API. The content calendar read from a JSON file I maintained. The habit tracker was standalone.

The first version looked like a developer's internal tool — functional but ugly. I spent two full days on design, describing the aesthetic I wanted: "Clean, minimal, dark mode. Think Bloomberg terminal meets Japanese design — information-dense but not cluttered. Every piece of data should be readable at a glance from arm's length."

Claude built a beautiful dashboard. I was genuinely surprised. The AI produced a design that was better than what I could have briefed a human designer to create, because I described the feeling I wanted rather than the specific implementation, and the AI interpreted that feeling into coherent design choices.

Week 2: I built the integrations. This was the grind. Connecting to Stripe's API required authentication, webhook handling, and error management. Connecting to Google Calendar required OAuth. Each integration was a mini-project.

Get essays like this — plus behind-the-scenes builds — in your inbox every week. Subscribe free →

My process for each: describe the integration to Claude, get the initial code, test it, discover it broke on some edge case, describe the edge case, get a fix, test again. The Stripe integration took a full day. Google Calendar took two days because OAuth is confusing even for AI.

Week 3: I built the habit tracker and the daily review flow. Every evening at 9pm, the app prompts me with a three-question review: what went well, what did not, what will I focus on tomorrow. The answers are stored and I can see trends over time — which days are productive, which habits correlate with good output, where I consistently fall short.

This feature was simple to build but transformative to use. The data revealed patterns I had not noticed: my best writing days were always preceded by walks along the canal. My worst days correlated with skipping morning movement. The system made my own patterns visible to me.

Tech stack: Next.js (a framework Claude chose for me), Supabase, Stripe API, Google Calendar API, Vercel.

Lines of code: Approximately 6,800. Estimated 92% AI-generated.

Monthly cost to run: About $25 (mostly Supabase and Vercel).

Revenue: LifeOS is not publicly available yet. I am using it personally and considering opening it to the Soulin membership as a benefit. The value for me personally is not measured in revenue — it is measured in the two hours per day I reclaimed from tool-switching.

Biggest mistake: I tried to build everything at once. The first week, I had a feature list of twenty-three items. I shipped four of them in week one, panicked that I was behind schedule, and tried to rush the rest. The result was eight half-finished features that all kind of worked and none of them worked well. I stopped, deleted everything except the four working features, and added new ones only when the existing ones were solid.

The Numbers That Matter

Across all three products:

Total lines of code across all products: roughly 14,100.
Total AI-generated: roughly 93%.
Total monthly operating cost: roughly $100.
Total development cost: $0 (beyond my existing Claude subscription).

Compare this to what it would cost to hire a developer to build three production SaaS products: conservatively $30,000-80,000. And that does not include the ongoing maintenance, the feature requests, the bugs, and the communication overhead.

The Lessons That Apply to Everyone

Lesson 1: Build for yourself first. Every one of these products started as a tool I needed for my own business. I did not build them because I thought they would sell — I built them because they solved my specific problems. The fact that other people also have those problems came later. Building for yourself guarantees that at least one person (you) will use the product passionately.

Lesson 2: Ship the ugly version. The first version of Soulin Social was hideous. The first version of the sales agent was too robotic. The first version of LifeOS looked like a spreadsheet. I shipped all of them anyway. The feedback from real usage was worth more than any amount of pre-launch polishing.

Lesson 3: Vibe coding is a conversation, not a command. I do not type one prompt and get a product. I have thousands of messages with Claude across these three products. Each message refines, improves, fixes, or adds something. The relationship is collaborative — I provide the vision and the domain knowledge, the AI provides the implementation. Neither of us could do it alone.

Lesson 4: Know your limits. Vibe coding has limits. I cannot build a mobile app this way (not well, anyway). I cannot build anything that requires real-time performance optimization. I cannot build anything that requires deep algorithmic work. For those things, I would need a developer. But for web applications, bots, dashboards, and content tools — vibe coding is more than sufficient.

Lesson 5: The AI-generated percentage does not matter. People ask me what percentage of the code is AI-generated like it is a credibility metric. It is not. The value is not in the code — it is in the system the code enables. Whether I wrote it or Claude wrote it is irrelevant to the user who generates 35 posts in their voice every morning.

What I Would Do Differently

If I were starting over, knowing what I know now:

I would start with the simplest possible version. Not the minimum viable product — the minimum valuable product. What is the smallest thing that delivers real value? Build that. Ship that. Learn from that. Then add.

I would set up proper error monitoring from day one. I shipped Soulin Social without proper error tracking and spent weeks not knowing about bugs until users told me. A simple error monitoring setup (which Claude can build in ten minutes) would have caught issues in real time.

I would version control everything from the first line. I lost work twice because I was editing files directly without git. Two minutes of setup prevents hours of pain.

I would talk to users earlier. I built LifeOS for three weeks before showing it to anyone. When I finally did, the first person said "can you add a weekly view?" — something so obvious that I was embarrassed not to have included it. Users see what builders miss.

You Can Do This

I want to end with the thing that would have helped me most when I started: explicit permission.

You can build a SaaS product. You — the person reading this who does not know what an API is, who has never opened a terminal, who has been told you need a technical co-founder. You can do this.

Not because you are special. Not because it is easy. Because the tools are available, the cost is minimal, and the only prerequisite is a problem you care about solving and the persistence to iterate until the solution works.

I am a Korean dropout who built a hotel brand from a cafe in Bali and then taught herself to build software by talking to an AI. If that sentence sounds improbable, good. Improbable things are the only things worth building.

Start with one product. Start with one problem. Start with one prompt.

The rest is iteration.

The full Soulin system — tools, workflows, templates, and the community of builders using them — is inside the membership. But everything I described here started with a $20 AI subscription and a problem I wanted to solve. Start there.