DEV Community: Wasp

What's the Best Way to Vibe Code a SaaS in 2026?

vincanger — Thu, 26 Mar 2026 09:05:13 +0000

You've probably seen the tweets, the YouTube tutorials, and the "I built a SaaS in 24 hours with AI" posts. But if you've actually tried to vibe code a SaaS, you know the reality is much messier than that.

Luckily, there are a bunch of tools, SaaS boilerplate starters, and workflows that you can use to build a profitable (side) business with, as long as you know how to apply them correctly.

So let's take a look at what's out there, and what really works.

TL;DR

AI-native platforms (Replit, Lovable, Bolt) are great for prototyping but hit a ceiling as complexity grows. Code is coupled to their infra, and it quickly becomes expensive and difficult to maintain.
AI coding tools (Claude Code, Cursor, Codex) give you great code and full control, but they need the right foundation and you'll need some fundamental understanding of the underlying tools to work well with them.
The winning combo: Claude Code paired with a well-structured SaaS boilerplate like Open SaaS is the best way to vibe code a SaaS in 2026, giving you coherent code generation, along with better control as your app grows.
Two key techniques for effective vibe coding: (1) LLM-friendly docs (llms.txt and beyond), (2) full-stack debugging visibility.

The Vibe Coding Landscape in 2026

AI-assisted coding tools come in different flavors, and understanding their differences is key to picking the right approach.

In the table below, we quickly compare the two approaches. In the sections below that, we go into more detail about each approach.

	AI-Native Platforms	AI Coding Tools
Examples	Replit, Lovable, Bolt.new	Claude Code, Cursor, Codex
Setup	Zero-config, browser-based	Local install, terminal/code-focused
Best for	Quick prototypes and demos	Production apps and SaaS businesses
Code control	Limited — AI makes structural decisions	Full — you own and control everything
Vendor lock-in	High — coupled to platform infra	None — works with any stack
Scalability	Scalability degrades as complexity grows	Scales with your codebase. No limitations.
Deployment	Platform-hosted (limited options)	Deploy anywhere (Railway, Fly.io, VPS)
Cost at scale	Monthly fee + additional costs for debugging, storage, hosting, etc.	Cheaper — monthly fee + choose your favorite hosting solution

AI-Native Platforms

Tools like Replit Agent, Lovable, Bolt.new, and v0 aim for a "zero-config", purer "vibe coding" approach, where you describe what you want and get a working app. They aim to remove setup, config, and having to touch the code and/or terminal as much as possible. They're impressive for demos and fast prototyping.

The catch here is that most of these apps are then locked-in to their hosting, auth, and storage solutions. This isn't always bad, but things can easily get complicated and expensive as your app grows:

The "70% problem": these tools get you roughly 70% of the way to a working product. The last 30% — auth hardening, error handling, performance, deployment config — requires significant manual effort. One estimate puts the cost of making Bolt.new output production-ready at $5,000-$20,000 in professional dev work.
Infrastructure coupling: the code you export is tightly coupled to a specific service stack. Lovable, for example, generates code deeply wired into Supabase, a separate service for auth, storage, realtime, edge functions, etc. Leaving Lovable/Supabase means rewriting all of those integrations. Replit similarly relies on its default Auth, Storage, and database options.
Code quality degrades at scale: Bolt.new projects with 15-20+ components experience severe AI context degradation — duplicated code, forgotten patterns, and inconsistencies. Replit Agent has been flagged for generating "non-idiomatic or messy" code that becomes harder to maintain as projects grow. Multiple developers report spending $1,000+ in tokens just debugging AI-generated bugs.
Limited architectural control: the AI makes structural decisions for you, and those decisions compound. Data models get rigid, logic gets tightly coupled, and by the time you want to refactor, you're looking at a near-rewrite anyway.

In the end, the most common feedback from users of these tools is that they allow you to move fast and to easily build initial prototypes, but maintainence and upgrades quickly become complex and expensive.

To solve this, working on code locally, instead of a platform, is the first step.

AI Coding Tools

Tools like Claude Code, Cursor, GitHub Copilot, and Codex work directly with your local files, and are better at generating production-ready code that you control.

The pros here are: full control, no lock-in, works with any stack, and the added bonus is that it will be cheaper. You can version it, test it, deploy it anywhere, and switch tools whenever you want.

But these tools require a bit more work to get the most out of them. You'll have to be comfortable using the terminal, install a few more underlying tools, and its good to have a general understanding of the fundamentals when working with them. But, luckily, these tools can help you each step of the way, and if you set things up right (which we will show you how to do in this article) you can go all the way with them.

In comparison to the AI-native platforms, if you're serious about building something substantial these tools give better results at cheaper prices.

We'll use Claude Code as the driving example throughout this post, but the same principles apply to Cursor, Codex, and others.

The Winning Combo: Claude Code + SaaS Boilerplate

Most of the tedious parts of building a SaaS are routine, boilerplate tasks like setting up authentication, payments, email sending, file uploads, admin dashboard, etc. These are the things that are time-consuming to set up, aren't very creative or interesting, but are 100% necessary for a functional SaaS.

Luckily, tons of SaaS boilerplate starter kits exist, giving you a solid foundation to build your SaaS on top of. They provide all the necessary integrations, plumbing, and glue code, along with some nice extras, so you can just focus on building the fun part of your app.

A well-structured boilerplate has some key benefits: it allows you to start working on the actual business logic of your SaaS from day one. It also gives the AI patterns, structure, and conventions to follow, making it easier for tools like Claude Code to generate clean, consistent code.

It's like giving a skilled carpenter a well-organized workshop instead of an empty shed. The tools are there, the materials are laid out, and there's a clear plan to follow.

You keep the full control, but you skip the part where you (or your AI) have to make a hundred decisions about project structure, auth patterns, payment integration, and deployment config. That's all solved for you already by the starter kit.

But, because so many boilerplate starters exist, choosing the right one can be a pain.

Choosing Your SaaS Boilerplate

There's no shortage of SaaS boilerplates out there. The real question isn't just "which one has the best features?", it's which one sets you (and your AI coding tool) up for long-term success. A few factors matter more than you'd think: cost, deployment flexibility, community support, and how well the codebase structure plays with AI.

In the table below, we quickly compare some popular, battle-tested starters. In the sections below that, we go into more detail about each of them.

	Paid Boilerplates (ShipFast, Supastarter)	Open SaaS
Price	$250-$800+	Free, open-source
Auth	Third-party providers (Clerk, Supabase auth, Better Auth)	Built-in (email/password, Google, GitHub, Microsoft, Slack, etc.)
Payments	Stripe, Lemon Squeezy, or Polar.sh, etc.	Stripe, Lemon Squeezy, or Polar.sh
Deployment	Vercel + Supabase (typically)	Railway, Fly.io, or any VPS
Community	1-2 maintainers	13,000+ GitHub stars, active open-source community
LLM-friendly docs	llms.txt	llms.txt
Codebase structure	Multiple apps/packages with separate configs and third-party integrations wired together	Single app, feature-based organization with fullstack code colocated

Paid Boilerplates

Options like ShipFast ($250) and Supastarter (starting at $299) are popular choices. They're packed with lots of features and have a strong history of adoption and support.

But there are a few things to consider:

Upfront cost: $250-$800+ before you've written a line of business logic
Vendor-leaning stacks: many are built on top of Vercel + Supabase + third-party auth services. That's more vendor lock-in and recurring hosting costs on top of the purchase price. You're not just paying for the boilerplate, but you're also committing to a specific infrastructure stack.
Code Quality: most paid boilerplates are maintained by a one or two developers. An open-source project, on the other hand, is maintained by many more people, and the community input is much larger, making it more robust and reliable.
Stack fragmentation: ShipFast is a flat Next.js app where auth, payments, email, and database are each handled by separate third-party libraries you wire together yourself. Supastarter is a Turborepo monorepo with 4 separate Next.js apps and 8+ shared packages, each with its own config. Both approaches mean more files for an AI tool to navigate, more indirection to follow, and more context needed to make a single cross-cutting change.

None of this means paid boilerplates are bad. They can absolutely save you time. But it's worth understanding what you're signing up for beyond the purchase price.

Open SaaS -- a free, open-source, production-ready SaaS boilerplate starter

Open SaaS is free, and open-source. It's powered by Wasp — a batteries-included full-stack framework for React, Node.js, and Prisma apps.

Here's what you get out of the box:

Auth: email/password, Google, GitHub, all pre-configured and without third-party providers
Payments: Stripe, Lemon Squeezy, or Polar.sh. Take your pick.
Email, file uploads, admin dashboard, analytics, e2e tests: the full SaaS toolkit.
Deploy anywhere: Railway, Fly.io, or any VPS. No vendor lock-in.
13,000+ GitHub stars and an active open-source community backing it.

The documentation is a million times better for Open SaaS than for ShipFast... I got frustrated with ShipFast's terrible code and terrible documentation (or just the lack of) and I found Open SaaS. It's looking like it will be a better experience.

★ ★ ★ ★ ★

Sean Nam Founder @ NotePulse

Because Open SaaS is built on Wasp, everything lives under one roof. React frontend, Node.js backend, and Prisma database layer are all managed by a single framework, with a declarative config (main.wasp or main.wasp.ts) that defines your routes, pages, operations, auth, and background jobs. The codebase is organized by feature (e.g. auth, payments, file uploads) with backend logic and frontend components sitting side by side. When an AI coding tool reads main.wasp, it immediately understands the full app structure without having to jump between separate apps, packages, or third-party service abstractions. One framework, one config, one mental model for the AI to follow.

Effectively Vibe Coding Your SaaS

So we've got our AI-assisted coding tool and our SaaS boilerplate starter, but to get the most out of AI-assisted development, you need two more things working together. Note that these tips come from real-world experience building full-stack apps with Claude Code and Wasp, and we covered them in depth on the Wasp blog.

1. LLM-Friendly Documentation

LLMs don't always get things right, and may sometimes be out-of-date with the latest features of the tools you're using. For example, if you're using a framework that shipped a new version last week, your AI tool probably doesn't know about it, unless you give it the docs.

But how you give it docs matters a lot, because LLMs don't have a long-term memory, rather they have context windows, which is like a limited memory of only the most recent conversations. So with each new session, you have to remind them of what you're working on, with, and what you want to do.

One of the best solutions is to use llms.txt files. These are structured docs in a single, machine-readable plain text file that's purpose-built for LLMs.

Open SaaS and Wasp both provide these:

Open SaaS docs: https://docs.opensaas.sh/llms.txt
Wasp framework docs: https://wasp.sh/llms.txt

Just add these URLs to your AI coding tool's chat session or "memory" (e.g. CLAUDE.md, AGENTS.md). When the AI needs to, for example, understand how Wasp auth works or how to set up Stripe payments in Open SaaS, it has the full, up-to-date docs right there.

And it's not just Open SaaS and Wasp. Most developer tools and integrations have adopted the llms.txt standard. Try appending /llms.txt to any tool's docs URL and see what comes back. You'd be surprised how many services already support it. When you're implementing a new integration, pass its llms.txt to your coding agent so it has good guardrails for development.

Another pro tip: when you're working on a specific feature, search the tool's docs for the relevant guide and look for a "Copy for LLMs" button. Many doc sites now offer this. Or just try adding .md to the end of a specific URL to get an LLM-friendly version of that page. For example, Stripe's guide on SaaS subscriptions is available at https://docs.stripe.com/get-started/use-cases/saas-subscriptions.md. Pass that to your agent and it'll have the knowledge it needs to implement Stripe subscriptions correctly.

2. Full-Stack Debugging Visibility

AI can write code all day, but if it can't tell whether the code actually works, you're constantly stuck in the middle, running the app, checking the browser, copying error messages back and forth.

The fix is giving your AI tool full-stack visibility into what's happening when the code runs, so it can see the errors, and fix them without you having to always intervene.

Background dev server: Run your dev server as a background task so the AI can see server logs, compilation errors, and runtime exceptions in real time. In Claude Code, you can use background tasks (Ctrl+B) to keep wasp start running while you work, or just tell it to "start the dev server as a background task".
Browser automation: Tools like Chrome DevTools MCP or Vercel's agent browser let AI see what's actually rendering in the browser -- console errors, network requests, DOM state -- without you having to screenshot anything. The AI can verify that the button it just added actually appears on the page and handles clicks correctly.

Together, these create a tight feedback loop: AI writes code → sees the result → spots the error → fixes it → verifies the fix. This improves the quality of the code it generates, and makes the entire process less tedious and more efficient.

Getting Started: From Zero to Vibe Coding

Ready to try it? Here's how to go from nothing to vibe coding a SaaS in a few minutes.

Step 1: Install Wasp and Get the Template

npm i -g @wasp.sh/wasp-cli
wasp new my-saas -t saas
cd my-saas

This scaffolds a new Open SaaS project with auth, payments, email, file uploads, an admin dashboard, a landing page, and more — all pre-configured and ready to go.

Step 2: Set Up Claude Code with the Wasp Plugin

After installing Claude Code, add the Wasp plugin so that it has deep knowledge of the framework, as well as skills and instructions on how to properly use full-stack debugging visibility, llms.txt docs, and more:

claude plugin marketplace add wasp-lang/wasp-agent-plugins
claude plugin install wasp@wasp-agent-plugins --scope project

NOTE: Other coding agents

If you're using a coding agent like Codex, OpenCode, Cursor, etc. you can get the same set of agent skills by running:

npx skills add wasp-lang/wasp-agent-plugins

Then, in a new session, run the plugin initialization skill command to initialize the plugin with Wasp best practices for your project:

/wasp-plugin-init

Step 3: Get Integrations Working (Stripe, Email Sender, OpenAI, etc)

