Wasp calls itself “A truly full-stack TypeScript framework that just works.” The mechanism behind that claim is a configuration layer: you describe your application in *.wasp.ts files, and Wasp wires together React on the front end, Node.js with Express on the back, and Prisma for the database — adding auth, background jobs, email and deployment.
The name is the design: Wasp stands for “Web App SPecification.”
How the spec layer works
You write declarations using the @wasp.sh/spec package — functions like app, route, page, query, action, job and api — and then implement the actual logic in ordinary React, Node and Prisma code. Data models live in schema.prisma as they normally would.
So the spec is not a DSL that replaces your code. It is a description of the parts and how they connect, with the implementations left in the languages you already use. Declaring auth or a cron job becomes a few lines rather than a day of wiring.
wasp build then produces deployable output in .wasp/out/ — a Dockerfile plus server/, web-app/ and db/ folders. The documentation’s framing of that output is the right mental model: “Treat the generated code like any compiler output,” readable when you need to debug but not something you edit.
From zero to a running app
npm i -g @wasp.sh/wasp-cli@latest
wasp new my-app
wasp startA local database comes up with wasp start db. Deployment has one-command paths to Fly.io and Railway — for example wasp deploy fly launch my-todo-app — and self-hosting works by deploying the generated Dockerfile and static files. The project is MIT licensed and makes a point of “No Provider Lock-In” and “Self-Host Anywhere,” which the generated Dockerfile substantiates.
The caveat that decides adoption
Wasp is in beta. The site says so directly — “Wasp is still in Beta” — and that the team is “moving fast toward 1.0,” which is when it will call itself production-ready. Example specs reference version ^0.24.0.
That is not a reason to dismiss it, but it is the fact to plan around. A pre-1.0 framework that sits between you and your stack is a different risk profile from a pre-1.0 library you import: breaking changes land in the layer that connects everything, and migration work is not optional.
The stack constraint compounds it. The documented limits are explicit: the stack is React, Node.js and Prisma, the team is “focused on refining the design on a single stack,” and replacing core parts such as React or Prisma is “not yet” possible. Deployment convenience currently covers Fly.io and Railway, with more planned. Windows support is listed as in development, with mobile support, RBAC and multi-tenancy on the roadmap.
Who it suits
Someone building a conventional full-stack web app on exactly that stack who would rather not spend the first week on auth, jobs and deployment plumbing. If React plus Node plus Prisma is already your default, Wasp removes a large amount of boilerplate and the escape hatch is real — you can read the generated output and self-host it anywhere.
Who it does not suit: anyone who needs a different stack, anyone on native Windows today, and anyone whose project cannot absorb pre-1.0 migrations. “Not yet” on swapping Prisma means the spec layer and the stack are a package deal for now.
The sensible test is a wasp new scaffold with auth and one background job — the two things it claims to make trivial — and then a look inside .wasp/out/ to see what it generated. If that output looks like code you would be comfortable debugging at 2am, the trade is probably worth it.
