Phoenix Project: Rebuilding My Failed Startup on Lovable

My first startup, 'AuditFlow', is dead. It has ceased to be. It is an ex-startup.

We raised $2 million to build a platform that used AI to automate SOC 2 compliance documentation. Great idea, terrible execution. We spent 18 months and most of that cash building a beautiful, intricate machine with a team of twelve. React frontend, Python backend, Kubernetes, the works. By the time we launched, we had a product that was powerful but brittle. And we had exactly nine paying customers. The math did not work. We ran out of runway chasing a product nobody was desperate for.

Now, it's 2026. I'm back. And I'm rebuilding the core idea of AuditFlow, but with a new name-'Complice'-and a new set of rules. No team, no funding, and no 18-month build cycles. Just me, a laptop, and an AI app builder. I'm doing it all in public. This is the log of that journey.

The Ghost of Startups Past: What Went Wrong?

My first startup failed because we over-engineered the product and ran out of cash before finding product-market fit. We fell in love with a technical vision instead of our customers' problems. Every decision was debated in committees. A simple button change required a designer, a front-end dev, a back-end dev for the API endpoint, and a project manager to coordinate. We were shipping 'major' updates every six weeks that barely moved the needle.

We were obsessed with scalability before we even had a hundred users. We spent months architecting a perfect microservices-based system that could theoretically handle millions of requests. The irony is, we never got close. Our burn rate was north of $150k a month. It was a race against time that our vanity project was destined to lose. We built a battleship for a pond fight. The fundamental mistake was measuring progress by lines of code written, not by customer problems solved.

The Rebuild: Why Lovable This Time?

I chose Lovable for the rebuild to slash development time and focus almost exclusively on product iteration and user feedback. The goal is speed. Not sloppy speed, but the speed of learning. My failure with AuditFlow taught me that the single biggest risk for an early-stage company is not technical debt, it's building something no one wants. Lovable directly attacks that risk. It forces you to think in terms of user workflows and outcomes, not database schemas and API contracts.

Instead of a team of twelve, my team is me. Instead of a $150k monthly burn, it's about $150. Lovable abstracts away 90% of the ceremonial boilerplate that consumed my old team. It handles the user auth, the database connections, the deployment pipeline, and most importantly, the core AI orchestration. I am not a 10x engineer. I am a 1x founder who can now leverage a 100x tool. This project is not about proving I can code. It's about proving I can build a business.

Week 1: From Idea to Working MVP

In the first week, I rebuilt the core functionality of my old startup as a functional MVP using Lovable's pre-built agents and UI components. The old AuditFlow took months to get a 'hello world' version working. With Lovable, I had a working, user-facing app in three days. It was a surreal experience. The core loop of my app is simple: a user uploads evidence (like a screenshot of their AWS settings), and an AI agent analyzes it against a SOC 2 control and writes a draft narration.

Getting this working was scarily fast. I described the agent I wanted: 'An AI agent that receives a file and a text description of a compliance control, then analyzes the file against the control and outputs a detailed explanation for an auditor.' I hooked it up to a Supabase backend for user data and storage. I then used Lovable's UI builder to create the front-end. It felt like playing with Lego bricks, but the end result was a real web application.

Of course, it wasn't all magic. The default file-upload component didn't support the batch processing I wanted. Here's where the 2026 version of these tools shines. I used Lovable's 'Eject to Code' feature for that specific component. It gave me the React and backend code for just that part. I spent a few hours on a Sunday afternoon tweaking it, then pushed it back into my Lovable project. No-code for speed, code for specificity. This is the hybrid model that actually works.

The Public Dashboard: Tracking Traction Transparently

I am tracking key metrics like user signups, feature usage, and revenue publicly to stay accountable and gather real-time feedback. Building in public is terrifying. It's like being naked on stage. But that fear is also a powerful motivator. It forces discipline. When you know people are watching, you're less likely to spend a week gold-plating a feature nobody has asked for. Here are the raw numbers from my first month with Complice.