Next, you'll want to get your payment, email sender, and other integrations working (Stripe, Email Sender, OpenAI, etc) before you start building features.

Luckily for you, we've got a complete walkthrough video that guides you step-by-step through creating accounts, adding your API keys, and getting each integration working:

Or if you want your agent to help guide you through the process, you can ask it to fetch the "getting started" guide from the Open SaaS LLMs.txt docs and follow the instructions step-by-step.

Step 4: Start Building

Fire up your database and dev server:

wasp start db
wasp start

Or just tell Claude Code to run start the dev server as a background task and it will run the correct commands for you :)

Now it's finally time to give Claude Code a real feature request — "add a user settings page where users can update their profile" — and watch it reference the Wasp config file(s) to understand your app's structure, reference the right patterns from the boilerplate, and implement the feature correctly.

Because Wasp is opinionated, Claude won't have to guess where to put files, how to wire up routes, or which patterns to follow. It reads the config file(s), sees the existing conventions, and follows them. You get consistent, working code on the first try — or pretty close to it.

Remember, if you're using Cursor, Copilot, or another tool, the same principles apply. Check out our Vibe Coding guide more info.

FAQ

What's the difference between AI-native platforms and AI coding tools?

AI-native platforms like Replit, Lovable, and Bolt.new aim for a zero-config experience where you describe what you want and get a working app. AI coding tools like Claude Code, Cursor, and Codex work directly with your codebase, giving you full control and no vendor lock-in. AI-native platforms are great for quick prototypes but hit a ceiling as complexity grows, while AI coding tools require more setup but produce more maintainable, production-ready code, and can actually be cheaper in the long run.

Can I export my code from Replit, Lovable, or Bolt.new?

Yes, all three platforms let you export your code via GitHub sync or ZIP download. However, the exported code is often tightly coupled to their infrastructure — for example, Lovable generates code wired into Supabase, and Replit uses proprietary auth, storage, and database solutions. This means significant refactoring is needed if you want to deploy elsewhere or switch services.

What is llms.txt and why does it matter for vibe coding?

llms.txt is a structured documentation file in plain text format, purpose-built for LLMs. It gives AI coding tools like Claude Code up-to-date knowledge about the frameworks and tools you're using, reducing hallucinations and outdated code suggestions. Most developer tools now support it -- just append /llms.txt to any tool's docs URL to check.

What is the best free SaaS boilerplate starter for AI-assisted development?

Open SaaS is a free, open-source SaaS boilerplate for React, Node.js, and Prisma apps powered by the Wasp framework. It comes with auth, payments (Stripe, Lemon Squeezy, or Polar.sh), email sending, file uploads, an admin dashboard, and more, all pre-configured. Because it's built on Wasp, the entire stack is managed by a single framework with a declarative config file. The codebase is organized by feature with backend and frontend code colocated, so AI tools can understand the full app structure from one file instead of navigating multiple apps, packages, and third-party integrations.

Does codebase structure matter for AI-assisted development?

Yes, significantly. AI coding tools work best when they can quickly understand the full picture of your app. A codebase organized by feature with colocated fullstack code — like Open SaaS, where backend logic and frontend components sit side by side — gives the AI one clear mental model to follow. In contrast, boilerplates that split code across multiple apps, packages, and third-party integrations require the AI to navigate more files and follow more indirection, which increases the chance of inconsistencies and errors.

How do I set up Claude Code for full-stack SaaS development?",

Install Claude Code, then add the Wasp plugin for deep framework knowledge. Create a new Open SaaS project with 'wasp new my-saas -t saas', set up your integrations (Stripe, email, etc.), and run 'wasp start' as a background task so Claude Code can see server logs and errors in real time. Pair this with browser automation tools like Chrome DevTools MCP for full-stack debugging visibility."

Conclusion

The best way to vibe code a SaaS in 2026 isn't about finding the flashiest AI tool, it's about giving your AI tool the right foundation to work with.

We suggest using Claude Code and giving it three things: a strong SaaS boilerplate starter kit, like Open SaaS, that gives AI a solid foundation to work with, LLM-friendly docs that help AI stay grounded without burning context, and full-stack debugging visibility that closes the feedback loop.

Open SaaS + Claude Code gives you all of this: a free, open-source, production-ready SaaS foundation, the structure and conventions AI needs to generate clean, consistent code, complete LLM-friendly docs for both the template and the framework, and the tools for full-stack debugging visibility. And because it's all free and open source there's no upfront cost, no vendor lock-in, and you can deploy wherever you want.

You spend your time on business logic and product, not the boring stuff.

What Are the Best Full-stack Web App Frameworks in 2026?

vincanger — Mon, 02 Mar 2026 16:00:27 +0000

TL;DR

Laravel, Rails, and Django remain the most battle-tested full-stack frameworks in 2026.
Next.js dominates for React-first apps but requires significant assembly.
Wasp brings the batteries-included experience of Laravel/Rails to the JS/TS ecosystem, with the strongest AI-coding compatibility of the five.

If you want proven maturity, go Laravel for PHP or Django for Python.

If you want to maximum flexibility and don't mind the extra work, go with Next.js.

If you want to ship fast in JavaScript with minimal boilerplate, go with Wasp.

What We're Comparing

In this guide, we compare the most popular full-stack frameworks in 2026: Laravel, Ruby on Rails, Django, and Next.js. We also include Wasp, the framework we're building. We think it's a compelling option in this space, and we wanted to put it side by side with the established players so you can judge for yourself.

We look at what each does well, where each falls short, and which one fits your use case, whether you're a solo indie hacker, a startup team, or an enterprise engineering org.

Beyond the usual criteria like developer experience and ecosystem size, we also evaluate how well each framework plays with AI coding tools like Cursor, Claude Code, Codex, Copilot, and OpenCode — because in 2026, that matters more than ever.

What Makes a Great Full-Stack Framework in 2026?

We focused on five criteria when evaluating full-stack frameworks:

Developer Experience (DX): How fast can you go from init to a deployed app? How much configuration and boilerplate do you (not) have to deal with?
Ecosystem & Community: Are there libraries, plugins, and guides for when you get stuck? Is it being actively maintained?
AI-Friendliness: How well does the framework work with AI coding assistants? Can an LLM understand your project structure and generate correct code?
Deployment Ease: Can you deploy with a single command, or do you need to configure infrastructure manually?
Full-Stack Coverage: Does the framework cover the client, server, and database layer, and how much assembly is required?

Different Flavors of Full-Stack

All five frameworks in this guide can be used for full-stack development, but they take different approaches:

Backend-first full-stack (Laravel, Rails, Django)

These are the original full-stack frameworks. They own the server and database layer with built-in ORMs, migrations, auth, background jobs, and more. Their frontend story varies, e.g. Laravel pairs with Inertia.js or Livewire, Rails has Hotwire/Turbo, and Django uses templates or a separate SPA. These are mature, battle-tested, and genuinely full-stack. If your definition of full-stack is "handles everything from HTTP request to database and back," these frameworks nailed it years ago.

Frontend-first full-stack (Next.js)

Covers client-side rendering and server-side logic (API routes, server components), but the database layer is entirely Bring Your Own (BYO). You choose your ORM, your auth solution, your email provider, and you wire them together yourself.

All-in-one full-stack (Wasp)

Wasp takes a different approach within the JavaScript ecosystem specifically. It uses a declarative configuration file that describes your routes, authentication, database models, server operations, and more in one place. The compiler then generates a React + Node.js + Prisma application. Unlike Laravel or Rails, Wasp removes the need to pick and assemble frontend solutions, and bundles everything within a single mental model. Wasp also brings the batteries-included philosophy of Laravel and Rails to the JS/TS ecosystem, where developers otherwise need to assemble everything from scratch.

Laravel (PHP)

The battle-tested PHP powerhouse that keeps reinventing itself.

Laravel has been the dominant PHP framework for over a decade, and it shows no signs of slowing down. Laravel has a long tradition of incremental, developer-friendly improvements. With over 80,000 GitHub stars and used by 61% of PHP developers, Laravel's community is massive and active.

Key Features

Eloquent ORM — expressive, ActiveRecord-style database layer
New Starter Kits (React, Vue, Livewire) — built-in auth scaffolding for email with optional WorkOS AuthKit for social auth, passkeys, and SSO
Laravel Cloud, or Forge — fully-managed deployments with Laravel Cloud, or VPS server management with Forge
Inertia.js integration — use React or Vue as your frontend with server-driven routing
Queues, events, broadcasting — built-in job processing and real-time features
Laravel Herd — zero-config local development environment

Pros

Incredibly mature ecosystem with solutions for nearly every problem
Excellent documentation — often cited as the gold standard
Huge job market, especially for agencies and SaaS companies
First-party tools for deployment, billing (Cashier), search (Scout), and more
Active release cycle with yearly major versions

Cons

PHP — love it or hate it, many JS/Python developers won't consider it
Frontend story requires extra setup (Inertia.js, Livewire, or a separate SPA)
Performance requires tuning for high-concurrency applications

Best For

Enterprise applications, SaaS products, agencies, and teams already invested in PHP. Laravel is the safest bet if you need a proven framework with an answer for everything.

AI/Vibe Coding Compatibility

Good. Laravel's consistent conventions and excellent documentation mean AI tools can generate reasonably accurate code. However, the PHP + JS split (if using Inertia or a React SPA) means the AI needs to understand two separate codebases. AI-coding tools work well with Laravel, but the full-stack context is split across languages.

Ruby on Rails

The original "convention over configuration" framework, still going strong.

Ruby on Rails practically invented modern web development conventions. Rails 8.0 (released late 2024) doubled down on simplicity with Kamal 2 for deployment, Thruster for HTTP/2, and the Solid trifecta (Solid Cable, Solid Cache, Solid Queue) — replacing Redis dependencies with database-backed alternatives. Rails has approximately 56,000+ GitHub stars and a loyal, experienced community.

Key Features

Active Record — the ORM that inspired every other ORM
Kamal 2 — deploy anywhere with zero-downtime Docker deployments
Hotwire (Turbo + Stimulus) — modern frontend interactivity without heavy JS
Solid Cable/Cache/Queue — database-backed infrastructure, no Redis needed
Built-in authentication generator (new in Rails 8)
Action Mailer, Active Job, Active Storage — batteries included for email, jobs, and file uploads

Pros

Convention over configuration means less decision fatigue
Extremely productive for CRUD applications and MVPs
Mature ecosystem with gems for nearly everything
Rails 8's "no PaaS" philosophy makes self-hosting straightforward
Strong opinions lead to consistent, maintainable codebases

Cons

Ruby's job market has shrunk compared to JS, Python, and PHP. JetBrains' 2025 survey classifies Ruby as a language in "long-term decline"
Ruby has no opt-in type system akin to TypeScript — that's freeing for some developers and frustrating for others
Performance can lag behind Node.js and Go for I/O-heavy workloads
Frontend story (Hotwire) is polarizing — great for some, frustrating for React/Vue developers
Smaller pool of new developers entering the ecosystem

Best For

Startups that value speed-to-market, CRUD-heavy applications, and teams that appreciate strong conventions. Rails remains one of the fastest ways to go from idea to working product if you're comfortable with Ruby.

AI/Vibe Coding Compatibility

Good. Rails' strong conventions make it relatively predictable for AI tools. The "Rails way" means there's usually one correct approach, which helps LLMs generate accurate code. However, like Laravel, the backend (Ruby) and any modern frontend (React via Inertia or API mode) are separate contexts the AI must juggle.

Django (Python)

Python's full-stack framework, now supercharged by the AI/ML ecosystem.

Django 5.2 LTS (released April 2025) is the latest long-term support release, with security fixes guaranteed through April 2028. With roughly 82,000+ GitHub stars, Django has one of the largest open-source communities of any web framework. Its killer advantage in 2026? Python is the language of AI and data science, making Django a natural choice for teams that need web applications tightly integrated with ML pipelines.

Key Features

Django ORM — powerful, Pythonic database layer with migrations
Django Admin — automatic admin interface from your models
Django REST Framework (DRF) — the de facto standard for building APIs
Built-in auth, sessions, CSRF protection — security-first by default
Excellent integration with Python ML/AI libraries — NumPy, pandas, scikit-learn, PyTorch

Pros

Python, the most popular programming language according to the TIOBE Index
Unmatched for applications that combine web + data science/ML
Django Admin alone saves weeks of development time
Battle-tested at scale (Instagram, Pinterest, Mozilla)
LTS releases provide long-term stability — 3 years of security fixes per LTS version, the longest of any framework in this list
Massive community with extensive third-party packages

Cons

Frontend story is the weakest of the five. Django templates are server-rendered, and pairing with React requires a separate SPA + DRF API
Async support is improving but still not as natural as Node.js
"Monolithic" architecture can feel heavy for small projects
Deployment requires more setup than modern deployment platforms

Best For

Data-driven applications, ML-integrated products, and teams already writing Python. If your backend does heavy data processing or integrates with AI models, Django is a natural fit. Also excellent for government, education, and enterprise contexts where Python is standard.

AI/Vibe Coding Compatibility

Very good for backend, weaker for full-stack. Python is the language AI tools understand best, so Django backend code gets excellent AI assistance. But the disconnect between Django's backend and a modern JS frontend means AI tools struggle with the full-stack picture. If you're building a Django + React app, the AI has to work across two very different codebases.

Next.js (React)

The React meta-framework that dominates the JavaScript ecosystem.

Next.js pioneered server-side rendering in the React ecosystem and continues to push boundaries with React Server Components, Server Actions, and a serverless-first deployment model via Vercel. Used by companies like Netflix, TikTok, and Notion, it has over 130,000+ GitHub stars, making it one of the most popular open-source frameworks.

Key Features

