Forem: vincanger

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.

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

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 :)

I built my SaaS app fast. Now it's marketing time.

vincanger — Wed, 26 Feb 2025 15:50:55 +0000

A few weeks ago, I gave myself the challenge of building and marketing a SaaS app to $100 in 1 month.

While I've slightly missed the mark since it's taken me ~25 days to build and launch the app, I'm happy to say that the app is now live -- https://blogbannergpt.xyz !

What is the app? It's an image generation tool that generates blog banner images based solely on your post's title!

In fact, the banner for this blogpost was made with it. Cool, right?

So, now, you might be wondering why I took on this challenge, and it's simple really.

As developers, we're living in the golden age of solo SaaS app development. With AI-powered coding tools like Cursor, and batteries-included full-stack frameworks like Wasp, we can launch apps in weeks that used to take a team of developers months. Insane!

Also, I'm the creator of Open SaaS, a free, open-source SaaS boilerplate starter, and I’ve been seeing other builders using my boilerplate share their success stories, such as getting their SaaS apps acquired within a couple weeks.

So I got inspired to try and build and market more SaaS apps of my own.

I've been documenting my progress through this self-imposed challenge on TikTok, where I've built a nice little following so far. I shared all the tips, tricks, and tools I used while building the app.

Now I'm going to share my entire marketing journey as I try and promote the app and make some real money with it, so follow along if you're interested :)

Of course, marketing is always a difficult task for a developer, and I don't have a huge social media following. So part of this challenge is to help me build my marketing muscle. And by documenting the entire process via videos and posts, I'll get better at “building in public” and finding marketing channels for the right audiences.

Here are some of the marketing ideas I'll try out, and post about, in the coming weeks:

Direct Emails to potential customers
Product Hunt launch to help me organize promotion materials and create good messaging
Reddit replies and maybe some posts -- I have to be careful here to not get seen as direct marketing or spam
Twitter/X and TikTok marketing posts on my personal channels.

Come follow along on my journey and see if I make it, or just make a fool of myself :)

There's never a better time than now to build!

Can I build & market a SaaS app to $100 in 1 month?

vincanger — Wed, 15 Jan 2025 12:36:00 +0000

Everyone’s saying it. We’re living in the golden age for software development.

With the current suite of tools, it’s getting easier for hackers to create and market their apps. Or, as Mckay Wrigley puts it, what used to take a team of developers, and tons of money, can now be built be a single developer using Cursor.

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

I agree, although I do think the claims are a tad bit exaggerated, I believe we will see many more solo-developers building profitable businesses, either as side projects, or as their main focus.

In fact, as the creator and maintainer of Open SaaS, a free, open-source SaaS starter, I’m seeing this first hand. Builders using Open SaaS are sharing their success stories, such as getting their SaaS apps acquired within a couple weeks of building it.

It’s pretty amazing, to be honest.

But not only has the success of my fellow builders impressed me, it’s also inspired me. And it’s motivating me to challenge myself to do the same. So here’s what I have planned.

I am going to challenge myself to build and market a SaaS app to $100 dollars within about 1 month.

The best part is, I am going to document the process almost in its entirety, by live-streaming all my coding and marketing sessions, as well as posting summaries to social media. So if you want to follow my journey, check out the following profiles

x.com/hot_town
tiktok.com/@hot_town_
youtube.com/@wasplang (where I’ll be live-streaming)

For this challenge, I am going to use my Open SaaS template as a starting point. I’m also assuming the app will use some AI capabilities, such as OpenAI’s API, and maybe Flux image generation via Replicate.com. But, for now, I still haven’t settled on a concrete app idea (I’ll probably have this figured out by day 1 of the challenge).

Now, it should be known that this type of challenge isn’t really something new. Peter Levels (aka levelsio) did this back in 2014 before the rise of LLMs with his 12 startups in 12 months challenge. His reasons for pursuing this idea were that he wanted to get into the habit of just shipping stuff and iterating quickly on his ideas to figure out which ones have potential, and to get out of the habit of ruminating too long on any single app.

For me, I also want to push myself to build and launch more, but I also want to put the current tools to the test and see if it’s really possible to be a 1000x engineer in the age of AI. That’s why I’ll be using the following:

Cursor — AI code editor
Claude 3.5 sonnet — Top notch LLM for coding
Open SaaS — Open-source SaaS starter w/ Stripe, AWS S3, Admin dashboard, …
Wasp — The Batteries-included React, NodeJS, & Prisma framework that Open SaaS is built on top of
OpenAI API — For the “GPT Wrapper” side of things
Replicate.com — API for other open-source AI models (LLMs, Image gen, etc.)