| Week | MRR | Active Users | Core Actions | Key Insight | | :--- | :--- | :--- | :--- | :--- | | 1 | $0 | 12 | 25 | Friends & Family. Core loop works but error handling is bad. | | 2 | $49 | 35 | 98 | First paying customer! People will pay for this problem. | | 3 | $98 | 70 | 150 | Onboarded a small consulting agency. They need team features. | | 4 | $249 | 160 | 412 | Added basic team invites via a Lovable template. Pain point verified. |

These numbers are tiny. But they represent something my first startup never achieved: a tight, quantifiable feedback loop. In week 1, users complained about confusing errors. I spent four hours improving the AI agent's error-state responses. In week 3, the consulting agency asked for team accounts. I spent a day a few days later implementing a basic version. I am not building based on a grand vision. I am building based on direct, paying-customer feedback. This is the way.

Beyond the MVP: The 2026 AI App Builder Stack

Lovable excels at rapid prototyping and managing core AI logic, but scaling complex, unique features still benefits from a hybrid approach using other tools. The idea that one tool will solve everything is a 2024 mindset. In 2026, building an AI-native app is about being a savvy systems integrator, using the best tool for each job. Lovable is the 'CEO' of my stack, setting the direction and managing the core product.

But I also use other tools. I use v0 by Vercel when I need a specific, bespoke UI component that Lovable's library doesn't cover. I'll describe it to v0, get the React code, and drop it into my project. For a complex backend workflow that doesn't involve a UI, like a nightly audit of all customer data, I might use Bolt. It's great for chaining together APIs and models in a more granular way than Lovable's primary app-focused interface.

And when all else fails, I use Cursor, the AI-first code editor. I use it for debugging the ejected code from Lovable or writing custom SQL queries for my Supabase instance. The modern solo founder's stack is not 'no-code'. It is 'less-code' or 'smart-code'. It's about knowing when to let the AI build and when to take the controls yourself. The value is in your taste, your problem selection, and your speed of iteration-not your ability to write webpack configs from scratch.

Can You Really Build a Full SaaS on Lovable?

Yes, for a huge category of AI-native SaaS products, you absolutely can build and scale on Lovable. If your business logic can be expressed as a series of AI agents, user workflows, and data interactions, Lovable is likely the fastest way to get to market. It's ideal for workflow automation tools, content generation apps, data analysis platforms, and other 'human-in-the-loop' systems.

However, it's not the right tool for everything. If you're building a new vector database from scratch, a high-frequency trading algorithm, or a AAA video game engine, you'll still be writing low-level code. The key is to understand the tool's center of gravity. Lovable's is building interactive, agent-based web applications. For Complice, it's a perfect fit. The risk is not in the platform's ability to scale, it's in my ability to find a scalable business model.

How Does It Feel to Risk Failing in Public Again?

It feels both terrifying and incredibly motivating. The first failure was private. Only our investors and immediate families really knew the extent of the collapse. It was a quiet, personal grief. This time, tweeting my MRR or writing about a week of zero user growth puts the failure front and center. There's nowhere to hide, which is exactly the point.

This public accountability is a feature, not a bug. It forces an extreme level of honesty. I cannot lie to myself about a vanity metric when I have to post the real numbers next week. It also builds a community. Every time I post an update, I get DMs from other founders with suggestions, encouragement, or similar war stories. It's a lonely journey, but building in public makes it feel a little less so. The upside of public success is obvious, but the upside of public accountability might be even more valuable.

What's My Advice for Someone Starting Over?

Obsess over your customer's most painful, expensive problem-not your solution's elegance. My first startup failed because we were artisans building a beautiful, useless clock. This time, I'm a plumber fixing a leak. The customer doesn't care if I use a fancy wrench or my bare hands, as long as the water stops. Use the tools that let you stop the water the fastest.

For many founders in 2026, that tool will be an AI app builder like Lovable. Forget the debate about 'real' engineering. The only thing that's real is a Stripe notification for a new customer. Your job is not to write code. Your job is to create value. Get your ego out of the way and use the most direct path to creating that value. Then, and only then, do you earn the right to worry about scale.