App Router — React Server Components, layouts, and streaming
Server Actions — call server functions directly from client components
Turbopack — Rust-based bundler for faster builds
API Routes — build backend endpoints alongside your frontend
Vercel deployment — git push to production in seconds
Image optimization, fonts, metadata — built-in performance features

Pros

Largest ecosystem and community in the JavaScript full-stack space
Vercel provides best-in-class deployment experience
React skills are the most in-demand frontend skills in the job market
Server Components and Server Actions blur the client/server boundary
Excellent TypeScript support
Formal LTS support policy — each major version gets up to 2 years of maintenance
Massive library of examples, templates, and tutorials

Cons

No built-in ORM, database layer, or auth — you need Prisma/Drizzle for DB, NextAuth/Clerk for auth, Resend for email, etc.
Complexity has grown significantly — App Router, Server Components, caching strategies can be overwhelming
Vercel platform coupling — key features like ISR, image optimization, and serverless deployment work best (or only) on Vercel, with no official adapter system for other hosts
Serverless-first billing model can lead to unpredictable costs at scale
"Glue framework" problem — you spend significant time choosing and wiring together third-party solutions
Frequent breaking changes like the migration from Pages to App Router, which effectively required rewriting large portions of existing apps

Best For

Teams building React-first applications who want maximum flexibility. Next.js is the right choice when you need a highly customized frontend with complex UI, and you're comfortable assembling or connecting your own backend stack. It's the only framework in this list that works equally well as a pure frontend layer.

AI/Vibe Coding Compatibility

Mixed. AI tools are excellent at generating React components and Next.js page structures. But because Next.js doesn't prescribe a database, auth, or backend architecture, the AI has to understand whatever custom stack you've assembled and spend a lot more time writing boilerplate and glue code. The complexity of the App Router, Server Components, and caching — plus breaking changes like the Pages to App Router migration — can also make it harder for AI to get things right.

Wasp (React + Node.js + Prisma)

A declarative full-stack JS framework that gives React + Node.js + Prisma the batteries-included treatment.

Wasp (Web Application Specification) takes a different approach within the JavaScript ecosystem. Instead of giving you building blocks and telling you to assemble them, Wasp uses a declarative configuration file that describes your entire application: routes, pages, authentication, database models, server operations, and background jobs. The Wasp compiler then generates a complete React + Node.js + Prisma application. With 18,000+ GitHub stars and a growing community, Wasp is earning attention as the opinionated alternative to the "assemble it yourself" JS ecosystem.

This is our framework. We built Wasp because we felt the JS/TS ecosystem was missing the kind of batteries-included experience that Laravel, Rails, and Django developers have had for years. We think that earns it a spot in this comparison, but we'll let you be the judge.

Key Features

Declarative .wasp or .wasp.ts config — define your entire app — routes, auth, database, jobs — from a high level
Full-stack type safety — types flow from database to UI automatically
Type-safe RPC — call server functions from the client with automatic serialization and type checking, no API layer to write
Built-in auth — email/password, Google, GitHub, etc. with minimal config
Background jobs — declare async jobs in config, implement in Node.js
One-command deployment — wasp deploy to Railway, Fly.io or other providers
Open SaaS — production-ready SaaS starter with 13,000+ GitHub stars

Pros

Dramatically less boilerplate than assembling Next.js + Prisma + NextAuth + etc. — which means a faster start and less maintenance later
Wasp's config acts as a high-level map of your app that both you and AI coding tools can read to quickly understand the full picture
Full-stack type safety without manual setup
Built on React, Node.js, and Prisma — widely adopted, marketable technologies
Simple by default, powerful when needed — common features work out of the box, but you can always drop into the underlying React, Node.js, and Prisma code for full flexibility
No deployment lock-in — build artifacts are standard Node.js and React, deployable anywhere
Helpful community with very active maintainers (according to the feedback of our users!)

Cons

Newer technology, which means faster changes and a still-growing ecosystem
Not yet battle-tested at enterprise scale
Currently only focused on the React + Node.js + Prisma stack
No serverless deployment support (yet)

Best For

Solo developers, indie hackers, and startup teams who want a batteries-included full-stack experience in JavaScript/TypeScript. Also a strong fit for small-to-medium teams building SaaS products and enterprises building internal tools — anywhere speed-to-ship and low boilerplate matter more than maximum customization.

AI/Vibe Coding Compatibility

Excellent. The Wasp configuration gives AI an instant, high-level understanding of your entire application, including its routes, authentication methods, server operations, and more. The well-defined stack and clear structure allow AI to focus on your app's business logic while Wasp handles the glue and boilerplate. And because complexity is hidden until you need it, there's simply less for AI to get wrong, making it easier to generate coherent code across the entire stack.

Built-in Features: What You Get Out of the Box

One of the biggest differences between frameworks is how much they give you versus how much you assemble yourself. Here's a detailed comparison of key features across all five frameworks.

Authentication

Framework	Built-in Solution	Setup Effort
Wasp	Declarative auth in config — ~10 lines for email + social auth	Minimal — declare it, done
Laravel	New starter kits with email auth and optional WorkOS AuthKit for social auth, passkeys, SSO	Low — one CLI command scaffolds views, controllers, routes
Rails	Built-in auth generator (Rails 8+). `rails generate authentication`	Low — generates migration, model, controller, views
Django	`django.contrib.auth` built into every project. Login/logout views, permissions, groups	Low — included by default, add URLs and templates
Next.js	None built-in. Use NextAuth.js/Auth.js (~50-100 lines config + route handler + middleware + provider setup) or Clerk (hosted, paid)	Moderate-High — install package, configure providers, add middleware, handle sessions

Where the established frameworks win: Laravel, Rails, and Django have had over a decade to refine their auth systems. They handle edge cases (password resets, email verification, rate limiting, 2FA) that newer solutions are still maturing on. Django's permission system and Laravel's team management are particularly sophisticated. That said, Wasp stands out for how little code is needed to get auth working: a few lines of config vs. generated scaffolding in the other frameworks.

Background Jobs / Async Tasks

Framework	Built-in Solution	External Dependencies
Laravel	Laravel Queues — first-party, supports Redis, SQS, database drivers. Horizon for monitoring	None required (database driver works out of the box)
Rails	Active Job — built-in abstraction. Solid Queue (Rails 8) eliminates Redis. Sidekiq for heavy workloads	None with Solid Queue; Sidekiq needs Redis
Django	None built-in. Celery is the de facto standard (~50-100 lines setup, needs broker like Redis/RabbitMQ)	Celery + message broker
Wasp	Declare `job` in `.wasp` config (~5 lines), implement handler in Node.js	None — uses pg-boss under-the-hood (PostgreSQL-backed)
Next.js	None built-in. Need Inngest, Trigger.dev, or BullMQ + separate worker process	Third-party service or self-hosted worker

Where Laravel, Rails, and Wasp dominate: Laravel Queues and Rails' Active Job / Solid Queue are the gold standard for background processing. They support job chaining, rate limiting, retry logic, priority queues, and monitoring dashboards (Horizon, Solid Queue's admin). Wasp's job system is simpler to declare but less feature-rich for complex workflows.

Routing

Framework	Approach
Next.js	File-based routing — create a file at `app/dashboard/page.tsx` and the route exists. Intuitive but can get messy with complex layouts
Laravel	`routes/web.php` — expressive, resourceful routing. `Route::resource('photos', PhotoController::class)` gives you 7 CRUD routes in one line
Rails	`config/routes.rb` — similar to Laravel. `resources :photos` generates RESTful routes. Mature, powerful DSL
Django	`urlpatterns` in `urls.py` — explicit URL-to-view mapping. Flexible but more verbose than Rails/Laravel
Wasp	Declare `route` + `page` in `.wasp` config — routes are paired with pages and get type-safe linking. Simpler but less flexible than Rails/Laravel

Honest take: Routing is largely a solved problem. Rails and Laravel have the most powerful routing DSLs. Next.js file-based routing is the most intuitive for simple apps. Wasp's routing is the most concise but also the least flexible for complex URL patterns.

Full-Stack Type Safety

Framework	Type Safety Story
Wasp	Automatic — types flow from Prisma schema through server operations to React components. No manual setup needed
Next.js	Possible with tRPC or Server Actions, but requires manual configuration. Server Actions provide some type flow but aren't end-to-end
Laravel	Limited — PHP has types, but no automatic flow to JS frontend. Inertia.js provides some type sharing with TypeScript
Rails	Minimal — Ruby is dynamically typed. Sorbet exists but isn't standard
Django	Limited — Python has type hints, but no automatic flow to JS frontend

Wasp's genuine advantage: This is one area where Wasp clearly leads. Having types flow automatically from your database schema to your UI components, with zero configuration, eliminates an entire class of bugs. In other frameworks, achieving this requires significant setup (tRPC in Next.js) or isn't practically possible (Rails, Django).

Head-to-Head Comparison

Feature	Laravel	Ruby on Rails	Django	Next.js	Wasp
Language	PHP	Ruby	Python	JavaScript/TypeScript	JavaScript/TypeScript
GitHub Stars	83K+	56K+	82K+	130K+	18K+
ORM	Eloquent	Active Record	Django ORM	BYO (Prisma/Drizzle)	Prisma (integrated)
Auth	Starter kits + WorkOS AuthKit integration	Generator (Rails 8)	django.contrib.auth	BYO (NextAuth/Clerk)	Declarative config
Background Jobs	Queues + Horizon	Active Job + Solid Queue	(Celery)	BYO (Inngest/Trigger.dev)	Declarative config
Modern React Frontend	Via Inertia.js	Via Hotwire/API	Via separate SPA	Native React	Native React
Full-Stack Type Safety	Limited	Minimal	Limited	Manual (tRPC)	Automatic
Easy Deployment	Forge/Vapor	Kamal 2	Manual/PaaS	Vercel (one-click)	CLI deploy to Railway, Fly.io, or any VPS
AI-Friendliness	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐⭐
Learning Curve	Moderate	Moderate	Moderate	Steep (App Router)	Low-Moderate
Job Market	Large (PHP)	Shrinking	Large (Python)	Very Large (React)	Indirectly Very Large (Wasp is React/Node.js/Prisma)
Maturity / Enterprise Readiness	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐

Frequently Asked Questions

When should I choose Laravel vs Next.js vs Wasp?

Choose Laravel if you or your team knows PHP, you need a battle-tested solution for a complex business application, and you want a massive ecosystem with answers for every problem. Choose Next.js if you're designing a marketing page and SEO is very important, or if you need a highly custom React frontend with maximum flexibility and you're comfortable assembling your own backend stack. Choose Wasp if you want a batteries-included JS/TS full-stack experience without the assembly tax for building and shipping fast.

What's the best framework for solo developers?

It depends on your language. Wasp is excellent for JS/TS solo developers. The declarative config eliminates decision fatigue and AI tools work particularly well with it. Rails has been the solo developer's best friend for two decades and is still incredibly productive. Laravel is similarly productive if you know PHP. The common thread: pick a framework with strong opinions so you spend time building, not configuring.

Which framework is best for vibe coding / AI-assisted development?

Wasp's configuration makes it the best choice as it gives AI a boilerplate-free, high-level understanding of the entire app, and allows it to focus on building your app's business logic while Wasp handles the glue. But Django also performs well because Python is the language AI tools understand most deeply, and Laravel/Rails benefit from their strong conventions that reduce ambiguity.

Is Wasp production-ready?

Yes, with caveats. Wasp is rapidly approaching a 1.0 release (currently in beta), which means API changes can occur between versions. However, real companies and indie hackers are running production applications built with Wasp. For enterprise-scale applications with complex requirements, you may want to wait for 1.0 or choose a more established framework. For startups, MVPs, and SaaS products, Wasp is production-viable.

What's the best framework for a startup MVP?

For a JavaScript/TypeScript startup: Wasp gets you to a deployed MVP fast, especially with the Open SaaS template. For a Python team: Django with Django REST Framework. For a PHP team: Laravel. For speed-to-market in Ruby: Rails. The common thread is choosing a framework that makes decisions for you so you can focus on your product.

Which framework has the best job market?

Next.js / React dominates the JavaScript job market. Django / Python leads in data science, AI/ML, and many enterprise contexts. Laravel / PHP remains strong for agencies, e-commerce, and WordPress-adjacent work. Rails has a loyal but shrinking job market. Wasp is too new for a meaningful job market of its own, but Wasp skills are really React + Node.js + Prisma skills — all highly marketable individually.

Can I use Next.js as a true full-stack framework?

You can, but it requires significant assembly. Next.js provides the client and server layers, but you'll need to add your own ORM, authentication, email service, background jobs, and more. This gives you maximum flexibility but also maximum setup time. If you want a batteries-included JavaScript full-stack experience, Wasp is a better fit. If you want a customizable React-first framework and don't mind the assembly, Next.js remains the industry standard.

Conclusion: Which Framework Should You Choose?

There's no single "best" framework but there is a best framework for you:

If you are...	Choose...	Why
An enterprise team with complex requirements	Laravel or Django	Battle-tested, massive ecosystems, proven at scale
A startup prioritizing speed-to-market	Rails or Wasp	Maximum productivity, minimum boilerplate
Building a data/ML-heavy product	Django	Python ecosystem integration is unmatched
A JS/TS developer who wants batteries included	Wasp	The Laravel/Rails experience for the JavaScript ecosystem
Need maximum frontend flexibility	Next.js	React ecosystem, Vercel deployment, custom everything
Optimizing for job market value	Next.js or Django	Largest demand for React and Python skills
Prioritizing AI-assisted development (vibe coding)	Wasp	Config-as-architecture, low boilerplate, batteries-included

Claude Code for Fullstack Development: The 3 Things You Actually Need

vincanger — Fri, 13 Feb 2026 13:00:00 +0000