Not only will this challenge help me launch more, but it will also help build my marketing muscle. I unfortunately don't have hundreds of thousands of twitter or tiktok followers, so I'm gonna really have to get my hands dirty and do some grassroots marketing. And by documenting the entire process via streams, video, and posts, it’ll help me get better at “building in public” and finding marketing channels for the right audiences.

I should mention that I’m not stranger to building profitable SaaS apps, as I already have an open-source SaaS app that makes ~$550 MRR. So the nice thing about this challenge will be to see if I just got lucky the first time, or if I have it in me to bring a good idea to life and market it effectively again.

Well, I’ll just have to get to work and see. Come follow along as I do!

Very proud to be the creator of one of the most popular open source SaaS starters

vincanger — Wed, 11 Dec 2024 13:42:07 +0000

Should You Use an Open-source SaaS Boilerplate Starter or a $300+ Paid One?

Matija Sosic for Wasp ・ Dec 11

#webdev #javascript #beginners #opensource

How a solo dev quickly built and sold his SaaS app for $20k 🏃‍♂️💰

vincanger — Thu, 14 Nov 2024 13:42:31 +0000

TL;DR Build Fast, Sell Faster

You've probably seen tons of stories online of successful devs who build a SaaS app and starting brining in the money.

Well, we've got another one for you.

And we're not sharing this story with you to make you feel bad, but rather to inspire you and tell you about the dev tools that made it all possible.

First of all, depending on who you are $20,000 may seem like a small amount of money, considering apps are often valued for millions of dollars in the tech world. But for others, $20k can be life changing.

Regardless, each story has some value in it, and this story in particular highlights a few great strategies in selling a small SaaS app:

Build fast with the right tools.
Be bold and make your product public ASAP.

This is the simple story of Kaloyan and how he built and sold NuloApp in a matter of weeks.

The Dev Behind the App

Meet Kaloyan Stoyanov, a tech lead by day, and a tinkerer and indiehacker by night who built and sold NuloApp a few days after making it public.

A year before officially launching NuloApp, Kaloyan was diving into the world of "faceless YouTube channels", those social media accounts that post short, simple, sometimes AI-narrated videos. Kaloyan wanted to start his own channel, but noticed that the common tools to generate short-form content from long-form videos, such as Opus.pro, were very expensive.

Seeing how expensive these tools were, Kaloyan decided to take matters into his own hands, building his own tool in just a month.

Initially, his tool automatically created and uploaded shorts, but after some time, when his channel didn’t pick up, he stopped the project. Fast forward to a year later, and YouTube's algorithm brought similar content back into his feed, reigniting his drive.

This time, Kaloyan took it further by transforming his tool into a SaaS product: NuloApp.

Before We Begin

We’re working hard at Wasp to help you build web apps as easily as possible, including creating inspiring content like this!

The easiest way to support our entirely free, open-source efforts is by starring our repo on GitHub: https://www.github.com/wasp-lang/wasp 🙏

⭐️ Star Wasp on GitHub 🙏

All about NuloApp

NuloApp is an AI-assisted tool designed to make video content creation simpler by converting long-form videos into short clips that have the highest chance to capture audience’s attention.

It automatically resizes and captions content from horizontal (landscape) to vertical (portrait) for platforms like YouTube Shorts, Instagram Reels, and TikTok, helping creators push content faster. Here's an example video

Tech Stack Overview

Full-stack framework: Wasp
Payment integration: Stripe
Other tools: OpenCV, FastAPI, Meta's llama, OpenAI's Whisper, LangChain
Database: PostgreSQL

Programatically Editing Videos

The real genius behind NuloApp is the way that Kaloyan combined a number of tools to programatically edit the longer form videos and podcasts, into short, engaging clips for social media.

First of all, OpenCV, an open-source computer vision library, was used as the main editing tool. This is how NuloApp is able to get the correct aspect ratio for smartphone content, and do other cool things like centering the video on the speaker so that they aren't out of frame when the aspect ratio is changed.

In order to programtically get the correct clips to be extracted, AI tools like Meta's llama-3-70b LLM and OpenAI's Whisper were also used. Whisper allowed for fast speech-to-text transcription, which could then be passed on the llama in order to find the segments worth extracting.

Putting these tools together and accessible via a standalone API was the final step in this process. But this really clever combination of tools was just one part of puzzle. The next problem to solve was how to deliver it all as a SaaS app that users could pay for?

Why Wasp?

When Kaloyan decided to relaunch his tool as a SaaS product, he didn’t have time to spare. He needed a framework that would allow him to build and deploy quickly. That’s where Wasp came in.

“I was looking for a quick and easy-to-use boilerplate with most SaaS app features already pre-built so I could deploy faster,” says Kaloyan. Wasp’s open-source SaaS boilerplate starter, with well-structured documentation, alongside its responsive Discord support, made it the ideal choice.

