My flow to vibecode new apps as a 16k/mo indie founder

I've been working on my main SaaS for over 2 years now and brought it to $16k MRR. Along the way, I've always been tinkering with other ideas and side projects.

I've tried a lot of things:

  • Vibe-coded a few apps with Lovable & Supabase
  • Built 2 internal tools starting with Chef, then iterating in Cursor
  • Built 3 different mobile apps with React Native + Convex

All of them flopped, but I built them mostly for the experience.

Recently, I started working on a new product, an email marketing tool for SaaS founders. All those learnings helped me build a full-featured app with a reliable backend and AWS integration in about 2 weeks (while still running my other startup).

Here's what I've learned:

Two non-negotiables

  1. Use the best model available. Go into debt if you have to. The difference between Sonnet 4.5 and Opus 4.5 is massive. If you're stuck on older models, you'll be much slower. Right now, it's Claude Code with Opus 4.5. In a month, it might be something else - stay flexible.
  2. You still need technical knowledge. AI will produce nonsense sometimes. You need to catch it and correct it.

Get the foundations right

The most important thing is nailing your architecture early. When you have a solid foundation - properly typed database, coherent structure - iterating on features becomes 10x easier.

Here's what I recommend:

  1. Use TypeScript with strict typings. No shortcuts.
  2. Use tRPC (or similar) to get strong types between frontend and backend.
  3. Set up your styling system early. Shadcn works great for most cases.
  4. Configure ESLint + strict tsconfig from day one.
  5. Use a typed ORM. I prefer Drizzle.
  6. Think deeply about your schema. What data do you need to store? How will you process it? I like to brainstorm with Gemini first, get a dump of all the info, then send it to Claude Code to implement.

Why does all this matter? When you have proper types end-to-end, it's 10x easier for AI to understand all the relationships in your codebase.

My take on testing

I strongly believe you should have unit tests for all your core functionality. Mock your database using something like PGlite and you're good to go.

This helps you move fast while making sure your app actually works. Most of your endpoints should be \~5 lines where you just call a well-tested function.

As for UI tests and E2E tests - I don't think they help at this stage. They slow you down, and you'll be changing your UI constantly. If you want to iterate quickly, skip them for now.

One more tip: keep configuration in code

Whenever you can, avoid manual setup. If you need to do something on AWS or GCP, use Terraform. Don't go through dashboard hell manually clicking around. It'll speed you up massively in the long run.

Writing the code

Run a few agents in parallel. Once you already have the schema, it's easy to add different API requests, screens, etc. at the same time.

Every 4–6 hours, stop and review everything you've done. Use Cursor Review, ask Claude Code to give you feedback about your PR, and verify that it added zero unexpected fields in the database. Make sure the flow still works as expected.

Don't allow AI to write code for days without review - it'll be incredibly hard to clean up and make useful.

That's the flow. If you're building a SaaS and need to set up email sequences for onboarding or retention, check out Sequenzy - we have a generous free tier and you can start sending sequences within minutes of signing up.

Good luck, and ship fast!

Author: polnikale