How Can I Use Claude Code Effectively?

There's a lot of hype around vibe coding with Claude Code.

The good news is that it's warranted. Claude Code can take care of some surprisingly complex coding tasks.

The bad news is that it's over-hyped, with claims of amazing apps being vibe coded in a couple hours, or complex workflows that use 10 parallel sub-agents running in a loop to replace the work of 5 software engineers.

If you're not already a Claude Code power user, all this hype can leave you questioning how to use it effectively. Am I missing out on productivity gains by not adopting this insane new workflow? Should I be using subagents, commands, skills, or MCP servers for my use case? If so, how?

I was asking myself these exact questions, so I did a good few weeks of research and testing, and reached the following conclusion:

With just a few well-picked tools, and Claude Code's basic features, you have enough to "vibe code" great full-stack apps.

You Don't Need All its Features

Weird seeing all these complex LLM workflows and tools. Meanwhile I run one continuous Claude convo per project... I've never used a subagent. Never used MCP…
And I have wildly good results ¯_(ツ)_/¯

— Chris McCord, creator of the Phoenix framework

While Claude Code's abilities are impressive, you quickly realize that there is a lot of feature overlap and stuff you just generally won't have to touch often if you get a few things right from the start. I'll explain what these are, and then go into more detail on each topic within this article.

1. Provide it with full-stack debugging visibility

This allows Claude to actually see and respond to what it's coding, rather than us having to copy-paste errors, or describe issues.

2. Give Claude Code access to up-to-date, LLM-friendly documentation

This is crucial when working with LLMs that may have outdated knowledge, hallucinate solutions, or get thrown off by "noisy" documentation that's not optimized for LLMs.

3. Use the right tech stack or framework

This is probably the most overlooked of these three approaches. By picking the right framework, you give AI clear patterns to follow, and remove a lot of complexity right from the start.