The Impact of Wasp on Development

Kaloyan was particularly impressed with how Wasp simplified complex tasks that would normally take much longer to implement. From setting up Google logins and dark mode switches to creating hourly jobs, the development process was smoother than expected. “Everything from enabling Google logins to creating hourly jobs I badly needed was way too easy to set up”.

If you're considering Wasp, Kaloyan’s advice is clear: Wasp is easy to get started with and flexible enough to build what you need without adding unnecessary complexity. For Kaloyan, Wasp was ideal because it handled the boilerplate while still giving him the freedom to customize as required. "The documentation is also solid, which definitely helps when you're moving quickly.”

Auth and Stripe Integration Made Easy

One of Kaloyan’s least favorite tasks as a developer is building out authentication systems, and he found that even implementing third-party libraries could be frustrating. Fortunately, Wasp’s boilerplate made the process of setting up authentication and pre-configuring Stripe for payments seamless.

Here's what wasp.config file looks like, through which you can define full-stack auth in a Wasp app.

app myApp {
  wasp: {
    version: "^0.14.0"
  },
  title: "My App",
  auth: {
    // 1. Specify the User entity
    userEntity: User,
    methods: {
      // 2. Enable Github Auth
      gitHub: {},
      email: {
        // 3. Specify the email from field
        fromField: {
          name: "My App Postman",
          email: "hello@itsme.com"
        },
        // 4. Specify the email verification and password reset options
        emailVerification: {
          clientRoute: EmailVerificationRoute, //this route/page should be created
        },
        passwordReset: {
          clientRoute: PasswordResetRoute, //this route/page should be created
        },
        // Add an emailSender -- Dummy just logs to console for dev purposes
        // but there are a ton of supported providers :D
        emailSender: {
          provider: Dummy,
        },
      },
    },
    onAuthFailedRedirectTo: "/login"
  },
}

And here's a 1 minute demo:

Additionally, the framework's job scheduling features helped Kaloyan avoid the headache of configuring cron jobs on Docker containers.

Fast Acquisition: From Launch to Sale in 24 Hours

Upon launching NuloApp, Kaloyan listed the product on Acquire with the primary goal of gathering feedback from potential buyers about what features or metrics they value most in a SaaS product.

To his surprise, within the first day of listing, he received multiple offers. After a brief meeting with one interested buyer, they quickly agreed on a $20k deal, validating the product's value and market potential.

Next Steps

If you’d like to follow in Kaloyan’s footsteps, this is how to get started with the boilerplate he used.

Open your terminal and install Wasp:

curl -sSL https://get.wasp-lang.dev/installer.sh | sh

From there you only need to run:

wasp new -t saas

That’s it, you’re one step closer to building your first SaaS!

Join us, friend!

So there you have it. Another success story. And it won't be the last!

That's because we've got a strong Discord community of indiehackers and solo devs building successful SaaS apps in their free time.

Join us if you've got questions, are looking for inspiration, or want to share what you're building. Who knows, maybe you and your app will be featured in a future blog post just like this one?

Thanks, and see you next week.

Making the most annoying cookie banners we could think of 🍪🤬

vincanger — Tue, 22 Oct 2024 14:43:44 +0000

Dark patterns in web UX are design features that are subtly designed to get the user to perform a specific action.

Cookie consent banners are one of the classic examples of dark patterns because they want the user to click accept, so they make rejecting them as annoying and tedious as possible.

Considering this, we wanted to see how blatantly annoying we could make cookie consent banners, which is why we set up THE MOST ANNOYING COOKIE BANNER HACKATHON.

With the deadline past, and submissions now in, we thought we'd present you with a showcase of some of the cookie banners our participants came up with.

BTW, We're allowing the community to vote on winners in an elimination style tournament on Twitter/X, starting Wednesday October 23rd.

🗳 Vote for the winners 🏆

Everyday we will post two cookie banners and you get to vote for who you think should move on to the next round

Participant Showcase

Below are a handful of the submissions our participants conjured up. Click the links to visit the sites and try them out yourself!

Windows of Time

Find all the Cookies

Gangnam Style Match the Beat

The GDPR Cookie regulations quiz

The Impossible Captcha

Find the ball to reject cookies

The Cookie Consent Application Process

Fresh batch of cookies

Do some math & quiz about the Big Bang Theory show

We don't even use cookies, but here's a cookie banner anyway

Cast your vote

Don't forget, we're allowing the community to vote on winners in an elimination style tournament on Twitter/X, starting Wednesday October 23rd.

Everyday we will post two cookie banners and you get to vote for who you think should move on to the next round

🗳 Vote for the winners 🏆