wasp-lang/wasp: a compiler that writes your whole app, and one fixed stack

Your app is the compiler's output, which is also the answer to the lock-in question

The How it works section is the most important paragraph in the README, and it is three sentences. Given a simple spec file that describes the high-level details of your web app, and your own source files in the languages the framework expects, the Wasp compiler generates the whole source of your web app in the target stack: front-end, back-end and deployment.

So this is code generation, not a runtime library. Your application exists because a compiler wrote it, in three parts, including the part that deploys it.

That is also the answer to the no lock-in claim, and it is a good one. The list of advantages says you can deploy the app anywhere, that there is no lock-in into specific providers, that you have complete control over the code, and that you can actually check it out in a generated directory if you are interested. The generated code is on disk, in your project, written in the ordinary stack, and yours to read.

The corollary is that the spec file is the source of truth. Your React components and your Node queries are inputs; the application is the output. That is a comfortable arrangement while the framework is doing what you want, and an awkward one on the day it does not, because the thing you want to change is a layer you do not have.

The stack is one stack, and the README says the multi-stack idea is future work

The Project status section contains two paragraphs and the second one is the constraint that matters.

It says that while the idea is to support multiple web tech stacks in the future, the project is currently focused on a specific stack: React with TanStack Query, Node.js with Express.js, and Prisma.

So the three components you might most want to choose are chosen for you. The query layer for talking to your server is TanStack Query, the server is Express, and the database access is through Prisma's schema and client. The feature list leans on exactly that pairing, since the remote procedure call feature is described as client to server and the type safety feature is described as end-to-end, and both of those are properties of a specific client library, a specific server framework and a specific schema layer working together.

The practical consequence is that Wasp is a bet on that combination rather than a set of interchangeable parts. If your team already has opinions about its server framework or its ORM, the migration path runs through Wasp's own feature set rather than around it, and the project's own statement that multiple stacks are a future idea is the honest version of that.

The version lives in your spec file, and the example still pins the previous line

The code example starts with a spec file that names the framework version as part of the application definition:

export default app({
  name: "todoApp",
  wasp: { version: "^0.24.0" },
  title: "ToDo App",

So the framework version is declared inside your own source file, which is a good thing for reproducibility and an unusual thing for an upgrade. Bumping Wasp is an edit to an application file, and a project with a dozen applications has a dozen places where that decision lives.

The pin in the example is worth noticing against the release list. The recent releases are v0.26.0 on 2026-10-16, then a release candidate for 0.26.1 and v0.26.1 itself, both on 2026-10-23, under four hours apart. So the newest line is 0.26, and the README's own sample is written against 0.24.

The range syntax matters too. A caret range on a version inside a file you generate from means a fresh install can resolve to a newer minor than the one you tested, and since the project is pre one, that is a decision you make per application rather than per repository.

The project says it is in beta and to expect numerous changes

The Project status section is two paragraphs long and both are about expectations rather than features.

The first says Wasp is currently in beta, with most features fully developed and functioning well, but that there are still many improvements and additions in mind and the team is continually working on them, and as a result you can expect numerous changes and improvements in the future.

That is an unusually direct statement to find in a README, and it is the sentence to quote when someone asks whether the project is safe for a long-lived application. A pre one version with a stated expectation of numerous changes means the upgrade path is part of your maintenance plan rather than an occasional chore, and it means the features list, which reads like a settled surface, is a description of today rather than a contract.

The second paragraph is the stack constraint quoted elsewhere, and the section points at a development roadmap on the project's board, which is the place to look for what is actually moving.

Fixes go straight in, behaviour changes need a conversation first

The Contributing section draws a line that is more specific than most, and it is a single sentence doing the work: small, obvious fixes, described as typos, broken links, documentation corrections and small bugs where the fix is clear and comes with a test, are welcome directly as pull requests. For anything bigger, including new features, refactors and changes in behaviour, the project asks you to talk to them first in a GitHub issue or on Discord so the approach can be agreed before you write code.

The list of what counts as bigger is the interesting part. Changes in behaviour is in it, which means a pull request that alters what the generated application does, even if it is a small alteration, is in the conversation category rather than the fix category.

For a compiler, that rule is coherent. The generated output is a contract with whatever else consumes it, and the maintainers are saying that changing that contract is a decision rather than a patch. The cost to a contributor is that a well-meant pull request can be closed for being larger than the policy allows, and the benefit is that the policy is written down before the argument.

The root package has no version, no dependencies and four formatting scripts

The root manifest is the smallest one in the repository and it is worth reading as a statement about the project's shape.

It is named for the repository rather than for a package, it declares the module type, it has no version field at all, and it has no runtime dependencies. Its entire script section is four aliases, and all four of them are the same command in different clothes: a check that runs Prettier in check mode over the tree, and a write that runs it in write mode, with the check and the write each aliased under a shorter name.

Its dev dependencies are a formatter and four plugins, one of which organises imports, one of which formats package manifests, one of which formats shell scripts, and one of which sorts Tailwind class names, plus a TypeScript version.

So the repository root is a formatting harness, not a build. The compiler and the runtime live in their own directories with their own manifests, and the presence of plugins for shell scripts and package manifests in the root is the clue: this is a repository where the formatting covers more languages than the manifest's own type field suggests.

The project is explicitly built to be driven by an AI agent

One of the four stated advantages is aimed at a specific reader. The claim is that Wasp is perfect for AI by design, and the reasons given are a high-level spec of the whole app, an opinionated approach, built-in full-stack features, and a tight integration of all parts of the stack. The stated benefit is that this gives agents clear guardrails and structure, less boilerplate to manage, and better context management.

That is a real engineering argument rather than a slogan. A code generator driven by a high-level description of the application is a better input for an agent than a codebase it has to infer, and the guardrail is the same opinionation that section on the fixed stack described as a constraint.

The repository is built to match. There is a section on official AI agent plugins, with a page describing how to use them with a coding tool such as Cursor or Claude Code. The root carries a configuration file whose name is a documentation-context format, an agents directory, a Claude directory, and two agent instruction files. And the examples directory includes a project whose name is about asking questions of documents, alongside a kitchen sink, tutorials, and a realtime voting example over WebSockets.

The trade is the mirror image of the advantage. A scaffold an agent produces matches the framework's assumptions closely, which is exactly what you want on day one and exactly what you have to unpick when the framework and your problem diverge.

Editorial conclusion

Use Wasp if you are building a React and Node application that needs the unglamorous full-stack features, authentication, jobs, email, remote procedure calls and deployment, and you would rather declare them than assemble them. Do not use it if you need to choose your own query library, your own server framework or your own ORM, because the project states it is focused on a single stack of React with TanStack Query, Node with Express, and Prisma. Check four things before you commit: the version field inside your spec file, since the upgrade is a source edit and the README's own example still pins an older minor line (^0.24.0); the beta status, since the project says outright to expect numerous changes; whether you can live with generated code, since your application is the compiler's output and the spec is the source of truth; and what contribution looks like, because behaviour changes require agreeing on the approach in an issue before any code is written. The license is MIT, the newest release is v0.26.1 dated 2026-10-23, and the last push was 2026-11-02.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. wasp-lang/wasp on GitHub