With this foundation, you'll be able to build and deploy fullstack apps easily by mostly using Claude Code's default workflows, and just a couple custom commands/skills (I also packed these ideas into a simple Claude Code plugin you can install and use, but I'll talk more about that later).

This approach works because it provides guardrails and the right patterns for the agent to follow, so you can spend more time on business logic implementation, and less time working out specifications and technical details.

Essentially, you get to work with the agent on what you want, rather than having to explain how you want it, bringing that magic feeling of AI-assisted coding to complex, full-stack apps.

Let's dive in.

Giving Claude Code Full-Stack Vision

Establishing a Tight Feedback Loop

Our typical AI-assisted coding workflow tends to look like this: we prompt, then wait, then look over the generated code (maybe), then check on things in the browser. If we've got some errors or some bad looking frontend designs, we copy and paste them and try to (better) explain what we want.

What's worse is we might have to do this a few times before we're satisfied, or get things working again.

By always keeping ourselves in the loop, we're slowing things down a lot. We should, at times, just get out of the way and let the agent improve the code with each iteration until its done, before checking the result.

But to do this, we need to give Claude Code a "set of eyes". Luckily, this is possible with the right features and tools, allowing it to see the results of the code it wrote, and quickly modify it autonomously if it encounters an error anywhere in the stack.

Let's check out how.

Running the Dev Server as a Background Task

Claude Code introduced their background tasks feature which lets it execute long-running tasks, like app development servers (e.g. npm run dev), on the side without blocking Claude's progress on other work. The nice part is that Claude can continue to read and respond to the output of this task while you work.

To run commands in the background, you can either:

Prompt Claude Code to run a command in the background, e.g. "run my app's dev server in the background"
Press Ctrl+B to move a regular Bash tool invocation to the background, e.g. "run the dev server" + Ctrl+b as it starts

Even though Claude can read the output of your background tasks, there are times you may want to check up on them yourself, and you still can do that. Just use the down arrow to highlight the background task message and click enter.

This is great because now Claude can react to issues that occur from building and serving your code. Unfortunately, it still can't react to errors that occur while your app is running in the browser.

But there's a cool way to solve this.

Browser Automation Tools

The missing piece so far is giving Claude the ability to actually see the result of the code it wrote, most typically what the UI looks like.

Problems that only show up after the app is running in the browser, like design issues and runtime errors, aren't yet visible to the agent. So this tends to be where the human steps in to report back to: "the button is misaligned", "there's a 404 error when trying to login", "the console says something about undefined".

But luckily, we can arm Claude Code with browser automation tools to solve for this. These tools allow for programmatic control of the browser, like loading pages, clicking buttons, inspecting elements, reading console logs, and even taking screenshots.

This closes the loop for the entire stack and gives Claude the autonomy to complete larger features tasks entirely on its own.

Chrome DevTools MCP server is one of the best options currently out there, though there are many alternatives. It's easy to install, and specializes in browser debugging and performance insights.

To install it, run the following command in the terminal to add it to your current project:

claude mcp add chrome-devtools --scope project npx chrome-devtools-mcp@latest

Then start a new Claude session and give it a prompt like:

Verify in the browser that your change works as expected.

You should see a separate Chrome instance open up being controlled by Claude. Go ahead and give it more tasks like:

authenticating a test user
checking the lighthouse performance score of a site (e.g. how fast it loads)
giving you feedback on how to improve your app's design

Tying it All Together

Now, when you're implementing full-stack features in your app, ask Claude to verify the feature works correctly by checking the logs in the development server, as well as in the browser with the Chrome DevTools MCP.

Alternatively, if you want Claude to always automatically verify changes in the browser with the DevTools MCP without having to explicitly ask it to do so, you can add a rule to Claude's memory in your CLAUDE.md file.

Give the Agent Access to the Right Docs

The Versioning Problem

You've probably experienced this: you're vibe coding using a library's API, and the AI confidently writes code that would have worked perfectly… two versions ago. Or it creates some crazy, over-engineered work-around to a known issue that has a simple solution in its documentation.

This is because the model's training data has a cut-off date. LLMs and tools like Claude have no way of knowing about the updated code patterns, unless you give it access to the current documentation.

But, as Andrej Karpathy observed, most documentation contains content that's not relevant for LLMs:

99% of libraries still have docs that basically render to some pretty .html static pages assuming a human will click through them. In 2025 the docs should be a your_project.md text file that is intended to go into the context window of an LLM.

There's research to back up his claim, showing that LLM performance degrades when irrelevant content, like HTML syntax or verbose instructions for humans, is added to context as it distracts from the task and reduces accuracy.

In other words, every unnecessary token in your context window makes the AI slightly worse at its job.

So we need to be giving Claude Code the right kind of docs.

The Solution: Curated Doc Access

The fix is simple: give the agent the ability to fetch and read the relevant, LLM-optimized documentation for the tools you're using.

Here are the two main ways developers are accomplishing this:

MCP Servers — A standard for external systems to serve data to AI agents. Popular dev tools, such as Vercel, make these available with doc searching tools.
llms.txt and doc maps — A standard for publishing LLM-friendly documentation at a well-known URL, e.g. https://wasp.sh/llms.txt. The agent fetches structured docs optimized for LLM context windows.

MCP Servers for Docs Fetching

The Model Context Protocol (MCP) is an open standard for connecting AI applications (i.e. agents, LLMs) to external systems. Claude Code can communicate with an MCP server to access specialized tools and information.

There are already tons of MCP servers for popular tools, like Supabase, Jira, Canva, Notion, and Vercel. Claude Code has a docs section listing these and many more, with instructions on how to install them if you’re interested.

Developer Tool MCP servers like Supabase and Vercel have tools which will fetch documentation for the agent based on a query. There are some pros and cons to this approach, though.

Pros

can do some pre-processing on the docs before sending them back
can version-check, filter, and fetch relevant snippets across multiple docs/guides
return structured outputs instead of raw text

Cons

the MCP server decides what is relevant, ignoring potentially useful information
all of its tools (not just doc fetching tools) get loaded into, and quickly fill up, the LLM’s context window, degrading the agent’s performance
more overhead for the agent: evaluate prompt → find the right MCP tool → call it → wait for response from MCP server → evaluate response → take action

Because LLMs don’t have a real memory, they have to load information into context with every new session, such as the tools they can use. A single MCP server can add around 15-30 tools to the context, and with multiple servers you can easily consume 10-20% or more of your LLM’s context window before you even begin working.

If you want to see how much of your context window is already used up, you can run the /context slash command in an active Claude Code session.
The example above shows that 2.5% of the context window is used up by just one MCP server.

And as an LLM’s context window fills up, it’s performance degrades. Some devs even suggest starting a new session once the context is 75% full to avoid this, which is possible with the /clear command in Claude Code. You can also run the /compact command which creates a summary of your current session’s context and passes it along to the next session.

Luckily, if your main reason for using an MCP server is just for documentation searching, then an alternative open standard exists that may be a better fit.

LLM-friendly Docs URLs — LLMs.txt

LLMs.txt has quickly become the standard for providing LLMs with context-friendly versions of websites at an /llms.txt path.

Try it out on some of your favorite developer tools URLs, such as:

Although llms.txt files might vary widely in the content they surface, they always follow the same format of a simple markdown file with the title of the website and some links. That’s it! This allows LLMs to get precise information without all the fluff.

Here are some of the pros and cons of using llms.txt for documentation fetching:

Pros

curated list of the most relevant information for LLMs and agents
extremely simple; works with any agent that can fetch URLs
agents decide which links to follow and can see full source text
very context window efficient

Cons

raw docs / markdown files may transmit more information than needed
the agent could fetch incompatible links / files
the agent might need more guidance / rules on how to interact with the docs correctly

In my opinion, I think that fetching docs via an llms.txt URL is the better approach as its more context efficient. For example, a typical documentation file is ~100 tokens versus 5,000-10,000 tokens for just one MCP server.

That’s a 10x reduction in context usage.

Claude Code is also great at navigating documentation maps to only fetch the most relevant information. Plus, you get the added benefit that llms.txt files are easier for humans to reference as well.

It's also the method that Claude Code uses for its own doc fetching internally. So when you ask it a question about its own features, it will first fetch its documentation map markdown file URL to find the correct guides.

So now that you know how to give Claude Code access to up-to-date documenation, the next question to answer is which tools might you need to provide the docs for?

And the most obvious answer is the tech stack or framework you’re building your full-stack app with.

Choosing the Right Tech Stack / Framework

Popular Choices

This is probably the most overlooked of the 3 pillars.

Starting with a tech stack that AI can easily reason about will make the job of building the app you want significantly easier. There are a lot of options out there, but luckily there are many solid choices, such as:

Wasp (React, NodeJS, Prisma)
NextJS (React, NodeJS)
Laravel (PHP)
Ruby on Rails (Rails)

In 2026, you'll be able to get very far with Claude Code and any of the frameworks listed above. But while these frameworks all offer good conventions, and are responsible for stitching together the most important parts of the stack, most of these still require some sort of additional integration.

Which one should you go with?

For NextJS, which is more client-side focused, you have to chose and connect your own database layer. For Laravel and Rails, which unify backend and database, you need to decide which client to use and how it will talk to your backend.

That's why a lot of developers will reach for popular stacks/combos that include these frameworks, such as:

NextJS + tRPC + Prisma + NextAuth (aka T3 Stack)
Laravel + Inertia.js + React
Rails + Hotwire

You might have noticed as well that the T3 Stack is the only one to include an authentication library, NextAuth. That's because the backend-focused frameworks, Laravel and Rails, have an opinionated way of adding authentication to your app already, but NextJS does not.

Wasp, on the other hand, is the only one of the bunch that unifies all parts of the stack — client ↔ backend ↔ database — while also being opinionated on features.

This is all great, but which one should you ultimately choose?

The More Opinionated, The Better

Well, the more opinionated the framework, the better it vibes with AI.

If a framework is opinionated, it means there's usually one obvious place to put code and one common pattern to follow. The AI doesn't have to guess. They've already made decisions ahead of time so you (and your agent) don't have to. They've encoded architectural wisdom into conventions, picked the libraries to use, the way authentication is wired, and how the app should be structured.

So when there are fewer decisions to make, less boilerplate to write, and fewer tools to stitch together, the development process becomes more reliable.

And as the app gets more complex, AI doesn't lose its focus, because the framework is handling a lot of underlying complexity. You can also understand and inspect what is being generated more easily, and avoid building yourself into a messy corner.

Consider that opinionated frameworks can reduce boilerplate by 60-80%. Wasp's auth declaration, for example, replaces 500+ lines of typical authentication code with a 10 to 15-line config. That's 97% less code that needs to be generated and audited!

Of these frameworks, Wasp is definitely the most opinionated but it's also the newest kid on the block. After that, Laravel and Rails are probably tied for a close second, but they are built on PHP and Rails, respectively, and come with their own distinct ecosystems, so you'll most likely have to pair them with a frontend JavaScript framework like React, too. NextJS, is the most popular but least opinionated of the bunch, so it means there is more complexity and up-front choices you and your AI have to deal with, but this offers more flexibility in the long run.

So in the end, the choice you make largely depends on what you're trying to achieve, what you're comfortable with, and how much flexibility you need.

Just remember, the more a framework gives you structure and defaults, the easier it is for AI to generate code that fits correctly — and the less time you spend fixing confusing or inconsistent output.

What This Means for Claude Code

Ok. So we've established that working with an opinionated framework means that it it manages a lot of the complexity for you.

But what does that practically mean when using it with Claude Code?

Subagents for architecture planning? The framework already decided the architecture.
Elaborate plans for where code should live? The conventions tell you.
Back-and-forth to agree on patterns? The patterns are already decided.
Glueing the pieces of your app together? The frameworks manage this code.
Context that explains your app structure? It's embedded in the framework.

In a sense, the framework acts as a large specification that both you and Claude already understand and agree on.

Instead of multi-turn conversations to figure out HOW things should be built, you get to just say WHAT you want built.

So when you tell Claude "add a new model for Comments" or "add a user account settings feature", Claude will know exactly what that means and where it all goes. And you also get the added benefit that the implementations follow best practices and are backed by the decisions of experienced professionals behind the framework, and is not just some LLM hastily implementing a feature on the wrong assumptions.

This isn't to say that you no longer have to do good planning, create a good spec, or Product Requirement Doc for your agent to follow. This can still be a really important step when vibe coding (or practicing "spec-driven development").

But it does mean that, with an opinionated full-stack framework, much less of your planning phases need to be devoted to discussing architectural and technical implementation details.

This Approach, In a Plugin

If you want to put this theoretical approach I discussed above to the practical test, then I suggest you try out the Wasp plugin we created for Claude Code.

We, the Wasp framework creators, maintain the plugin, so we've battle tested it with Wasp. Plus we're a very responsive community and we're listening to feedback and improving it all the time.

Here's how to get started:

Install Wasp

npm i -g @wasp.sh/wasp-cli

Install the Claude Code plugin

# add the Wasp marketplace to Claude
claude plugin marketplace add wasp-lang/wasp-agent-plugins

# install the plugin from the marketplace
claude plugin install wasp@wasp-agent-plugins --scope project

Start a new Wasp project

# create a new project
wasp new

# change into the project root directory
cd <your-wasp-project>

Start a Claude Code session in your Wasp project directory

claude

Run the init command to set up the plugin

/wasp-plugin-init

From there, you can tell Claude to "start the dev server" and it will walk you through spinning up fullstack visibility as we outlined above. Or ask it to implement a Wasp feature and watch it fetch version-matched documentation guides for you!

More importantly, Wasp as a framework pushes into territory that's even more AI-native than the rest, because of its central configuration file(s) where the app is defined.

This main config file is like your app's blueprint. Wasp takes these declarations, and manages the code for those features for you.

Take this example config file authentication snippet as reference:

app TaskManager {
  wasp: { version: "^0.21.0" },
  title: "Task Manager",
  auth: {
    userEntity: User,
    methods: {
      email: {},
      google: {}
    },
    onAuthFailedRedirectTo: "/login"
  }
}

This is what an authentication implementation in Wasp looks like. That's it.

This 8-line config generates what would typically require 500-800 lines of code: components, session handling, password hashing, OAuth flows, and database schemas. Claude just needs to know what auth methods you want.

Claude doesn't need to worry about choosing what kind of auth implementation to use, or generating any of the glue code. It can just get straight to work building features.

When You DO Need the Fancy Stuff

I've spent this whole article arguing that you can ignore a lot Claude Code features for fullstack app development. But I don't want to leave you with the impression that those features are useless.

Custom subagents, commands, and skills shine when you're doing the same task repeatedly with consistent criteria, e.g.:

Testing — A dedicated test-runner subagent that knows your testing patterns, runs suites, analyzes failures, and suggests fixes.
Code Reviews — A code review command or subagent that runs tests, fixes bugs, and reviews code after every development.
Running Scripts — Skills can be useful if you have deterministic tasks you run often, like a deployment script or using a cli tool to convert your blog images to webp. Define them in a Skill and link those scripts to them, and Claude Code will run them when it deems it fit for the task at hand.

These are tasks where you want the same process followed every time and where a well-configured subagent with specific rules makes sense.

In most cases, reach for complexity only when the simpler approach stops working.

Now Build!

With these three ingredients I think most fullstack app developers can get the vast majority of the work done without reaching for much more:

An opinionated framework that handles architecture/boilerplate so Claude doesn't have to
Version-matched documentation so Claude has up-to-date implementation details
Full-stack visibility so Claude can see what's happening and fix it on its own

With these in place, Claude Code's basic toolset—exploring, planning, reading, writing, running commands—is enough to build real, complex fullstack applications. The subagents, hooks, plugins, and complex configurations are there if you need them, but honestly most of the time, you won't.

Turn Claude Code into a Fullstack web app expert 🔌

vincanger — Tue, 23 Dec 2025 14:58:03 +0000

Get Even More Out of Claude Code with the Wasp Plugin

Batteries-included frameworks are a great match for AI-assisted coding tools like Claude Code. The frameworks themselves are opinionated and already take care of a lot of routine tasks and boilerplate, which makes the AI's output more deterministic and predictable.

In effect, frameworks like Wasp take care of a lot of grunt work for you and your AI assistants, shifting the focus to the more complex and creative parts of your app.

And now with Claude Code's plugin system, which bundles skills, commands, hooks, and rules, you can make sure that Claude Code has expert knowledge of Wasp.

But configuring, testing, and maintaining all these Claude Code features for your specific projects can be a lot of work. Almost as much as just writing the code yourself (ironic, isn't it?)!

Luckily for you, the the Wasp Team has created the Wasp Claude Code plugin, curated with the help of community and their own experience, that ensures you are getting the most out of Claude Code.

Turn Claude into a Wasp Expert

Claude Code knows it can’t do everything perfectly, which is why it allows for user-defined commands, skills, hooks, and rules, which act as sources of knowledge and guardrails when working in your project.

We’ve done the tedious work for you, and bundled a bunch of the essentials into the Claude Code plugin for Wasp.

Here’s how you can try it once you’ve got Wasp and Claude Code installed:

Add the Wasp x Claude Code Plugin Marketplace:

claude plugin marketplace add wasp-lang/claude-plugins

Install the plugin:

claude plugin install wasp@wasp-plugins --scope project

Once installed, initialize the plugin in a Claude Code session and follow the instructions:

/wasp:init

With the plugin installed, Claude turns into a true Wasp expert by:

Using the right documentation — Automatically fetches the correct Wasp docs for your project's version during development and debugging
Avoiding common mistakes — Provides Wasp-specific tips, patterns, and best practices so Claude doesn't hallucinate or use outdated approaches
Guided workflows — Skills and commands so Claude can walk you through setting up Wasp's batteries-included features: auth, email, database, deploying, etc.
Full debugging visibility — Start managed databases, dev servers, and connect browser console access so Claude has full development and debugging visibility across the entire stack

The result: Claude actually understands Wasp instead of guessing and can get the most out of Wasp features to help you spend less time managing boilerplate or debugging errors, and more time building and shipping app features.

Give Claude the Wheel, Or Let it Be Your Backseat Driver

One of the most important features of the plugin is that it gives Claude everything it needs to get your Wasp app setup and running locally, with full visibility into what’s going on with your app.

For example, Claude can use the Plugin’s skills to easily setup, run and monitor Wasp’s:

managed Postgres DB server,
local development servers, and
a Chrome instance

By leveraging these Wasp features, you give Claude instant access to logs across the entire stack and can drastically reduce development and debugging feedback loops.

On top of that, we’ve added hooks to ensure Claude checks your project’s Wasp version and always pulls the correct LLM-friendly docs before performing important Wasp-related tasks.

Here are some examples of things you can ask Claude to help with:

"Add Google authentication to my app"
"Migrate the database from SQLite to PostgreSQL and start it for me”
"Deploy my app to Railway for me”
"Help me add ShadCN UI to my app to build a dashboard"
"Start a new SaaS app using Wasp's SaaS starter template"
"Why isn't my recurring job working?"

With the Wasp plugin, Claude Code will know exactly how to take care of these tasks in your Wasp app, and can take full control of implementation, or guide you through the process.

We’ve also loaded the plugin with straight-forward slash commands, such as /wasp:help so that you can always quickly reference what the plugin can do.

What’s Next

The focus for the first iteration of the plugin was to give Claude good fundamentals Wasp knowledge.

For the future, we’ll expand it with better guardrails and more skills and workflows to really speed up development. We’ll also be adding a separate plugin for Open SaaS, our open-source SaaS starter built on Wasp, to get you shipping SaaS apps easier and quicker.

And if you have any feedback or ideas on how to improve the plugin, let us know.

🎨 Join Wasp Design-AI-Thon - Pimp our website and win TRMNL, Playdate, and OB-4! 🤖

Matija Sosic — Mon, 13 Oct 2025 13:39:38 +0000

As promised at the start of this Launch Week, we're bringing our hackathon back! And this time, it's a bit special - we're asking you to give a revamp to Wasp's website! Our design is kinda dated and looks like it was done by a backend engineer (looking at myself), and we think it's about time we did something about it!

We want to come up with something fun and not what you see every day, which reflects our style and personality.

The only rule is: there are no rules!

Key things to know

You have 10 days to create a redesigned mock-up of Wasp's website
- Starting 10:00 am PT Friday, Oct 10th, 2025
- The submission deadline is 11:59 pm Sunday, midnight PT, Oct 19th, 2025
Use any tool or format - code, Figma design, drawing. Anything.
You're welcome to adapt the copy on the website. If you have an idea for a tagline you think would work better (e.g., "Laravel for JS"), we'd love to see it!

You can find Wasp's existing website code and use it as a starting point here.

FAQ

Here are answers to some questions you might have. If there is something we haven't covered, ping us on Discord!

What should I create? What level of fidelity should it be?

We leave this part up to you. Whatever you think might be a good way to represent your idea on how to upgrade Wasp's page design and/or branding. It could be a page you actually coded and deployed, a Figma/Illustrator design, a drawing or a video in which you present your vision.

Maybe even a poem. Ok, probably not, but would be interesting to see someone give it a try.

To get your juices flowing, here's an example we played around with internally :

How much of the website should I mock up?

You can go as far as you want. As a minimum, we recommend focusing on the Above-The-Fold aka Hero section of the page. That is the portion of the page you see on your screen when it loads for the first time, before you scroll down.

Which tools should I use? Can I use AI?

Of course! As the title says, it's a design-AI-thon. We believe that AI has made better design more accessible to anyone (even backend engineers, although that's a tough one) and would love to see it in action!

You're of course also free to go old-school and do it Figma/Sketch/Photoshop/Illustrator or any other design tool out there.

Prizes

There are 3 categories, and there will be prizes for:

Best overall project
Most fun / innovative
Most technically impressive

For the prizes themselves, we'll give away three beautifully designed pieces of hardware. We think that is just right for the theme of this competition, and will inspire you to channel your inner Jony Ive or Dieter Rams.

Prize #1: OB-4 Bluetooth Loudspeaker by teenage engineering
Prize #2: TRMNL - E-ink companion for your desk
Prize #3: Playdate - A tiny handheld game system. With The Crank.

Special thanks go to folks at TRMNL for offering to sponsor this event by gifting a device! Seems like me tweeting a lot of stuff eventually pays off!

A lil' disclaimer: If for some reason we can't get our hands on one of the prizes, or can't ship it to your location, we'll swap it out for something just as cool (promise!).

Submission

You should submit your project using the submission form before 11:59 pm PT, Sunday, October 19th, 2025.

Judging

The Wasp team will judge the winners for each category. We will be looking for:

Creativity & thinking out of the box

How well it showcases Wasp’s playful personality
Visually pleasing
Attention to detail
Fun!

Rules

Multiple submissions are allowed. You can do as many as you want.
You must submit before the deadline (no late entries)

Additional info

By making a submission, you grant Wasp permission to use screenshots, code snippets, and/or links to your project on our Twitter, blog, website, email updated, and in the Wasp discord server.

That's - it have fun. Find your inner artist, pair it with AI and let the sparks fly. We can't wait to see what you come up with!

Open SaaS v2.0 -- ShadCN UI, LLM-friendly, MoRs, and more.

vincanger — Tue, 29 Jul 2025 10:23:42 +0000

What could make a free, open-source, full-featured SaaS boilerplate even better? Probably a fresh new look on top the hottest UI library out there, plus a slew of new features.

Well, that's exactly what we've done with Open SaaS v2.0.

Oh, and we're launching it on Product Hunt, so go show your support for open-source SaaS dopeness! 🙏

// Detect dark theme var iframe = document.getElementById('tweet-1950117243246821770-679'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1950117243246821770&theme=dark" }

The most significant change is a complete redesign using Shadcn UI, providing a more modern, consistent, and customizable experience out of the box. This update also includes key framework upgrades, new integrations, and significant codebase improvements to help you build your SaaS faster than ever.

You're welcome.

New Look with Shadcn UI

People really love Open SaaS, but we knew from the start that if there were a way to improve it, than it would be to offer a better look and feel.

So we've done just that.

You probably noticed that the design is cleaner, more consistent, and offers more interactive elements. But it's also completely redesigned on top of Shadcn UI (which is also open source!), so you get a modern, composable, and highly customizable experience out of the box.

On top of that, we've also made the styles easily themable, and in the future we'll be offering a slick way to find and use a great looking theme, as well as a range of different Landing Page templates for you to choose from. So stay tuned for that!

Now on to the new features!

New Features

Lemon Squeezy, Polar, and Paddle Merchants of Record

Merchants of Record (MoR) are great. They're a layer on top of payment processors like Stripe that take the pain out of the legalities and tax compliance of being a merchant.

We've added support for Lemon Squeezy with Polar integration in the works as we speak! Choose the payment processor that best fits your SaaS if Stripe is too granular for your needs.

And while we're working on Polar right now, next up we'll be adding support for Paddle as a MoR to satisfy the needs of the broader international indiehacker community.

LLM-friendly Docs and Rules

One of the best use cases for LLM-assisted coding is to get precise answers to your questions about a codebase or library. You can pass it the docs, ask your questions, and get context-aware answers.

So we've added an LLM-friendly version of the Open SaaS docs, as well as the Wasp framework docs, to make it easier for you to use in your AI coding environments.

Just add the following urls to your AI coding environment such as Cursor, Copilot, etc, and mention it in your prompt to get precise answers to your Open SaaS and Wasp framework questions.

Open SaaS AI-friendly docs:

https://docs.opensaas.sh/llms-full.txt

Wasp framework AI-friendly docs:

https://wasp.sh/llms-full.txt

In addition, we've also got a full set of project-specific Cursor rules files that you can use to make sure your AI assistants stay on the right track. These can be adapted to use with Claude Code, Windsurf, and more.

End-to-End Testing with Playwright

One thing I hate about building a SaaS is that I'm constantly worried it might break after adding a new feature. To give you peace of mind, we've integrated a full suite of end-to-end tests using Playwright. These tests act like a robot user, clicking through your app to verify that everything from user sign-ups to critical payment flows is working exactly as it should.

But we didn't just write tests for ourselves. We've provided the entire setup, including a CI/CD workflow file for GitHub Actions. This means you can automatically run these checks on every code change, ensuring you never accidentally break your production app. Ship with confidence, knowing your core features are easily protected, and use our test suite as a foundation for your own custom test cases.

More Refactors & Improvements

On top of the headlining features, we've been busy shipping a ton of other improvements to make your life easier. We've squashed bugs, upgraded major dependencies like Node.js and the Wasp framework, and completely refactored the codebase for better organization. We also threw in some handy new integrations like enhanced file uploads with progress bars and a cookie consent banner. Here's a quick rundown of other key changes:

New Features & Integrations 🚀:
- Enhanced File Uploads: The file upload functionality has been improved with features like progress bars and validation. The S3 CORS configuration was tightened for improved security.
- Cookie Consent: A cookie consent banner has been implemented.
Major Dependency and Framework Upgrades 🛠️:
- Wasp Framework: There have been multiple upgrades to the Wasp framework, moving from version 0.13.0 up to 0.16.0 and beyond. This indicates active maintenance and adoption of new Wasp features.
- SDKs: The AWS and OpenAI SDKs have been updated to their latest versions.
- Node.js: The environment has been updated to Node.js version 20.
Codebase Refactoring and Organization 🗂️:
- Vertical Reorganization: A major refactoring effort was undertaken to organize the codebase "vertically". Functionality for features like auth, payments, users, and file-upload are now grouped together, improving modularity.
- User Management: Significant refactoring was done on the user management and administration pages.
Documentation and Content 📚:
- A substantial number of commits are related to adding new blog posts, updating documentation, and creating other content. This reflects a strong focus on community engagement and developer resources.

Help Us, Help You!

We're not done yet. We're going to keep listening to our commonunity and improving Open SaaS.

So if you've got ideas on how to improve it, please create a GitHub issue or submit a pull request.

Got a cool landing page variation? Submit a PR!
Found a bug? Create an issue!

Want to support us? Star the repo on GitHub!

From 0 to 10K ⭐: How Open SaaS became the Free Boilerplate Devs Love

vincanger — Tue, 29 Apr 2025 11:51:32 +0000

The Open SaaS Story

When building an app, I want to start on the unique idea that sparked the project in the first place, not spend weeks configuring auth, payments, and user management.

Of course, there are paid 3rd-party solutions for integrating things like authentication, cron jobs, and email sending quickly. And paid SaaS boilerplates exist, too.

But when I looked there was surprisingly no great full-featured, open-source solution for building a SaaS quickly.

So I decided to build one.

And I'm excited to announce that it now has over 10,000 stars on GitHub!

What is Open SaaS?

For those unfamiliar, Open SaaS is a 100% free and open-source, batteries-included SaaS starter kit, built on top of the Wasp full-stack framework (using React, Node.js, and Prisma).

Its mission is simple:

Accelerate and focus your SaaS development by providing an open-source, full-featured foundation with essential features, like:

Authentication (email, google, github, etc.)
Payments (Stripe or Lemon Squeezy integration)
Example Apps w/ the OpenAI API
AWS S3 File Upload
Email sending
Admin dashboard
And more, right out of the box

The best part is that it doesn't rely on a ton of paid 3rd-party services like other templates do, so you own more of your app (oh, and you can deploy it wherever you want, too).

Since its launch, Open SaaS hasn't just gathered stars; it has empowered developers to launch countless projects faster, turning ideas into profitable businesses, sometimes in a matter of days.

It's been crazy to see the apps and businesses people are building with it, like some of these below (yes, all of them were built with Open SaaS 🤩):

SearchCraft.io - powerful search SDK
Prompt Panda - prompt library
Scribeist - SEO-optimized AI writing

Besides all the cool stuff being built with it, an interesting side-effect of Open SaaS is that it has also become the cornerstone of the Wasp ecosystem, demonstrating the framework's power and really delighting developers in the process.

Support us! 🙏⭐️

Everything we do at Wasp is open-source. You can show your support by giving us a star on Github. It helps us make web development easier and motivates us to write more articles like this!

⭐️ Thanks For Your Support 🙏

Under the Hood: The Wasp Advantage

Launched in December 2023, Open SaaS adoption took off almost immediately. The positive reception was surprising, but it confirmed our belief that developers needed a high-quality, open-source SaaS boilerplate starter.

While Open SaaS leverages familiar tools like React, NodeJS, and Prisma, and comes with a bunch of built-in examples like an OpenAI example app, AWS S3 file storage, and more, its secret sauce lies in its core tool choice that glues them all together: the Wasp framework.

Wasp is special because it's the only full-stack framework that actually manages the tedious boilerplate that plagues modern web development.

It does this through its use of a central config file and its compiler, allowing developers (and AI) to define tons of full-stack features in just a few lines of code.

The Central Nervous System: `main.wasp`

Think of the main.wasp config file as the central nervous system of your application. Here, you declaratively define key aspects of your app:

Authentication methods
Database models (via Prisma integration)
Routes and Pages
API endpoints (Queries and Actions)
Background jobs
Email sending
...and more.

This configuration file acts as a single "source of truth" for your app's architecture, a concept highlighted in our post on AI-assisted workflows, and it's how you can get complex web app features really quickly and easily as a developer.

Here's a quick code snippet of what a main.wasp file looks like:

app exampleApp {
  wasp: { version: "^0.16.3" },
  title: "Example App",
  auth: {
    userEntity: User,
    methods: {
      email: {},
      github: {},
    },
  }
}

route LoginRoute { path: "/login", to: Login }
page Login {
  component: import { Login } from "@src/features/auth/login"
}

route EnvelopesRoute { path: "/envelopes", to: EnvelopesPage }
page EnvelopesPage {
  authRequired: true,
  component: import { EnvelopesPage } from "@src/features/envelopes/EnvelopesPage.tsx"
}

query getEnvelopes {
  fn: import { getEnvelopes } from "@src/features/envelopes/operations.ts",
  entities: [Envelope, UserBudgetProfile]
}

action createEnvelope {
  fn: import { createEnvelope } from "@src/features/envelopes/operations.ts",
  entities: [Envelope, UserBudgetProfile] 
}

//...

The Wasp Compiler: Where the Magic Happens

Then, the Wasp compiler takes over. It analyzes your .wasp declarations alongside your custom React and Node.js code (where you write your specific business logic) and intelligently generates the complete underlying code.

This includes:

Setting up the server and database connections.
Wiring up communication between client and server with full type-safety.
Handling complex authentication flows and session management.
Simplifying deployment with commands like wasp deploy.

Using this as the basis for Open SaaS, this translates directly into less code and complexity for essential features.

In other words, you get to focus solely on building your unique product, rather than struggling with putting all the pieces together.

Implementing a new authentication method, adding background jobs, or defining protected routes is as easy as a couple lines of code in the main.wasp file.

This allows Open SaaS apps to be feature-rich yet maintainable and, crucially, easy to understand and extend.

Open SaaS + AI = Vibe Coding Superpowers

This also means that Open SaaS is exceptionally well-suited for AI-assisted development.

Why?

Because the effectiveness of AI-assisted development (or "vibe coding" as some call it) heavily depends on the underlying codebase structure and clarity.

Open SaaS's foundation on Wasp makes it exceptionally well-suited for AI-assisted development for two key reasons:

Clear Architecture through Wasp's Config: The main.wasp file serves as a perfect "source of truth" for AI tools.

When an AI assistant needs to understand your app's structure – its routes, models, operations, and features – everything is clearly laid out in one declarative file.

This makes it significantly easier for AI to comprehend the context and generate accurate, relevant code.

Focus on Business Logic: Since Wasp's compiler handles the underlying infrastructure, both you and your AI assistant can focus purely on implementing your unique features.

No time is wasted having the AI generate or explain boilerplate code for auth flows, API setup, or database connections – Wasp handles all of that.

This means that LLMs have considerably less code to write, and can pass of the complexity of connecting the different parts of the stack to Wasp.

(BTW, If you're curious to see how using Open SaaS with AI-assisted development tools like Cursor looks like, make sure to check out this 3 hour walkthrough tutorial on YouTube)

Using AI tools in a vibe coding workflow like this on top of Open SaaS's robust foundation creates a powerful development environment where you and your LLM buddy only have to focus on the fun stuff – the business logic of your SaaS app.

The Future of Open SaaS

Hitting 10,000 GitHub stars is a milestone, but it's just the beginning. The community and I are actively working on making Open SaaS even more powerful and flexible.

Here's some stuff we have in store for you:

Complete Redesign w/ Shadcn UI: We're working on a complete redesign of the Open SaaS template to make it even more modern and user-friendly by leveraging the power of Shadcn UI.
More Example Apps: Ready-to-use app templates, like ones that leverage AI APIs (because GPT Wrappers are in!).
Enhanced Admin Features: Expanding the admin dashboard with more analytics, role-based authentication, and customization options.

BTW, if you have any feature requests, please let us know by creating an issue or a discussion on GitHub.

Whether you're a React developer looking to contribute new features, a designer interested in improving the UI, or someone who just found a bug, don't be shy!

Ready to Build Your SaaS?

In just a few months, Open SaaS has grown from an idea to one of the most popular SaaS repos on GitHub that's helping developers launch SaaS applications by writing less boilerplate code.

By combining:

A robust, full-featured SaaS starter
The power and simplicity of the Wasp framework
An active, supportive community
AI-friendly architecture for modern development workflows

Open SaaS has become more than just a template.

If you wanna start building your SaaS, all you need to get started is install Wasp and get the Open SaaS template by running:

curl -sSL https://get.wasp.sh/installer.sh | sh
wasp new -t saas

After that, check out the Open SaaS documentation 📚 where everything you need to know is outlined for you, along with step-by-step setup guides!

And don't forget to:

⭐️ Star Open SaaS on GitHub to support the project
⭐️ Star Wasp on GitHub to support the framework
💬 Join the Wasp Discord community to connect with other builders

🐝 Wasp: a full-stack, "Laravel for JS" framework. Vibe-coding approved 🕹️

Matija Sosic — Wed, 23 Apr 2025 12:57:21 +0000

What is Laravel, and why do I need it for JavaScript?

Laravel is one of the most popular web frameworks for PHP. It was released in 2011 and has since become a synonym for a well-designed, enjoyable developer experience. Its "superpower" is that it provides pretty much everything you need with the best practices out of the box. Authentication, ORM, emails, jobs, testing - there is a "Laravel" way to do it, and there's nothing for you to figure out - it all just works!

On the other hand, the JavaScript ecosystem is on the drastically opposite spectrum. There is a standalone library/service for pretty much every web app feature, and it's up to you to figure out the best way to integrate it all together.

It can be fun to hand-select every part of your stack, but it can also be quite frustrating when you have an idea and want to get it out to users as soon as possible.

This is why developers who used all-in-one full-stack frameworks such as Laravel, Rails, and Django have been very strongly calling for the same experience in JavaScript.

There are historical and maturity reasons why we didn't have that in JavaScript for so long, but finally, the times are changing.

There are multiple solutions and frameworks that aim to solve this problem, and today we'll take a look at one of the fastest-growing among them: Wasp! 🐝

Wasp: A full-stack, “Laravel for JS” framework. Great for vibe-coders, too!

Wasp is one of the fastest-growing next-gen full-stack web frameworks and is leading the pack when it comes to pushing for a Laravel-like experience in JavaScript. It appeared at about the same time as Redwood and was motivated by the same pain (too fragmented and modular JS ecosystem). Wasp is currently in Beta (recently went through its Launch Week #9) but is already being used by solopreneurs, startups, and Fortune 500 companies.

The main “secret sauce” is a declarative specification file where a developer describes their app at a high level - pages and routes, async jobs, database operations, and more. It helps cut down a lot of boilerplate and lets a developer focus on their unique logic in React, Node.js, and Prisma.

Support us! 🙏⭐️

If you find this post helpful,consider giving us a star on Github! Everything we do at Wasp is open source, and your support helps us make web development easier and motivates us to write more articles like this one.

⭐️ Thanks For Your Support 🙏

OpenSaaS - a free, open-source boilerplate starter for React & Node.js

Finally, one of the big drivers for developers choosing Wasp for their projects is OpenSaaS - a 100% free and open-source SaaS boilerplate starter on top of Wasp. It comes with a lot of common features out-of-the-box (Stripe & OpenAI integration, blog via Astro, admin dashboard, file uploads, …) and will save you hundreds of development hours. Since its release about a year ago, it has skyrocketed toover 10,000 stars on GitHub, and has been used to bring hundreds of SaaSes to life.

Wasp helps vibe coders build their apps further and safer 🕹️

Recently, Wasp has been gaining a lot of popularity among so-called “vibe coders”, which is just a trendy term for people who want to build their app as fast as possible using AI. It turns out that a Wasp app’s robust structure that spans the whole stack of your app (client, server, database, and deployment) and less boilerplate code helps AI develop more features and make fewer mistakes along the way.

Here you can find a detailed video guide that explains the whole process, step-by-step, on how to build your next app with Wasp and Cursor, and then also deploy it to production.

Happy building and stay safe!

Hopefully, this post gave you an insight into the latest developments of the JavaScript ecosystem and prompted (pun intended) you to start working on your next idea, be it with Wasp or another framework that fits your needs the best.

Also, whether you adopt less or more AI in your development workflow, make sure to check and understand your app’s code before putting it into production. Although full-stack frameworks such as Wasp can help with ensuring best practices out of the box, it’s still your responsibility as a developer to make sure that the code that goes out meets all the security standards.

With that said, happy coding! If you want to support our mission with Wasp, we’d appreciate it if you starred it on GitHub. We’d also love to hear from you, and we’re here if you have any questions about Wasp or web dev in general - you can always find us in our Discord.

A Structured Workflow for "Vibe Coding" Full-Stack Apps

vincanger — Wed, 16 Apr 2025 08:46:36 +0000

There's a lot of hype surrounding "vibe coding". You've probably seen the AI influencers making claims like how you can build SaaS apps in 15 minutes with just a few tools and prompts.

But, as you might have guessed, these example workflows are pretty flimsy.

Yes, you can copy a landing page, or build a decent CRUD app, but you're not gonna be able to build a complex SaaS or internal tool with them.

But that doesn't mean there aren't workflows out there that can positively augment your development workflow. Anyone who's tinkered around with different AI-assisted techniques can tell you that there is some real magic in these tools.

That's why I spent a couple weeks researching the best techniques and workflow tips and put them to the test by building a full-featured, full-stack app with them.

Below, you'll find my honest review and the workflow that I found that really worked while using Cursor with Google's Gemini 2.5 Pro, and a solid UI template.

By the way, I came up with this workflow by testing and building a full-stack personal finance app in my spare time, tweaking and improving the process the entire time. Then, after landing on a good template and workflow, I rebuilt the app again and recorded it entirely, from start to deployments, in a ~3 hour long youtube video (above).

This article is a summary of the key approaches to implementing this workflow.

Step 1: Laying the Foundation

There are a lot of moving parts in modern full-stack web apps. Trying to get your LLM to glue it all together for you cohesively just doesn't work.

That's why you should give your AI helper a helping hand by starting with a solid foundation and leveraging the tools we have at our disposal.

In practical terms this means using stuff like:

UI Component Libraries
Boilerplate templates
Full-stack frameworks with batteries-included

Component libraries and templates are great ways to give the LLM a known foundation to build upon. It also takes the guess work out of styling and helps those styles be consistent as the app grows.

Using a full-stack framework with batteries-included, such as Wasp for JavaScript (React, Node.js, Prisma) or Laravel for PHP, takes the complexity out of piecing the different parts of the stack together. Since these frameworks are opinionated, they've chosen a set of tools that work well together, and the have the added benefit of doing a lot of work under-the-hood. In the end, the AI can focus on just the business logic of the app.

Take Wasp's main config file, for example (see below). All you or the LLM has to do is define your backend operations, and the framework takes care of managing the server setup and configuration for you. On top of that, this config file acts as a central "source of truth" the LLM can always reference to see how the app is defined as it builds new features.

app vibeCodeWasp {
  wasp: { version: "^0.16.3" },
  title: "Vibe Code Workflow",
  auth: {
    userEntity: User,
    methods: {
      email: {},
      google: {},
      github: {},
    },
  },
  client: {
    rootComponent: import Main from "@src/main",
    setupFn: import QuerySetup from "@src/config/querySetup",
  },
}

route LoginRoute { path: "/login", to: Login }
page Login {
  component: import { Login } from "@src/features/auth/login"
}

route EnvelopesRoute { path: "/envelopes", to: EnvelopesPage }
page EnvelopesPage {
  authRequired: true,
  component: import { EnvelopesPage } from "@src/features/envelopes/EnvelopesPage.tsx"
}

query getEnvelopes {
  fn: import { getEnvelopes } from "@src/features/envelopes/operations.ts",
  entities: [Envelope, BudgetProfile, UserBudgetProfile] // Need BudgetProfile to check ownership
}

action createEnvelope {
  fn: import { createEnvelope } from "@src/features/envelopes/operations.ts",
  entities: [Envelope, BudgetProfile, UserBudgetProfile] // Need BudgetProfile to link
}

//...

Step 2: Getting the Most Out of Your AI Assistant

Once you've got a solid foundation to work with, you need create a comprehensive set of rules for your editor and LLM to follow.

To arrive at a solid set of rules you need to:

Start building something
Look out for times when the LLM (repeatedly) doesn't meet your expectations and define rules for them
Constantly ask the LLM to help you improve your workflow

Defining Rules

Different IDE's and coding tools have different naming conventions for the rules you define, but they all function more or less the same way (I used Cursor for this project so I'll be referring to Cursor's conventions here).

Cursor deprecated their .cursorrules config file in favor of a .cursor/rules/ directory with multiple files. In this set of rules, you can pack in general rules that align with your coding style, and project-specific rules (e.g. conventions, operations, auth).

The key here is to provide structured context for the LLM so that it doesn't have to rely on broader knowledge.

What does that mean exactly? It means telling the LLM about the current project and template you'll be building on, what conventions it should use, and how it should deal with common issues (e.g. the examples picture above, which are taken from the tutorial video's accompanying repo.

You can also add general strategies to rules files that you can manually reference in chat windows. For example, I often like telling the LLM to "think about 3 different strategies/approaches, pick the best one, and give your rationale for why you chose it." So I created a rule for it, 7-possible-solutions-thinking.mdc, and I pass it in whenever I want to use it, saving myself from typing the same thing over and over.

Using AI to Critique and Improve Your Workflow

Aside from this, I view the set of rules as a fluid object. As I worked on my apps, I started with a set of rules and iterated on them to get the kind of output I was looking for. This meant adding new rules to deal with common errors the LLM would introduce, or to overcome project-specific issues that didn't meet the general expectations of the LLM.

As I amended these rules, I would also take time to use the LLM as a source of feedback, asking it to critique my current workflow and find ways I could improve it.

This meant passing in my rules files into context, along with other documents like Plans and READMEs, and ask it to look for areas where we could improve them, using the past chat sessions as context as well.

A lot of time this just means asking the LLM something like:

Can you review for breadth and clarity and think of a few ways it could be improved, if necessary. Remember, these documents are to be used as context for AI-assisted coding workflows.

Step 3: Defining the "What" and the "How" (PRD & Plan)

An extremely important step in all this is the initial prompts you use to guide the generation of the Product Requirement Doc (PRD) and the step-by-step actionable plan you create from it.

The PRD is basically just a detailed guideline for how the app should look and behave, and some guidelines for how it should be implemented.

After generating the PRD, we ask the LLM to generate a step-by-step actionable plan that will implement the app in phases using a modified vertical slice method suitable for LLM-assisted development.

The vertical slice implementation is important because it instructs the LLM to develop the app in full-stack "slices" -- from DB to UI -- in increasingly complexity. That might look like developing a super simple version of a full-stack feature in an early phase, and then adding more complexity to that feature in the later phases.

This approach highlights a common recurring theme in this workflow: build a simple, solid foundation and increasing add on complexity in focused chunks

After the initial generation of each of these docs, I will often ask the LLM to review it's own work and look for possible ways to improve the documents based on the project structure and the fact that it will be used for assisted coding. Sometimes it finds seem interesting improvements, or at the very least it finds redundant information it can remove.

Here is an example prompt for generating the step-by-step plan (all example prompts used in the walkthrough video can be found in the accompanying repo):

From this PRD, create an actionable, step-by-step plan using a modified vertical slice implmentation approach that's suitable for LLM-assisted coding. Before you create the plan, think about a few different plan styles that would be suitable for this project and the implmentation style before selecting the best one. Give your reasoning for why you think we should use this plan style. Remember that we will constantly refer to this plan to guide our coding implementation so it should be well structured, concise, and actionable, while still providing enough information to guide the LLM.

Finding this tutorial interesting?

Wasp team is working hard to create content like this, not to mention building a modern, open-source React/NodeJS framework.

The easiest way to show your support is just to star Wasp repo! 🐝 But it would be greatly appreciated if you could take a look at the repository (for contributions, or to simply test the product). Click on the button below to give Wasp a star and show your support!

⭐️ Thank You For Your Support 💪

Step 4: Building End-to-End - Vertical Slices in Action

As mentioned above, the vertical slice approach lends itself well to building with full-stack frameworks because of the heavy-lifting they can do for you and the LLM.

Rather than trying to define all your database models from the start, for example, this approach tackles the simplest form of a full-stack feature individually, and then builds upon them in later phases. This means, in an early phase, we might only define the database models needed for Authentication, then its related server-side functions, and the UI for it like Login forms and pages.

In my Wasp project, that flow for implementing a phase/feature looked a lot like:
-> Define necessary DB entities in schema.prisma for that feature only
-> Define operations in the main.wasp file
-> Write the server operations logic
-> Define pages/routes in the main.wasp file
-> src/features or src/components UI
-> Connect things via Wasp hooks and other library hooks and modules (react-router-dom, recharts, tanstack-table).

This gave me and the LLM a huge advantage in being able to build the app incrementally without getting too bogged down by the amount of complexity.

Once the basis for these features was working smoothly, we could improve the complexity of them, and add on other sub-features, with little to no issues!

The other advantage this had was that, if I realised there was a feature set I wanted to add on later that didn't already exist in the plan, I could ask the LLM to review the plan and find the best time/phase within it to implement it. Sometimes that time was then at the moment, and other times it gave great recommendations for deferring the new feature idea until later. If so, we'd update the plan accordingly.

Step 5: Closing the Loop - AI-Assisted Documentation

Documentation often gets pushed to the back burner. But in an AI-assisted workflow, keeping track of why things were built a certain way and how the current implementation works becomes even more crucial.

The AI doesn't inherently "remember" the context from three phases ago unless you provide it. So we get the LLM to provide it for itself :)

After completing a significant phase or feature slice defined in our Plan, I made it a habit to task the AI with documenting what we just built. I even created a rule file for this task to make it easier.

The process looked something like this:

Gather the key files related to the implemented feature (e.g., relevant sections of main.wasp, schema.prisma, the operations.ts file, UI component files).
Provide the relevant sections of the PRD and the Plan that described the feature.
Reference the rule file with the Doc creation task
Have it review the Doc for breadth and clarity

What's important is to have it focus on the core logic, how the different parts connect (DB -> Server -> Client), and any key decisions made, referencing the specific files where the implementation details can be found.

The AI would then generate a markdown file (or update an existing one) in the ai/docs/ directory, and this is nice for two reasons:

For Humans: It created a clear, human-readable record of the feature for onboarding or future development.
For the AI: It built up a knowledge base within the project that could be fed back into the AI's context in later stages. This helped maintain consistency and reduced the chances of the AI forgetting previous decisions or implementations.

This "closing the loop" step turns documentation from a chore into a clean way of maintaining the workflow's effectiveness.

Conclusion: Believe the Hype... Just not All of It

So, can you "vibe code" a complex SaaS app in just a few hours? Well, kinda, but it will probably be a boring one.

But what you can do is leverage AI to significantly augment your development process, build faster, handle complexity more effectively, and maintain better structure in your full-stack projects.

The "Vibe Coding" workflow I landed on after weeks of testing boils down to these core principles:

Start Strong: Use solid foundations like full-stack frameworks (Wasp) and UI libraries (Shadcn-admin) to reduce boilerplate and constrain the problem space for the AI.
Teach Your AI: Create explicit, detailed rules (.cursor/rules/) to guide the AI on project conventions, specific technologies, and common pitfalls. Don't rely on its general knowledge alone.
Structure the Dialogue: Use shared artifacts like a PRD and a step-by-step Plan (developed collaboratively with the AI) to align intent and break down work.
Slice Vertically: Implement features end-to-end in manageable, incremental slices, adding complexity gradually. Document Continuously: Use the AI to help document features as you build them, maintaining project knowledge for both human and AI collaborators.
Iterate and Refine: Treat the rules, plan, and workflow itself as living documents, using the AI to help critique and improve the process.

Following this structured approach delivered really good results and I was able to implement features in record time. With this workflow I could really build complex apps 20-50x faster than I could before.

The fact that you also have a companion that has a huge knowledge set that helps you refine ideas and test assumptions is amazing as well

Although you can do a lot without ever touching code yourself, it still requires you, the developer, to guide, review, and understand the code. But it is a realistic, effective way to collaborate with AI assistants like Gemini 2.5 Pro in Cursor, moving beyond simple prompts to build full-features apps efficiently.

If you want to see this workflow in action from start to finish, check out the full ~3 hour YouTube walkthrough and template repo. And if you have any other tips I missed, please let me know in the comments :)

Going from an Idea to MVP in Weeks: PromptPanda's Launch(es)

Milica Maksimovic — Tue, 18 Mar 2025 08:54:09 +0000

Did you know that most co-founders meet each other through work? Lander Willem met his friend and co-founder Bram Billiet while they were working at the local venture fund. They both shared the love towards LLMs and got the idea to kickstart their SaaS after experiencing the same pain points with managing and versioning prompts.

In this post, you'll learn how they:

Shipped their SaaS from idea to MVP in weeks, using modern AI stack
Launched and got trending on Product Hunt with 100+ upvotes
Successfully onboarded first users

The problem: Managing prompts is messy

Right after OpenAI released their first LLM models, Lander and Bram started exchanging tips on how to get optimal results from prompts. Soon, they learned that managing AI prompts is often chaotic.

People who share prompts usually do so through messaging apps such as Slack, Microsoft Teams or in better cases, shared Google Docs documents. Some of the people they talked to even confessed they were sharing their favorite prompts using screenshots 😅. Although a Google Doc might work initially, people quickly bump into issues regarding versioning and granular access management.

This is how they got the idea to create PromptPanda - a SaaS that allows people to exchange prompts in an easy way. Here's an interactive demo you can click through to see what they've built.

The opportunity: Everyone uses prompts, not just devs

Other AI prompt tools are primarily designed with developers in mind, which leaves out non-technical teams. Those less technical users depend heavily on collaboration, efficiency, and consistency to complete their tasks. This is the market PromptPanda decided to go after.

The tool is designed specifically to help teams centralize their prompts and ensures consistent output quality. Collaboration is painless because of an intuitive web app that also has a Chrome extension.

PromptPanda integrates with major AI providers such as OpenAI, Anthropic, Google, Perplexity, and DeepSeek. Coupled with its built-in Prompt Improver, these integrations allow users to quickly test, iterate, and enhance their prompts, while not imposing any limitations for the end-users.

With this approach they covered a market that other companies overlooked, non-technical users who rely on the biggest LLM providers for their daily tasks.

Launching is unpredictable: Product Hunt hits and flops

As soon as the app was somewhat stable and usable, Lander and Bram decided to launch on ProductHunt.

Their first ProductHunt launch was great in terms of visibility. They were featured by the ProductHunt team which got them a bunch of upvotes and comments. Although there was quite a lot of engagement with the launch, it didn't really end up in sticky, paying customers.

A short while later they relaunched on ProductHunt after processing the feedback from their first launch. Both their product and launch campaign were much better prepared. Weirdly enough, the launch mostly failed as they got almost no upvotes or conversions.

Although their second launch was mostly a flop, it did manage to get them mentioned in a Superhuman (the email app) newsletter. Their user base doubled overnight.

Ever since then they have an active stream of users and new signups coming in.

”My main takeaway is to never stop shipping, and always share your work!”

Lander Willem

Most of their users today have found PromptPanda through organic SEO. They started writing articles about AI Prompt Management which have quickly found traction in search engine algorithms.

Finding this article interesting?

Wasp team is working hard to create content like this, not to mention building a modern, open-source React/NodeJS framework.

⭐️ Thank You For Your Support 💪

Choosing the right stack for developing your SaaS app

PromptPanda's team chose Open SaaS because it significantly streamlined their product development by simplifying backend setup, database management, and built-in authentication. This was crucial as they needed an efficient solution that could save time due to their busy schedules. Wasp's default integration with Fly also enabled rapid deployment, allowing them to quickly validate their product idea without getting bogged down in infrastructure complexities.

Here's a full overview of their tech stack alongside all the tools they rely on to run their SaaS:

Are you ready to ship your SaaS now?

PromptPanda's story proves the best SaaS ideas come from solving your own pain points. Lander and Bram also learned launching isn't predictable—success can come from unexpected places, even failed launches. The takeaway? Keep building, keep shipping, and always share your progress openly.

If you enjoyed this post please make sure to give Wasp a star on GitHub, this keeps us going forward and supports our work!

From “You will fail” to 15,000 GitHub stars: The story of Wasp, a "Laravel for JS" full-stack framework

Matija Sosic — Wed, 05 Mar 2025 13:03:40 +0000

"What you're building is the holy grail for developers. No one has succeeded so far." 🏆 ☠️

This is the feedback from Y Combinator when Martin (my twin brother) and I applied with Wasp for the second time in May 2020. At that point, we had worked on Wasp for 1.5 years, the last nine months full-time. We had quit our previous jobs and gone all in.

Today, Wasp has over 15,000 stars on GitHub. Even more importantly, developers of all backgrounds have used it to develop thousands of web apps, from side projects that have grown into acquired or revenue-generating businesses to venture-backed startups and internal tools deployed within Fortune 500 companies.

Some people have grown to love Wasp and the vision it pursues. Thanks to them, we enjoy working on it. Without the community that gathered around Wasp (>4,000 devs in our Discord), we wouldn’t have been even close to where we are today. For them, we keep pushing towards the holy grail we promised.

Our work has just begun - but we’re more excited about it than ever.

The journey - getting from 0 to 15,000 stars

As with most success stories, the success rarely happens linearly. It usually starts with a long period of "drought" with occasional signs of life, and then there is a moment when things click together and start moving really fast. We experienced the same, and it looked something like this:

The inception - “Why not?”

In the beginning, Wasp was just an idea—or rather, a question: "Why hasn't anyone built this yet? What would we discover if we tried?" After spending a decade building web apps and using every major tech stack (from PHP to Java and Node.js on the server to Backbone, Angular, and React on the client), we were feeling the pain of "framework fatigue," aka reinventing the wheel with each new stack.

So we set out to start thinking about it and put things on paper (ok, Google Slides). This is how the original idea for Wasp was born - can we create a framework that removes a lot of boilerplate by offering higher-level abstractions, but is still flexible enough and is not strictly bound to the specific stack and architecture?

Now looking that, it really does sound like a holy grail.

Getting in YC and things getting real

We had already quit our jobs a year ago and were quite exhausted and doubtful of the whole concept. We were getting some early traction and received promising feedback from Reddit, Hacker News, and Product Hunt, but we also started realizing how much work is needed to bring a full-stack web framework to a state where it’s usable, especially with the ambitious requirements we set for ourselves.

Finally, we got into YC the third time we applied for it. They were following our progress for the last year and, having seen the community excitement, decided to take a bet on our crazy idea.

Beta and beyond - MAGE and OpenSaaS

Looking at the graph, you can spot two key inflection points. The first one happened in July 2023 when we launched MAGE, a GPT SaaS starter that uses Wasp under the hood (you can think of it as one-shot Loveable/Bolt). It was among the first LLM products that could generate a working full-stack web app, bringing many eyes to Wasp.

The second major growth catalyzer came in December 2023 with the launch of OpenSaaS, our open-source SaaS starter built on top of Wasp, which now has almost 10,000 stars on GitHub.

We realized that most builders really want to start working on their idea as quickly as possible without picking out and patching together all the different features every SaaS needs - authentication, payments, admin dashboard, sending emails, blog, …

And this is exactly what we provided - a 100% free & open-source, high-quality, SaaS starter based on React, Node.js, Prisma, and Wasp. OpenSaaS basically became a “killer app” for Wasp as it attracts developers to try it and realize how helpful the framework is.

Open SaaS also pairs extremely well with Cursor - given Wasp’s robust structure and higher-level primitives, many developers have found it as an ideal combo for getting their SaaS-es from an idea to a production-ready app in a matter of days.

// Detect dark theme var iframe = document.getElementById('tweet-1832194642596508076-687'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1832194642596508076&theme=dark" }

Language/DSL vs framework - so which one is it?

As you can see from the examples above, we used to refer to Wasp as a language, DSL - a Domain Specific Language. It was for these reasons that we originally set out to have an abstraction layer that can, in the future, work with any language, library, and architecture.

For this, we needed to introduce our own compiler that would first analyze your app’s specification that you defined via Wasp (e.g., your routes, async jobs, db operations, …), combine it with the “native” code you wrote in React & Node.js, and finally generate a React/Node.js app. That effectively meant we’ve invented our own language, albeit very limited and simple.

This is how we initially presented Wasp, but we learned that is the wrong way to think about it. Wasp is by its function a web framework, just like Laravel, Rails, or Next.js. The fact that it uses a compiler under the hood is simply an implementation detail that gives it its superpowers. For example, thanks to this approach, we can easily visualize the topology of your whole app, from database to server and client components:

The road to 1.0 and building the next-gen framework

This is the story of how Wasp came to be where it is today. For more details on the very early days (getting from an idea to the first 1,000 stars), you can check out this post.

What’s next? After almost five years of building and getting feedback from you, we have a pretty clear picture of what Wasp 1.0 needs to look like. Simply put, we have set out to build a full-stack framework with the best possible developer experience. We want you to focus on building your product and spend as little time as possible fighting your stack.

Think what Rails and Laravel did for Ruby and PHP - we’re doing the same for the modern, AI-powered, JS ecosystem.

To follow our story and support us, star Wasp on GitHub and join our Discord - we can’t wait to see you there!

Meet Marko Saric, Co-founder of Privacy-friendly Plausible Analytics

Milica Maksimovic — Tue, 04 Mar 2025 15:39:18 +0000

In this interview, Marko Saric shared his thoughts on privacy and running a bootstrapped SaaS business. Plausible integration is already available in Open SaaS as a privacy-friendly alternative to Google Analytics. We hope this interview helps you understand the value of such a product, and the nature of running an open source business.

Here's a few other things we've covered in this interview:

Tackling big tech privacy issues.
How bootstrapping your business fuels independence and transparency.
Real, practical advice for growing your SaaS the smart way.

Let's dive in!

Can you share a bit about your background and what led you to start Plausible?

I'm Marko Saric, co-founder of Plausible Analytics.

My journey with Plausible began with a growing awareness of the privacy issues surrounding Google and its products. For many years, I was a user of Google's services but over time (and thanks to Snowden, Cambridge Analytica and other privacy scandals), I became more aware of the negative aspects of surveillance capitalism. This led me to explore better, more ethical alternatives to the big tech products.

I started sharing these alternatives on my blog which is how I connected with my co-founder Uku. We both had experience in tech and a shared vision of working on a privacy-friendly analytics tool so we decided to work together on Plausible. I'm focused on marketing and communication side of things while Uku is focused on design and development.

For those unfamiliar with Plausible, how would you describe its core mission in just a few sentences?

Plausible Analytics is an easy to use, lightweight, open source and privacy-friendly analytics tool. Our mission is to provide website owners with useful insights while respecting visitor privacy.

We have been working on Plausible for more than 6 years now, have more than 14,000 active subscribers at this point and have counted more than 136 billion pageviews so far.

Plausible is bootstrapped and open-source—what made you choose this path instead of taking the more common VC route?

We chose to bootstrap and open source Plausible because we wanted to maintain control and independence while also being more privacy-friendly and transparent.

Both of us have worked at venture funded startups in the past and neither of us had good experiences with investors so going bootstrapped was pretty much the way to do this if we wanted to do things our way.

We're in the privacy niche so open sourcing our product allows us to build trust as people can inspect our code to verify that our actions match our words. People cannot do that with Google Analytics and other competing products.

Just like Plausible, Wasp is an open-source project too! We'd appreciate it if you could star Wasp on GitHub as a sign of support! ⭐️

Do you have any advice for people who are considering bootstrapping their company? Do you have any books or podcasts to recommend?

I think it's a good idea to start bootstrapped even if you do wish to get funded. You should focus on creating a great product that solves a real problem and on spreading the word about it. If you do that well, you'll have investors reaching out to you even if you don't want or need them.

I recommend reading "Rework" by Jason Fried and David Heinemeier Hansson. It offers unconventional but valuable insights into running a startup.

Another good book is "This Is Marketing" by Seth Godin. It's about how many startups confuse marketing with spending money on advertising, spamming, interrupting, being annoying and other hacks and tricks. That's not marketing. Marketing is communication.

How did you get your first customers?

Our first customers came through community engagement and the "build in public" movement. We shared our journey, steps taken and product development openly on our blog, social media and niche communities such as Indie Hackers. That's how we got the early beta users and some of those became our first subscribers too.

What were the biggest challenges you faced while building and growing Plausible?

The first year was pretty challenging in terms of growth. Uku was working alone on Plausible trying to do both development and marketing. This is pretty much an impossible task. The growth was very slow and we made it to about 100 subscribers and $400 MRR some 14 months into the existence of Plausible.

That's when Uku decided to look for a marketing co-founder and that's how we found me. Being two co-founders helped us put more time and effort into marketing and communication. One of the first things we did when I joined was to change our positioning to make it crystal clear and easy to understand what we do, what we stand for and how we compare to Google Analytics (the biggest name in our market). And then we started publishing educational and informative content covering topics such as privacy, open source, bootstrapping and startup marketing .

I have written more about the changes we made in these early days in this post.

Which growth strategies have been the most effective?

We have a boring marketing strategy and we say no to all the growth hacks and other best marketing practices. Content marketing has been our most effective growth strategy. As an example, the first blog post that I published (Why You Should Remove Google Analytics from Your Site) went viral on Hacker News. It drove some good traffic to our site leading to an increase in brand awareness.

What matters is doing quality work and staying consistent with it over a longer period of time so we continued to publish multiple blog posts per week for over a year. Thanks to that work, we've been fortunate enough to achieve the viral moments on Hacker News multiple times over those first 2-3 years.

I have shared more about our early years, marketing steps we've taken, lessons we've learned and things we have achieved in blog posts such as this one. Our analytics dashboard is open to the public so it's possible to see the progress we've made since day one in our stats.

What role has the community played in Plausible's growth? Have there been any surprising or particularly impactful contributions from the community?

The community has helped shape our product and spread the word about our mission.

We have an open roadmap and listen to the product feedback which determines our development prioritization. This is where feature requests and other feedback is very valuable to us. We pretty much pick the most upvoted feature and work on that.

As mentioned earlier, we don't do any traditional marketing as in we don't do any paid advertising nor pay anyone to recommend Plausible. This means that most of our growth comes from people who love using Plausible and who share their experiences with the world. Without people spreading the word about Plausible it would be difficult for us to do what we do. So that's why community contributions is vital for us.

What's next for Plausible? Are there any upcoming features or improvements you're particularly excited about?

We're focused on continuing to improve Plausible and making it even more useful and competitive while staying true to our mission and meeting rigorous standards for stability, security and privacy.

Our developers are currently working on the top two most upvoted feature requests from our public feedback board (scroll depth and saved segments) so that's very exciting. It would be great to release these two big features soon!

Just like Plausible, Wasp is an open-source project too! We'd appreciate it if you could star Wasp on GitHub as a sign of support! ⭐️