Marcel Coetzee is a data scientist and AI consultant based in South Africa. With a background in actuarial science and data science, he runs his own consultancy. He also builds SaaS products on the side. His latest project, Hireveld, is a job board tackling South Africa's broken hiring market. He built it entirely with Wasp after trying nearly every other stack out there.

Tell us about yourself. How did you end up building web apps as a Python developer?​

My path has been a bit unconventional. I started in actuarial science, which involves insurance, mathematical statistics and risk modeling. From there I moved into data science, then data engineering, and eventually into building products. Python has been my main language through all of that.

Today I run my own consultancy doing data engineering and AI work. But I've always wanted to build my own things too, so I started learning the JavaScript ecosystem and working on SaaS products on the side. I'm not a JS native by any means, but with the rise of agentic coding tools, I realized I could finally turn my ideas into real full-stack applications without spending years mastering every corner of Node and React.

What's Hireveld, and what problem are you solving?​

Hiring in South Africa is expensive and opaque. Recruitment agencies take a massive cut of annual salary. The established job boards charge thousands of rands just to post a single listing. And too many roles still get filled through personal connections rather than merit.

I built Hireveld to change that. Employers post for free, applicants get ranked anonymously, and employers pay a flat fee to reveal candidates. It's simple, it's cheap, and it puts merit first. The whole thing runs on Wasp - auth, background jobs for expiring old listings, transactional email, payment integration, the works.

You mentioned trying about 10 different stacks before landing on Wasp. What happened?​

Yeah, I went through quite the journey. I started with PocketBase because I liked the idea of owning my code and not being locked into a cloud platform. It's a solid tool, but I quickly realized I needed PostgreSQL for search, background jobs, and a frontend that wasn't stitched together by hand. It just didn't scale to what I was building.

Then I tried Next.js, Nuxt, Svelte - they're decent, but those codebases can grow extremely quickly. As someone who's still relatively new to the JS ecosystem, I'd hit the limits of my knowledge fast. I even tried Django, thinking I'd stick with Python, but it's accumulated so much over the years. Too much magic, too much stuff.

My philosophy is: the projects that succeed expose as few abstractions as possible to the user. I try to keep myself at the highest level of abstraction I can. When I found Wasp on GitHub, the config file clicked for me immediately. You declare what you want - auth, database, jobs, email - and it all works together. I was writing actual product code on day one instead of gluing infrastructure together.

Don't prioritize the important over the urgent. With other stacks I was spending time on infrastructure decisions that felt important but weren't getting me closer to a product. Wasp let me focus on the urgent thing: shipping.

You're a big advocate for agentic coding. How does Wasp fit into that workflow?​

This is where Wasp really shines, and honestly I think more people need to know about it. I've been building Hireveld almost entirely through agentic coding - Claude Code in the terminal - and after trying 10 different things, Wasp is by far the best experience for AI-assisted development.

Here's why: context is the precious commodity. Every line of code in your project takes a chunk of the model's context window. Wasp keeps the codebase tight and small.

The .wasp config file means the AI can understand your entire app's architecture at a glance - your routes, your auth setup, your jobs, your entities. Instead of the agent crawling through hundreds of files trying to figure out how things connect, it's all declared in one place. And because Wasp is opinionated and constrained, the agent doesn't try to do 50 different things. When something is wrong, the compiler screams. That tight feedback loop is exactly what agentic coding needs.

Wasp respects the model's context length. It keeps things tidy. The constraint is the feature - it's what keeps both you and the AI from spiraling into a 20,000-line mess.

I should say - I'm not blindly vibe coding. I know where my files are, I know my routes, I hand-edit the main.wasp file when I need to. I take testing seriously, both e2e and unit tests. QA is the layer where you, the human, decide what you actually want to build. But Wasp gives me the structure to stay at a high level and be productive, even as someone whose main language is Python. Also bring my data science background to bear by simulating data to gauge how the system would react to real traffic.

You also contributed back to Wasp - tell us about the Microsoft Auth integration.​

Hireveld targets the South African enterprise market, and enterprises run on Microsoft. They need Entra ID (Azure AD) for single sign-on - it's non-negotiable. When I started building, Wasp didn't have a Microsoft OAuth provider. With most frameworks, that would mean either paying a fortune for a third-party service or building a fragile custom integration that becomes tech debt.

But Wasp's codebase is approachable enough that I could build the provider myself and contribute it back. The PR process was great - Carlos and the team were welcoming and helpful. That's the sweet spot I was looking for: a framework that's batteries-included enough that I'm not rebuilding auth from scratch, but open enough that when I need something custom, I can add it without fighting the framework.

The community in general has been one of the best parts. The developers are genuinely friendly, my contributions felt valued, and I can tell the team takes agentic coding seriously - they maintain a Claude Code skill, they keep their prompts updated, they engage with the tooling ecosystem. That's an unusual level of involvement for a framework team.

What would you say to a developer considering Wasp for their next project?​

If you're building a full-stack web app in 2026 and you're using AI tools to code - which you should be - try Wasp. Seriously. I went through PocketBase, Next.js, Nuxt, Svelte, Django, and more. Wasp is the only one where I felt like I was building my product from day one instead of fighting my tools.

It gave me auth, type-safe full-stack operations, background jobs, and transactional email - all wired together from a single config file. Everything else - the ranking algorithm, payments, file storage - I built on top of what Wasp provided. That separation is what made it possible to ship as a solo developer.

And if you're coming from Python or another ecosystem and you're intimidated by the JavaScript world - don't be. Wasp abstracts away enough of the complexity that you can stay at a high level and be productive. I'm proof of that.

Wasp is the full-stack framework for the agentic era. It's the one that lets you focus on what you're building, not how you're building it.

Marcel Coetzee is a data scientist, AI consultant, and SaaS builder based in South Africa. You can find him on GitHub and reach out to him on coetzee.marcel2@gmail.com

TL;DR​

We gave Claude Code the exact same feature prompt for two identical apps - one built with Next.js, the other built with Wasp - and measured everything that Claude Code did to implement the feature.

Not surprisingly, the savings were proportional to the amount of actual total code/tokens the Wasp framework abstracts away, which we also measured by running a static token count across both codebases. In this case, the Wasp version reduced total code/tokens by ~40%.

Because the framework allows Claude Code to get the same work done in fewer tokens, it delivers a ~70% higher token efficiency (output per token).

So, if you're using AI coding tools daily, your framework choice might be your single biggest lever for improving your AI's ability to generate accurate, complex code, quickly and cheaply.

What Wasp Actually Is​

Wasp is a full-stack framework for React, Node.js, and Prisma with batteries-included. Think Rails or Laravel-like productivity for the JS ecosystem but where authentication, routing, operations, database, and cron jobs are defined declaratively as config.

You write business logic and Wasp handles the boilerplate and glue code for you.

Here's a simple example of a Wasp app's config file:

import { App } from 'wasp-config'

const app = new App('todoApp', {
  title: 'ToDo App',
  wasp: { version: '^0.21' },
  // head: []
});

app.auth({
  userEntity: User,
  methods: {
    google: {},
    email: {...}
  }
});

const mainPage = app.page('MainPage', {
  component: { importDefault: 'Main', from: '@src/pages/MainPage' }
});
app.route('RootRoute', { path: '/', to: mainPage });

app.query('getTasks', {
  fn: { import: 'getTasks', from: '@src/queries' },
  entities: ['Task']
});

app.job('taskReminderJob', {
  executor: 'PgBoss',
  perform: {
    fn: { import: 'sendTaskReminder', from: '@src/workers/taskReminder' }
  },
  schedule: { cron: "*/5 * * * *" },
  entities: ['Task']
});

export default app;

Wasp's opinionated approach via its config gives AI tools (and developers) a big advantage: it acts as a large "specification" that both you and your AI coding agents already understand and agree on.

This gives AI one common pattern to follow, fewer decisions to make, less boilerplate to write, and fewer tools to stitch together, making the entire development process more reliable.

Show, Don't Tell​

Before the numbers mean anything, here's how Wasp's "declarative config" compares to Next.js's equivalent.

In this example, we're comparing the fundamental auth setup from the actual test apps. The first tab shows Wasp, and the second tab shows Next.js. Click between the tabs to see the difference.

app.auth({
  userEntity: 'User',
  methods: {
    email: {
      fromField: {
        name: 'SaaS App',
        email: 'hello@example.com'
      },
      emailVerification: {
        clientRoute: 'EmailVerificationRoute'
      },
      passwordReset: {
        clientRoute: 'PasswordResetRoute'
      },
    },
  },
  onAfterSignup: { import: 'onAfterSignup', from: '@src/auth/hooks' },
  onAuthFailedRedirectTo: '/login',
  onAuthSucceededRedirectTo: '/dashboard',
});

// lib/auth/session.ts
import { SignJWT, jwtVerify } from 'jose';
import { cookies } from 'next/headers';

const key = new TextEncoder().encode(process.env.AUTH_SECRET);

type SessionData = {
  user: { id: number };
  expires: string;
};

export async function signToken(payload: SessionData) {
  return await new SignJWT(payload)
    .setProtectedHeader({ alg: 'HS256' })
    .setIssuedAt()
    .setExpirationTime('1 day from now')
    .sign(key);
}

export async function verifyToken(input: string) {
  const { payload } = await jwtVerify(input, key, { algorithms: ['HS256'] });
  return payload as SessionData;
}

export async function setSession(user: NewUser) {
  const expiresInOneDay = new Date(Date.now() + 24 * 60 * 60 * 1000);
  const session: SessionData = {
    user: { id: user.id! },
    expires: expiresInOneDay.toISOString(),
  };
  const encryptedSession = await signToken(session);
  (await cookies()).set('session', encryptedSession, {
    expires: expiresInOneDay,
    httpOnly: true, secure: true, sameSite: 'lax',
  });
}

export async function getSession() {
  const session = (await cookies()).get('session')?.value;
  if (!session) return null;
  return await verifyToken(session);
}

export async function hashPassword(password: string) {
  return hash(password, SALT_ROUNDS);
}

export async function comparePasswords(plainText: string, hashed: string) {
  return compare(plainText, hashed);
}

// middleware.ts — route protection + token refresh
import { signToken, verifyToken } from '@/lib/auth/session';

const protectedRoutes = '/dashboard';

export async function middleware(request: NextRequest) {
  const { pathname } = request.nextUrl;
  const sessionCookie = request.cookies.get('session');
  const isProtectedRoute = pathname.startsWith(protectedRoutes);

  if (isProtectedRoute && !sessionCookie) {
    return NextResponse.redirect(new URL('/sign-in', request.url));
  }

  let res = NextResponse.next();

  if (sessionCookie && request.method === 'GET') {
    try {
      const parsed = await verifyToken(sessionCookie.value);
      const expiresInOneDay = new Date(Date.now() + 24 * 60 * 60 * 1000);
      res.cookies.set({
        name: 'session',
        value: await signToken({
          ...parsed,
          expires: expiresInOneDay.toISOString(),
        }),
        httpOnly: true, secure: true, sameSite: 'lax',
        expires: expiresInOneDay,
      });
    } catch (error) {
      res.cookies.delete('session');
      if (isProtectedRoute) {
        return NextResponse.redirect(new URL('/sign-in', request.url));
      }
    }
  }
  return res;
}

As you can see, Wasp's config is much more concise and readable than Next.js's.

Why This Matters for AI​

Now that you can see the abstraction gap, here's why it compounds for AI:

1. Performance degrades as context window fills up

   AI tools are stateless and have a finite context window and performance degrades long before it's completely full. A larger codebase fills it faster, which means earlier message compression, less room for reasoning, and degraded output. Developers also have to maintain detailed memory and skill files to help AI understand the app structure and implementation expectations.

2. Signal-to-noise ratio

   More tokens isn't just more expensive, it's more noise. Wasp's config is pure signal for AI, acting like a spec and concise map of the app the AI can follow. Next.js's equivalent is spread across route files, API handlers, middleware, and config. Higher noise = higher chance of mistakes.

3. Every LLM call to the API re-reads the codebase

   AI tools don't remember between turns. Each turn re-reads the session conversation and codebase context from scratch. A bigger codebase means every single turn costs more. In our test, cache reads alone cost $1.71 with Next.js vs. $1.09 for Wasp.

4. It compounds over a project's lifetime

   This test only measured one full-stack feature (db model, server operation, client page), and the differences were already significant (2.5M tokens vs. 4.0M tokens). In larger codebases, these differences quickly compound.

The Full Results​

Combined: Planning + Implementation Phases​

Here are the main takeaways:

• Output tokens (what the AI wrote): nearly identical — $0.21 vs $0.21
• Cache creation (what the AI first loaded): Next.js 113% more — $2.82 vs $1.32
• Cache read (what the AI re-read each turn): Next.js 57% more — $1.71 vs $1.09

Cache creation cost. By caching your prompts, Claude optimizes your API usage by reusing prompts. But while reading from cache is cheap, creating new cache entries is still expensive. Next.js had 2.2x more cache creation tokens (343K vs 155K), at $6.25/M that's $2.15 vs $0.97. The bigger codebase means more new content being loaded into cache.

Cache read cost. Each LLM call to the API re-reads the growing context. The Next.js codebase is bigger so each read costs more: $1.14 vs $0.67. Output tokens were nearly identical (~5,400), meaning the AI wrote roughly the same amount of code but had to read far more to do it.

The main differences comes from the Next.js codebase being bigger, meaning more tokens to load and re-read across every single API call to get the same output.

Context Efficiency: a New Evaluation Metric​

The savings mirror what Wasp abstracts: authentication, routing, database management, operations, and jobs are defined in the config, so AI doesn't need to read, navigate, or generate layers of glue code.

And while this is a new approach in the framework space, Wasp is just following a general principle here: tools that make coding easier for humans make it easier for AI, too. They offload structural work and let the AI focus on business logic, giving a clearer path to generating complex code more accurately.

Think of it as a new evaluation metric for any framework: "context efficiency", or how much of an AI's context window goes to signal vs. boilerplate. Add it alongside DX, performance, and ecosystem when choosing your stack in the AI-assisted coding era.

Methodology​

First, we took Vercel's official SaaS starter app in Next.js and converted it to a Wasp (React, Node.js, Prisma) app.

Then, we made sure to use the same models (Opus for planning and implementation, Haiku for exploring), same framework-agnostic prompt, and same plan-then-implement flow, outlined in the test protocol.

Finally, we created measurement scripts to pull metrics from Claude Code's detailed JSONL session transcripts.

We used Anthropic's API pricing as of March 2026 (per 1M tokens), e.g.:

Fairness caveats: Claude has seen far more Next.js training data (advantage: Next.js). Wasp's codebase is ~40% smaller, but that's the point. And this is a single feature test, not a comprehensive benchmark.

Explore the comparison yourself: both apps, the test protocol, and measurement scripts are in the comparison repo.

Try Wasp​

Want to try Wasp? Get started with:

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

Then start a new Wasp app:

wasp new my-app
wasp start

And don't forget to add the Wasp Agent Plugin / Skills to turn your agent into a Wasp framework expert!

Getting this right was harder than expected, and this post is what we learned. We'll dig into how npm workspaces actually work: how dependencies get resolved and hoisted, how Node.js finds modules at runtime, and help you build intuition/mental model that will come in useful when debugging this setup.

Your side project started as a single folder with a hundred lines of code. Now it's a full-stack app with a React frontend, an Express backend, and a shared library of types and helpers that both sides need. You might be copy-pasting files between folders like it's 2005, and the cracks are showing: a type definition got updated in one place but not the other, and now your API responses don't match what the frontend expects. Something has to change.

The first step would probably be splitting your code into multiple packages. But without the right tools, you'll quickly find yourself drowning in running npm install in five different folders, or fighting runtime errors because React is installed three times.To fix this, modern package managers introduced workspaces. Intended to allow you to manage multiple packages within a single repository without the dependency headaches, workspaces are widely used in many projects, but their inner workings are often misunderstood.

In this post, we'll dig into the magic that makes them tick: how package managers resolve shared dependencies across packages, and how Node.js finds them at runtime.

Enter workspaces​

Workspaces are a feature in npm, Yarn, pnpm, and others that let you organize multiple JavaScript packages in a single project. And while each package acts as its own encapsulated unit, they can still depend on one another with no extra ceremony.

Two main behaviors make this work: shared dependencies (if two packages depend on react, they both use the same installed version) and cross-package imports (a pkg-a can just import pkg-b by name).

The building blocks are interesting and require a dive into how package managers and Node.js work. The feature also comes after a long evolution of tooling and JS development practices, so let's start with some history.

A brief history​

It seems like the second half of the 2010s was when the professionalization of JS development started to trickle down to the average developer. The rise of Babel and Webpack gave us a modern development experience, one that more closely resembled what other languages had enjoyed for years. We finally had a proper module system, and the ability to target newer language versions, while still supporting older runtimes.

Our history of workspaces starts in 2015, when the 6to5 project realized they didn't want to work only on ES6 code, but also on everything that came after it. They renamed themselves to Babel and started working on modularizing the codebase, knowing they'd need well-separated concerns to keep up with the ever-evolving language.

Babel maintainers wanted to distribute the new version as a collection of plugins you could pick and choose, but couldn't afford to manage each one independently. So when they split all their code into different packages, they did so in the shape of a monorepo. That decision kickstarted the development of what would eventually be called workspaces.

Their internal tooling was soon released as Lerna. Lerna's main job was to allow packages in a monorepo to seamlessly require() one another as if they were already published, instead of having to edit, publish, and reinstall each one independently.

A few months later in 2017, Yarn came along. Yarn was created to solve some problematic behaviors of npm at the time, and dramatically improved performance and reliability. Alongside features like reproducible lockfiles and heavy caching, Yarn also introduced workspaces as a first-class citizen. This was no surprise, as Yarn was created by some of the same people who had worked on Babel and Lerna.

Soon, Yarn exploded in popularity, and in time, other package managers followed suit. pnpm added workspaces support in 2018, and npm followed in 2020. Nowadays, after a long evolution, workspaces are supported in all the mainstream package managers and widely used in both open and closed source projects.

Problems and solutions​

The exact definition of what a workspace is depends on the package manager you're using. The definition I gave above is more of an observation of what the main package managers have in common than a prescriptive specification. There isn't a common "workspaces spec". Each package manager has its own take, with different configuration formats, commands, and even different ways to declare dependencies.

That said, there's a core of functionality you can expect across package managers: you declare a root folder that contains multiple sub-packages. Each sub-package is called a workspace, and the whole set is a project¹. From there, three features usually become available:

• Each workspace is its own full package, as if it were an independent project. Each workspace has its own package.json, where it declares dependencies, configuration, and scripts without worrying about the insides of other packages.

• All dependencies are resolved together across the project, as if it were a single package. If two workspaces depend on the same package, it gets installed once and shared (assuming compatible version ranges).

• Workspaces can depend on each other by name, as if they were regular dependencies. In a project with many workspaces, pkg-a can import pkg-b and everything works.

Workspaces give us the best of both worlds: the encapsulation of small packages with the convenience of shared dependencies.

The first feature is just the natural way of working with multiple packages, so it doesn't require much explanation. Let's look at the other two: why they're useful and how they're implemented. The exact implementation details depend on the package manager, so we'll use npm as a reference here, since it's the most widely used. The general concepts apply across the board.

The dependencies of the whole project are resolved together​

The problem​

Imagine testing a project with many interconnected packages ...say, 157 of them. You'd have to find out which packages depend on which others, run npm install in each folder, and deal with the ongoing headache of keeping dependency versions in sync. Worse: if each package had its own node_modules, you'd end up with tons of copies of the same dependencies installed in different places.

Multiple copies aren't just a waste of disk space, they can cause bugs. In JavaScript, the same class defined in two different files is considered different, even if the code is identical²:

export class MyClass {}

export class MyClass {}

import * as foo from "./foo/my-class";
import * as bar from "./bar/my-class";

new foo.MyClass() instanceof foo.MyClass; // true
new foo.MyClass() instanceof bar.MyClass; // false!

For shared dependencies to work correctly, they need to be installed once, in a single place. That way, when different pieces of code import the same dependency, they get the same object.

The solution​

Most package managers already deduplicate dependencies for a single project. So to get this behaviour for free with workspaces, they cheat a bit: they treat all workspaces as dependencies of a single, "fake" root package. The existing resolution algorithm gets reused without changes.

You can see this in any workspaces lockfile. Here's a simplified example for a regular package with no workspaces:

"my-simple-package":
  dependencies:
    left-pad: ^1.0.0
    right-pad: ^1.0.0

"left-pad@^1.0.0":
  resolved: 1.1.0
  dependencies:
    core-pad: ^1.1.0

"right-pad@^1.0.0":
  resolved: 1.4.0
  dependencies:
    core-pad: ^1.4.0

"core-pad@^1.1.0,^1.4.0":
  resolved: 1.4.5

The package depends on both left-pad and right-pad, which both depend on core-pad with different version ranges. The package manager found a single version of core-pad that satisfies both and installed it once.

Here's the same scenario in a workspaces project:

"##fake-project-root##":
  dependencies:
    workspace-a: local
    workspace-b: local

"workspace-a@local":
  dependencies:
    left-pad: ^1.0.0

"workspace-b@local":
  dependencies:
    right-pad: ^1.0.0

"left-pad@^1.0.0":
  resolved: 1.1.0
  dependencies:
    core-pad: ^1.1.0

"right-pad@^1.0.0":
  resolved: 1.4.0
  dependencies:
    core-pad: ^1.4.0

"core-pad@^1.1.0,^1.4.0":
  resolved: 1.4.5

By pretending all workspaces are dependencies of a single root package, the package manager reuses its existing algorithm. It finds one version of core-pad that works for both, installs it once, and any workspace that imports it gets the same object.

Workspaces can depend on each other by name​

The problem​

If you have two separate packages and want one to depend on the other, you have two options:

• Publish the dependency to the registry, then install it in the other package. Straightforward, but if you're iterating quickly, the publish-install cycle kills your flow.

• Use a local file dependency. Edit the imports to point to the local path. This works, but it's brittle: if you move packages around or share the code with someone else, paths break. If the dependency has its own dependencies, you have to install them manually. And you need to remember to switch paths back before publishing.

Neither is great. What you actually want is to say "my package depends on pkg-b" and have the package manager figure out that pkg-b is just in the folder next to you. That's exactly what workspaces do!

The solution​

This seems straightforward to implement. The package manager knows where all workspaces are, so it could point to the right folder when it finds a matching dependency name. But there's a catch: the dependency resolution of the package manager (npm, Yarn) is separate from the import resolution of the runtime (Node.js).

If you've ever looked into your node_modules and found dependencies nested inside other dependencies instead of a flat structure, this is why. The package manager has no influence on how Node.js finds imports³, all it can do is lay them out on disk in a way that Node.js will understand.

How Node.js finds packages​

The high-level idea is simple:

• If the import is a relative or absolute path (./, ../, or /), Node.js follows that path directly.
• Otherwise, it looks for the import name in the nearest node_modules folder, starting from the current file's directory, walking up the folder tree until it finds a match or reaches the filesystem root.

For example, if we want to import e.g. left-pad, Node.js checks these folders in order:

• From ~/projects/app/src/utils.js

1. ~/projects/app/src/node_modules/left-pad
2. ~/projects/app/node_modules/left-pad
3. ~/projects/node_modules/left-pad
4. ~/node_modules/left-pad

Symlinks tie it all together​

We know we don't want multiple copies of the same workspace in different node_modules folders, because that would bring back all the problems we discussed. Instead, we can use symlinks. As a refresher: they are special files that just "redirect" to another file or folder when accessed.

So now, this just becomes a problem of how to arrange the symlinks in the node_modules folders for Node.js. And the solution: we'll create a symlink to each workspace in the top-level node_modules folder. Since Node.js walks up the directory tree looking for that folder, every workspace will eventually find the root one:

• package-root/
  • node_modules/
    • sub-a (symlink to sub-a)
    • sub-b (symlink to sub-b)
    • sub-c (symlink to sub-c)
  • sub-a/
    • package.json
    • ...
  • sub-b/
    • package.json
    • ...
  • sub-c/
    • package.json
    • ...

Here's an example:

import { foo } from "sub-b";
console.log(foo());

export function foo() {
  return "Hello from sub-b!";
}

How does Node.js resolve the import in sub-a/index.js?

• package-root/sub-a/node_modules/sub-b
  → doesn't exist
• package-root/node_modules/sub-b
  → symlink to package-root/sub-b/, follow it
• package-root/sub-b
  → found it!

By placing symlinks in the top-level node_modules, any workspace can import any other workspace by name, and Node.js finds it correctly.

When (not) to use workspaces​

While workspaces are pretty useful, they are not a silver bullet. That is, you shouldn't go link every project in your ~/dev folder just yet. Instead, they should be treated as a scoped feature, with a clear sweet spot.

In general, workspaces work best for projects that:

• Consist of multiple packages
• Will be developed in tandem
• Share many dependencies
• Call each other frequently

That's why workspaces are mostly used in monorepos: almost by definition, they satisfy all of these criteria. Wasp uses them outside the monorepo context, but that's because we generate packages for each part of your app, that are tightly coupled and evolve together.

On the other hand, I'd discourage using workspaces when:

• You don't have a good reason to split a single codebase or repo into multiple packages. Workspaces solve problems, but it's better if you don't have those problems in the first place.
• Your packages are mostly independent and don't share many dependencies. I wouldn't use workspaces to link all the random libraries in my ~/dev folder. It could lead to random interference between dependencies, or implicit relationships.
• You have cyclic dependencies. Without a clear story of which packages depend on which⁴, workspaces can allow any package depend on any other carelessly, and that can lead to a tangled web of dependencies.
• Your project is split across multiple repositories. Workspaces would make them no longer self-contained. Unless you're very sure of your use case, either unlink the repos altogether or merge them into a single monorepo.

Why does Wasp care about workspaces?​

When you run the Wasp compiler, it generates app code into a .wasp/ folder inside your project. And part of that generated code is three different packages: one for the SDK we generate from your Wasp spec, and a frontend and backend package that contain the final codebase for your deployed apps.

Those three packages are tightly coupled, with frequent imports across packages, and also to your own code. They also share many dependencies, and we want to avoid any chance of mismatches or duplication between them.

As part of our push for Wasp 1.0, we wanted to make this situation easier to work with, and we realized workspaces were a perfect fit for our problems. We worked on a project internally called Wasp Citizen, so we could capitalize on workspaces to ease our dependency mismatch issues.

Since Wasp v0.19, this is at work in every Wasp project. Your app still works as a single-package project and you don't need to learn anything new; but internally, the generated packages are structured as workspaces. This translates to a better experience for you, fewer weird bugs for us, and quicker installs for everyone.

And with this knowledge, if you want, now you can add your own workspaces to your Wasp project too, and have them play nicely with the generated ones!

Go off!​

Workspaces are a powerful tool that help you organize your code, avoid dependency errors, and speed up your development workflow. I hope this post has given you a good understanding of how they work under the hood and when to use them. If you find yourself in a situation where workspaces could help you, give them a try!

Until next time, happy coding!

Claude Code for fullstack development doesn't require complex workflows. Three essentials are all you need:

1. full-stack debugging visibility via background tasks and browser automation tools like Chrome DevTools MCP,
2. LLM-friendly documentation access via llms.txt (10x more context-efficient than MCP servers), and
3. an opinionated fullstack framework like Wasp that reduces boilerplate by 60-80% so AI can build more complex apps with greater accuracy.

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:

• stripe.com/llms.txt
• supabase.com/llms.txt
• wasp.sh/llms.txt

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:

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

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:

1. Install Wasp

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

2. 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

3. Start a new Wasp project

# create a new project
wasp new

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

4. Start a Claude Code session in your Wasp project directory

claude

5. Run the init command to set up the plugin

/wasp: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:

1. An opinionated framework that handles architecture/boilerplate so Claude doesn't have to
2. Version-matched documentation so Claude has up-to-date implementation details
3. 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.

This was the year in which we had to slow down in order to speed up. We got serious about maturity, transparency, and building the foundation for what Wasp needs to become. Still, we managed to sneak in a few cool new features, too.

We want to share with you what we achieved, what we learned, and what's coming next.

2025 in Numbers​

• 📦 13 releases (v0.16 → v0.20)
• 🚀 5 launch events
• ⭐ +8,182 GitHub stars across Wasp and Open SaaS
• 🔀 489 pull requests merged
• ✅ 284 issues closed
• 👾 4,669 Discord members
• 🐝 8 people working on Wasp full-time (welcome Franjo, Carlos & Tole!)

What We Shipped​

In 2025, we hosted five launch events - one each quarter, plus a special Xmas launch. You can see the details of each launch below:

• Launch Week 8 (January) - "Fixer Upper"
• Launch Week 9 (April) - "The Road to 1.0"
• Launch Week 10 (July) - "Public Exposure"
• Launch Week 11 (September) - "Grinding the Grind"
• Wasp Xmas Launch (December) - React 19, Claude Code Plugin, Polar

What we released falls into four major categories:

• Core & Developer Experience - the overall architecture, CLI, and what/how Wasp uses under the hood
• Integrations & Ecosystem - how well Wasp plays with other tools and services (deployment, analytics, AI, ...)
• Open SaaS - an open-source SaaS boilerplate starter, based on Wasp. Payments, admin dashboard, emails, and more
• Content & Education - tutorials, guides, showcases, and community engagement

Let's now dive into the details of each category:

Core & Developer Experience​

• React 19 & stack upgrades - Updated to React 19, along with Node.js and Vite version bumps
• Public development roadmap - Published our transparent path to 1.0, with epics and milestones tracked on GitHub
• Deployment docs rehaul - New guides for Coolify, CapRover, and improved deployment story overall
• TypeScript config (experimental) - Define your app in main.wasp.ts instead of the DSL, with full editor support out of the box. Soon to become the default.
• Quality of life improvements - Env variable validation with Zod, wasp build start for testing production builds locally, better TSConfig behavior

While some of these look like single bullet points, the roadmap and TypeScript config alone represent months of focused work. Behind the scenes, we also overhauled our internal architecture - modernizing how we build, test, and release Wasp, so we can move faster and ship with more confidence.

This groundwork is already enabling us to make Wasp behave more like a "standard" part of the JS ecosystem: respecting your existing tooling, playing nicely with other libraries (e.g. ShadCN), and just working the way you'd expect.

Integrations & Ecosystem​

• Railway CLI Integration - One-command deployment to Railway with wasp deploy railway launch
• Claude Code Plugin - AI-assisted development with deep Wasp integration
• AI-friendly docs - Added .cursorrules and llms.txt with versioning, so AI tools always have the right docs for your Wasp version
• Slack Authentication - New auth provider, next to Google, GitHub, Discord, and others

No tool can exist in isolation. And when we find a service/tool that fits with Wasp's philosophy, we go above and beyond to make it easy to use together.

Open SaaS​

2025 is the year Open SaaS truly came into its own. What started as a simple wrapper around Wasp with common SaaS features has grown into a fully-fledged product. It's now one of the most common ways developers start their (Wasp) apps.

• Hit 13,000+ GitHub stars - One of the most popular React/Node.js SaaS starters
• Complete redesign (v2.0) - Now with ShadCN UI, and a sleek new design by default
• Railway Marketplace - Now part of Railway's official marketplace. One click deployment to Railway's hosting platform.
• Polar integration - New billing provider, next to Stripe and LemonSqueezy

Open SaaS now also has its own roadmap, developed in parallel with Wasp's roadmap. You're welcome to join, comment, and contribute - we'd love to have you!

Content & Education​

Launch Weeks are our most intense publishing periods, but we don't go quiet in between. We aim to keep you up to date with Wasp's progress while sharing what we're learning along the way.

Most popular deep-dives:

• How we test a web framework
• Cleaning up 5 years of tech debt in a full-stack JS framework

Most popular tutorials:

• Building Advanced React Forms Using React Hook Form, Zod and Shadcn
• A Gentle Introduction to Database Migrations in Prisma
• How to Run CRON Jobs in Postgres Without Extra Infrastructure
• Build an agent-powered SaaS with Mastra AI & Wasp (video)
• Vibe Code a Full-stack App Effectively (video)

What We Learned​

Developers really want "Rails for JS" - productivity and portability​

The JavaScript ecosystem is incredibly powerful - its modularity means there's a package for everything. But that same modularity makes it exhausting to start and maintain a full-stack project. You have to choose your bundler, your router, your ORM, your auth library/service, your hosting platform... and then keep them all working together as they evolve.

We've heard this over and over again: developers want the productivity and portability of Rails, but in the JavaScript/TypeScript world they already know. This conviction has only grown stronger for us in 2025 - there's a real gap here, and we're building to fill it.

Frameworks matter more in the age of AI, not less​

Here's something we've assumed for a while but haven't seen confirmed until recently: AI coding assistants work dramatically better with opinionated frameworks. When there's one right way to do something, AI can nail it. When there are fifteen ways to wire up authentication, it's another point of friction you or your LLM need to think about and make a decision.

We're literally seeing this as a choosing criteria now for Wasp - developers pick tools that make their AI assistants more effective. Good abstractions aren't just nice for humans anymore; they're essential for AI too. This has reinforced our belief that the right level of abstraction is one of the most valuable things a framework can provide.

TypeScript is the way​

We're moving from a DSL to TypeScript config. From "Wasp language" to "Wasp framework." Some of this is messaging, but it's actually a meaningful shift.

TypeScript gives an editor support for free - autocomplete, type checking, refactoring tools - without us having to build and maintain custom IDE plugins. It's a language developers already know. And it opens the door to more flexibility while keeping the benefits of a structured, declarative config.

This move reflects a broader lesson: meet developers where they are. Don't ask them to learn something new unless it provides clear, significant value. TypeScript config is just as expressive as our DSL (even more), but without the learning curve.

Developers are building real businesses and tools​

2025 made something crystal clear: Wasp has moved past the "toy/side project" phase. We're seeing developers build very real things - production apps serving actual users, internal tools at enterprises, startups that have raised funding, and yes, even exits.

This shift is meaningful. It's one thing to hear "I built a to-do app with Wasp" and quite another to hear "we're running our entire company on it." The maturity of what people are building now - and the trust they're placing in the framework - is something we don't take lightly. It's also the ultimate validation that we're on the right track.

The Team​

This is the team that made it all happen in 2025. Without their focus and dedication, none of this would be possible. This year we welcomed Franjo, Carlos, and another Matija (Tole). It is a unique privilege to be able to pick (and get picked by) your own team and get to design our team culture as we build out the vision we have for Wasp.

What we're building hasn't really been done before - a true full-stack, batteries-included framework for JavaScript. That means we're often in uncharted territory. Our work takes a lot of research and design before we can even start writing code. What keeps us going is the feedback and adoption we see from the community - knowing that what we're building actually helps people ship and achieve their dreams and goals.

What's Coming Next​

Laser focus on 1.0​

The path is clear and we're going full speed. Everything we did in 2025 - the roadmap, the internal refactors, the testing infrastructure - was setting the stage for this. Now we execute.

Doubling down on AI​

We're seeing exciting signal on how well Wasp works with AI coding assistants. Opinionated frameworks and AI are a natural fit, and we want to lean into that even more - better tooling, better docs, better integrations.

Polishing the DX + more user-facing features​

Having invested in leveling up the core of Wasp in 2025, we can now reap the benefits and move to the next stage - building cool features you'll see and use! We'll be doing a complete "DX audit", from creating a new project to building and testing it and finally deploying it to production.

Thank you!​

None of this would have been possible without you - our community. You're the ones building with Wasp, pushing its limits, reporting bugs, suggesting features, and showing us what's possible. Seeing you get excited about what we're building, and then taking it even further than we imagined, is what keeps us going.

Thank you for being part of this journey. Here's to a buzzing 2026.

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 tweak things so that you're getting the absolute most out of Claude Code in your projects.

But configuring, testing, and maintaining all these Claude Code features for your specific projects and tools 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 and Wasp when using them together.

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:

1. Add the Wasp x Claude Code Plugin Marketplace:

claude plugin marketplace add wasp-lang/wasp-agent-plugins

2. Install the plugin:

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

3. 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:

1. Using the right documentation — Automatically fetches the correct Wasp docs for your project's version during development and debugging
2. Avoiding common mistakes — Provides Wasp-specific tips, patterns, and best practices so Claude doesn't hallucinate or use outdated approaches
3. Guided workflows — Skills and commands so Claude can walk you through setting up Wasp's batteries-included features: auth, email, database, deploying, etc.
4. 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.

You know that feeling when you're waiting for a package to arrive and the tracking says "delivery delayed until January"? Yeah, we think that sucks, too (thanks so much, Temu).

We've been working on some cool stuff that we're really excited about, and we thought - why make you wait until our next launch week in January when we can give you early Xmas presents instead?

So here's what we're doing: On December 23rd, we're unwrapping 4 new features for the Wasp community. Consider it our gift to you for an amazing 2026! 🎄

Join Us for the Xmas Party! 🎉​

What's a launch without a party? We're hosting a cozy Discord call on December 23rd at 7 AM PT / 10 AM ET / 4 PM CET to unwrap all the gifts together!

We'll be:

• Doing live demos of all 4 new features
• Answering your questions
• Sharing what's coming in 2026
• Having a good time with the community

Make sure to join our Discord and RSVP to the event - we'd love to see you there! Bring your hot cocoa ☕

And now, let's start unpacking! As the olden song goes, "On the Xmas Launch Day, my true full-stack batteries included web framework gave me":

🎁 Gift #1: React 19 Support​

It's here! We're bringing React 19 to Wasp so you can take advantage of all the latest and greatest features from the React team.

People have been asking for this for a while now, and we're excited to finally deliver it:

With React 19 support, you'll get access to some exciting improvements - new Actions and form APIs, a bunch of new hooks, ref as a prop, and more!

🎁 Gift #2: Claude Code Plugin for Wasp​

You're gonna love this one. We keep hearing from so many developers what a great fit Claude Code combined with Wasp is, so we decided to take things one step further - introducing official Claude Code plugin for Wasp!

If you haven't heard of Claude Code plugins yet - it's a way to extend Claude with custom functionality. Think of it as giving Claude superpowers for specific frameworks and workflows.

Here's what it does:

• Knows Wasp inside-out - Plugs in Wasp best practices and points Claude to the right documentation (even accounting for your Wasp version!)
• Guides you through common tasks - Adding auth, email sending, deployment, and more
• Embedded workflows - Common patterns and advice baked right in, so Claude can help you build the "Wasp way"

It's like having a Wasp expert sitting next to you while you code. AI-assisted development just got a whole lot better for Wasp developers! 🤖

🎁 Gift #3: Polar Integration in Open SaaS​

Polar is now the hottest way to add billing to your SaaS. Think of it like Wasp, but for payment systems - it's extremely fast to add and does a ton of heavy lifting for you (subscriptions, usage-based billing, and MoR). It's also 100% open-source, so no wonder we like it!

We're integrating Polar directly into Open SaaS, making it even simpler to start accepting payments and building your SaaS business.

🎁 Gift #4: Wasp News​

Stay in the loop without leaving your terminal! We're introducing Wasp News - a new feature that brings you important updates, tips, and announcements right in your CLI. Never miss a beat with what's happening in the Wasp ecosystem.

All you have to do is run wasp news in your terminal and you'll be up to date!

See You on the 23rd! 📅​

December 23rd is the day! We'll be sharing:

• Full feature announcements with all the details
• Video demos and tutorials
• Fun stuff on Twitter/X

Make sure you're following us so you don't miss the unwrapping:

• Twitter/X - We'll be tweeting all day
• Discord - Join the celebration with the community
• GitHub - Where all the magic happens

That's all for now - we don't want to give away too much! Keep an eye out for the full announcement on December 23rd.

Stay cozy, keep building, and get ready to unwrap some presents! 🎁🐝

Aaaand the results are in! After 10 days of intense vibes-fueled creative energy, we're thrilled to announce the winners of Wasp's first ever Design-AI-thon.

We have to admit - judging was tough. We asked you to reimagine Wasp's website, and you absolutely delivered. Some of you went full Figma wizard mode, others shipped actual working code, and one person even brought in a full vibe-coded OS (more on that later 👀).

Thank you to everyone who participated! Whether you submitted or just followed along, your enthusiasm made this event special. Now, without further ado, let's get to the winners across our three categories: Best Overall Project, Most Fun/Innovative, and Most Technically Impressive.

Best Overall Project 🥇​

Winner: Zeke

When we said "no rules," Zeke took it to heart and delivered a complete overhaul of Wasp's visual identity. We're talking full redesign - new layout, refreshed copy, the works. But what really made this submission stand out wasn't just the end result though it looked great, it was the journey.

Zeke didn't just drop a Figma file and call it a day. He documented his entire thought process, breaking down every design decision, every copy change, and the reasoning behind it all. He even created 6 different drawings of boi!

The attention to detail combined with the comprehensive approach made this an easy pick for Best Overall Project. Zeke clearly put serious time and energy into understanding what Wasp needed, and it shows.

Most Fun / Innovative 🎨​

Winner: Étienne Gagnier

Figma design: link

Remember when we said we wanted something you don't see every day? Etienne delivered exactly that. Imagine if Wasp's website was designed like a developer's notebook, complete with that hand-drawn, sketch-style aesthetic.

It's playful, it's memorable, and it's fun. In a world where most dev tool websites look like they came from the same template, Etienne's design stands out by leaning into personality over polish. The notebook-style approach feels authentic and creative - like you're peeking into someone's actual design process.

This is the kind of out-of-the-box thinking we were hoping to see. It's a design that makes you smile, and honestly, that's exactly the vibe Wasp is all about (next to building web apps).

Most Technically Impressive 💻​

Winner: Adam (bO-05)

See it in action: link

Remember that vibe-coded OS we mentioned earlier? Yeah, this is it. Adam didn't just redesign Wasp's website - he built an entire interactive desktop OS playground where you can explore Wasp like you're using an actual operating system.

We're talking a fully functional virtual desktop complete with file management, a working terminal, notes app, and even an AI-powered chat assistant. Want to save your work? There's optional cloud sync with authentication. Adam literally shipped a whole OS experience for a website redesign competition.

The technical execution here is wild, but what really sealed the deal was how it all comes together with this futuristic, high-vibe aesthetic. It's not just technically impressive - it's cool. You could spend 20 minutes just playing around with it, which is exactly what I did.

Thank You!​

A huge thank you to everyone who submitted - the quality and creativity across the board was incredible. It was genuinely tough to narrow it down to just three winners. Each submission brought something special, and we loved seeing how you interpreted Wasp's personality in your own unique way.

The Prizes​

Our three winners will each be receiving one of these beautifully designed pieces of hardware:

• OB-4 Bluetooth Loudspeaker by teenage engineering
• TRMNL - E-ink companion for your desk
• Playdate - A tiny handheld game system. With The Crank.

Congrats again to Zeke, Etienne, and Adam!

Inspired to build your next app?​

Want to start building with Wasp? Check out Open SaaS - a free, open-source SaaS starter kit built with Wasp that includes authentication, payments, email, analytics, and more out of the box.

What's Next?​

If you want to stay in the loop for future events, challenges, and launch weeks, join us on Discord or follow us on Twitter/X.

Until next time - keep b(uzz)|(ild)ing! 🐝

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

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

The only rule is: there are no rules!

Key things to know​

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

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

FAQ​

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

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

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

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

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

How much of the website should I mock up?​

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

Which tools should I use? Can I use AI?​

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

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

Prizes​

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

• Best overall project
• Most fun / innovative
• Most technically impressive

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

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

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

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

Submission​

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

Judging​

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

• Creativity & thinking out of the box
• How well it showcases Wasp’s playful personality
• Visually pleasing
• Attention to detail
• Fun!

Rules​

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

Additional info​

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

See you there!​

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

Wasp is a compiler-driven full-stack web framework; it takes configuration and source files with your unique logic, and it generates the complete source code your the web app. Think of a Rails-like framework for React, Node.js and Prisma.

As a result of our approach and somewhat unique design, we have a large surface area to test. Every layer can break in its own creative way, and a strong suite of automated tests is what keeps us (somewhat) sane.

In this article, our goal is to demonstrate the practical side of testing in a compiler-driven full-stack framework, where traditional testing intersects with code generation and developer experience.

Our approach to tests​

If we wanted to reduce our principle to a single sentence, it would be: We believe that test code deserves the same care as production code.

Bad tests slow you down. They make you afraid to change things. So our principle is simple: if a piece of test code matters enough to catch a bug, it matters enough to be well-designed. We refactor it. We name things clearly. We make it easy to read and reason about.

It’s not new or revolutionary; it’s just consistent care, applied where most people stop caring.

Tests that explain themselves​

Our guiding principle is that tests should be readable at a glance, without requiring an understanding of the machinery hiding underneath. That’s why we write them so that the essence of the test, the input and expected output, comes first. Supporting logic and setup details follow afterward, only for those who need to understand the details.

spec_kebabToCamelCase :: Spec
spec_kebabToCamelCase = do
  "foobar" ~> "foobar"
  "foo-bar-bar" ~> "fooBarBar"
  "foo---bar-baz" ~> "fooBarBaz"
  "-foo-" ~> "foo"
  -- ...
  "--" ~> ""
  "" ~> ""
  where
    kebab ~> camel = it (kebab ++ " -> " ++ camel) $ do
      kebabToCamelCase kebab `shouldBe` camel

That rule naturally connects to the next one: tests should be descriptive enough that you can understand their essence without additional comments. That’s why sometimes we end up with beautifully long descriptions like this:

spec_WriteFileDrafts :: Spec
spec_WriteFileDrafts =
  describe "fileDraftsToWriteAndFilesToDelete" $ do
    it "should write and delete nothing if there are no checksums and no file drafts" $
    -- ...
    it "should write new (not in checksums list) and updated (in checksums list but different checksum) files drafts and delete redundant files (in checksums but have no corresponding file draft)" $ do
    -- ...

The nice thing about writing tests in Haskell is how easy it is to build tiny DSLs that make tests readable. And for us, reading code is much more important than writing it; we even leaned into Unicode operators for math operations. But the boundary between clarity and productivity can be tricky when you realize nobody remembers how to type “⊆”.

  describe "isSubintervalOf" $ do
	  -- ...
    [vi| [4, inf) |] ⊆ [vi| [3, inf) |] ~> True
    [vi| (3, inf) |] ⊆ [vi| [3, inf) |] ~> True
	  -- ...
    [vi| (inf, inf) |] ⊆ [vi| (inf, inf) |] ~> True
    [vi| [2, 2.5) |] ⊆ [vi| (1, 2.6] |] ~> True

Courage not coverage​

Chasing 100% coverage is fun. It’s complete. But it’s also hard to do. It can push you to spend time testing code paths that don’t really matter. It looks good in the report, but while getting there, you miss out on testing potentially important stuff.

The goal is that our combined tests catch nearly all meaningful errors. We aim for “courage”. Confidence that if something breaks, we’ll know fast.

TDD (but not the one you think)​

We've always liked the idea of test-driven development, but it never really stuck for us. In practice, we’d start coding and only after something worked, would we add tests.

One thing we love is strong typing (we use TypeScript and Haskell), describing what the feature should look like and how data should flow. Once the types make sense, the implementation becomes straightforward. It’s leaning on the compiler to guide you along the way. For us, that rhythm feels more natural, the Type-Driven Development.

Testing the compiler​

At the core of our framework sits the compiler, written in Haskell. It takes a configuration file and user source code as input, and it assembles a full-stack web app as output.

Although Haskell has excellent reliability and type safety (e.g., check out our library for type-safe paths), tests are still necessary. We use unit tests to ensure our compiler’s logic is correct. But the compiler’s most important product is the generated code that exists outside the Haskell domain. To verify the generated code, we use the end-to-end (e2e) tests.

Our E2E tests story​

The purpose of our e2e tests is to verify that the Wasp binary works as expected. We are not concerned with the internal implementation, only its interface and outputs.

The interface is the Wasp CLI (called waspc). Every command is treated as a black box: we feed it input, observe its side effects, and verify the output.

The primary output of waspc is a Wasp app. So we validate that each command correctly generates or modifies an app. Secondary outputs are installer behavior, uninstall flow, bash completions, etc.

Tracking each and every change​

Wasp generates a considerable amount of code, and even small compiler tweaks can cause the weirdest changes in the output — a real-life butterfly effect. We want to be sure that each PR doesn't cause any unexpected changes.

Snapshot tests are the crown jewel of our e2e story. We use it to track the compiler’s code generation changes in the form of golden vs current snapshots. We test the actual (current) output vs. the expected (golden) output.

They are an efficient way to gain high confidence in the generated output with relatively little test code, a good fit for code generation. Because we track golden snapshots with Git, every pull request clearly shows how the generated code changes.

To make it clear what we are testing, we build our test cases from simple:

waspNewSnapshotTest :: SnapshotTest
waspNewSnapshotTest =
  makeSnapshotTest
    "wasp-new"
    [createSnapshotWaspProjectFromMinimalStarter]

To more complex ones, feature by feature (command by command):

waspMigrateSnapshotTest :: SnapshotTest
waspMigrateSnapshotTest =
  makeSnapshotTest
    "wasp-migrate"
    [ createSnapshotWaspProjectFromMinimalStarter,
      withInSnapshotWaspProjectDir
        [ waspCliCompile,
          appendToPrismaFile taskPrismaModel,
          waspCliMigrate "foo"
        ]
    ]
  where
    taskPrismaModel = -- ... details ...

What does this look like in practice? Suppose while modifying a feature, we accidentally added a stray character (e.g., a dot) while editing a Mustache template, which means it will also appear in the generated code. If we now run snapshot tests to compare the current output of the compiler with the golden (expected) one, it will detect the change in the generated files and ask us to review it:

Now we can check the change and accept it if it was expected, or fix it if not. Finally, when we are satisfied with the current snapshot, we record it as a new golden snapshot.

Untangling TypeScript from Mustache​

Mustache templates make up the core of our code generation. Any file with dynamic content is a Mustache template, be it TypeScript, HTML, or a Dockerfile. It made sense as we need the compiler to inject them with relevant data.

While this gave us a lot of control and flexibility while generating the code, it also created development challenges. Mustache templates aren’t valid TypeScript, so they broke TypeScript’s own ecosystem: linters, formatters, and tests.

This inconvenience made our usual development workflow consist of generating a Wasp app, making modifications to the generated files, and carrying over the changes back to the template. Repeat the process until we get it right.

That is why we’re migrating most of the TypeScript logic from Mustaches templates into dedicated npm packages. This will leave templates as mostly simple import/export wrappers, while allowing us to build and test the TypeScript side of the source code with full type safety and normal toolqing.

Testing the Wasp apps​

Besides the compiler, we also ship many Wasp apps ourselves, including starter templates and example apps. We maintain them and update them together with the compiler. Our goal is to test the Wasp apps in runtime, and we use playwright e2e tests for that.

Starter templates​

Typically, every Wasp app starts from a starter template. They are prebuilt Wasp apps that you generate through Wasp CLI to get you started. As they are our first line of UX (or DX?), it's essential to keep the experience as smooth and flawless as possible.

What is most important is to test the starter templates themselves. Each starter represents a different promise that we have to validate. We test their domains rather than the framework itself.

Interestingly, since starter templates are Mustache templates, we can’t test them directly. Instead, we must initialize new projects through the Wasp CLI, on which we run the prebuilt playwright e2e tests.

Example apps​

Starter templates get you started, but Wasp features so many more features. To test the entire framework end-to-end, we had to build additional Wasp apps — example apps. They serve a dual purpose: to serve as a public examples of what can be built with Wasp and how, but also as a testing suite on which we run extensive tests.

We test each framework feature with playwright. On each PR, we build the development version of Wasp, and each example app runs its e2e tests in isolation. While golden snapshots provide clarity into code generation changes, these tests serve to ensure none of the framework features' expectations were broken.

Kitchen sink​

The kitchen sink app is the "holy grail" of example apps. We test most of the framework features in this single application (smartly named kitchen-sink ). If you’re not familiar with the term “kitchen sink application”, think of it like a Swiss knife for framework features

Kitchen sink is also one of the applications we snapshot in our snapshot tests. So, kitchen-sink not only serves to test that the code works in the runtime, but also tracks any changes to the code generation.

We have one golden rule when modifying/adding framework features: “There must be a test in the example applications which covers this feature.”

When Kitchen Sink is not enough (or too much)​

Previously, I mentioned that kitchen-sink tests most of the framework features. Most — because Wasp has mutually exclusive features. For example, usernameAndPassword authentication vs email authentication (yes, email authentication also uses a password, I didn’t design the name). So we try to pick up the scraps with the rest of the smaller example apps.

While the kitchen-sink application is suitable for showcasing the framework's power to users, it’s impossible to test all of the features in a single application. Nor is it the proper way to test Wasp end-to-end.

This is how our “variants” idea sparked. The idea is to build variants on top of the minimal starter. E.g., “Wasp app but using SendGrid email sender”, “Wasp app but using Mailgun email sender”…

For each possible feature that exists, a Wasp application of that feature should exist. It's something we haven't yet solved, but we plan to address it as we approach the Wasp 1.0 release. For now, the kitchen-sink app serves us well enough.

Building tools for your tests​

Wasp applications are complex systems with many parts: front-end, back-end, database, and specific requirements and differences between the development and production versions of the application. This makes test automation cumbersome.

You can do it, but you really don’t want to repeat the process. So we’ve packaged it into our own driver called wasp-app-runner. It exports two simple commands: dev and build. It’s not suitable for development purposes (nor deployment), but for testing, it’s perfect. Tooling for your tests is tooling for your sanity.

Testing the deployment​

Wasp CLI can automatically deploy your Wasp applications to certain supported providers. You set the production environment variables, and the command does everything else.

To ensure deployment continues to work correctly, each code merge on the Wasp repository triggers a test deployment of the kitchen-sink example app using the development version of Wasp, followed by basic smoke tests on the client and server to confirm everything runs smoothly. Finally, we clean up the deployed app.

When releasing a new version of our framework, we follow the same procedure described above, but for all the example apps, not just the kitchen-sink one: we redeploy their test deployments using this new version of the framework. However, these deployments remain permanent, as we use example apps to showcase Wasp to users.

Testing the docs (kind of)​

APIs change fast, in a startup building a pre-1.0 framework. Documentation lags even faster. You tweak a feature, push the code, and somewhere, a forgotten code example still lies.

We’re careful about updating documentation when features change, but some references hide in unexpected corners. It’s a recurring pain: docs are the primary way developers experience your tool, yet they’re often the easiest part to let rot. So we started treating documentation more like code.

Keeping code examples honest​

You modify a feature, update the API, but some part of the docs still shows an old example. Users (and I) prefer copy-pasting examples over reading API documentation. We copy and paste broken snippets and expect things to work, but they don’t.

Wouldn’t it be nice if docs’ code examples were also tested like Wasp app examples? Why not combine the two?

We agreed that the docs examples must reference the source code of example apps. Each code snippet in the docs must declare a source file in one of the example apps where that same code resides (with some caveats). We can automatically verify that the reference is correct and the code matches; if not, the CI fails.

We are implementing this as a Docusaurus plugin called code-ref-checker. It’s still a work in progress, but we’re happy with the early results (notice the code ref in the header):

```ts title="src/auth.ts" ref="waspc/examples/todoApp/src/auth/signup.ts:L1-14"
import { defineUserSignupFields } from "wasp/server/auth";

export const userSignupFields = defineUserSignupFields({
  address: (data) => {
    if (typeof data.address !== "string") {
      throw new Error("Address is required.");
    }
    if (data.address.length < 10) {
      throw new Error("Address must be at least 10 characters long.");
    }
    return data.address;
  },
});
```

An additional benefit is that, besides ensuring code examples in the docs don't become stale, it forces us to test every feature, because when we write documentation and add a code example, it can’t exist without implementing it first inside an example app.

Making tutorials testable​

We have a “Todo App” tutorial in our documentation that, before every release, we would manually review and verify to ensure it was still valid. Someone would have to execute all the steps, and once they finally finish them, they would still have to test the resulting Wasp app.

While code-ref-checker solved the examples drift, tutorials add a time dimension. They evolve as the reader builds the app: files appear, disappear, and change with each step. So we opted for a new solution.

Looking at our tutorial, each step changes the project: run a CLI command, apply a diff, and move on. We realized the tutorial basically repeats those two actions over and over.

So we built a small CLI tool integrating with the Docusaurus plugin to formalize that process:

1. Each step defines an action.
2. The CLI can replay all steps to rebuild the final app automatically.
3. Steps are easily editable in isolation.
4. That final app is then tested like any other Wasp app.

We call it TACTE, the Tutorial Action Executor.

In TACTE, each step is declared via a JSX component that lives next to the tutorial content itself, and the CLI helps us define the actions to make the process work.

To setup a new Wasp project, run the following command in your terminal:

<TutorialAction
  id="create-wasp-app"
  action="INIT_APP"
  starterTemplateName="minimal"
/>

```sh
wasp new TodoApp -t minimal
```

# ...

Start by cleaning up the starter project and removing unnecessary code and files.

<TutorialAction id="prepare-project" action="APPLY_PATCH" />

First, remove most of the code from the `MainPage` component:

```tsx title="src/MainPage.tsx" auto-js
export const MainPage = () => {
  return <div>Hello world!</div>;
};
```

TACTE is still in development, but we are planning to publish it as a library in the near future.

Conclusion​

See Our approach to tests.

Anybody remember RuneScape? Martin and I spent a solid part of our high-school years on it (no regrets). What better way to spend your Friday evening than catching a bunch of fresh lobbies, cooking them nicely, going to the town square, and selling them for 250 ea?

If our last quarter were RuneScape, we've been patiently grinding and leveling up: making things easier to build and test (starting with ourselves), and deploy. No super big fancy features this time, but everything you know and love about Wasp just got better. And that will help us add more, bigger and fancier things in the future, faster.

So the time has come to count the loot and show the XP we gained - welcome to Launch Week #11.

(If you never heard of RuneScape, I'm sorry. Just imagine I mentioned your favorite MMORPG. If you don't know what that is, then I'm really sorry).

The raid starts on Oct 6, Monday - bring your bows, swords and staffs!​

There's no launch party without a nice, cozy community call to kick it all off! We'll assemble in exactly one week, on Monday, October 6th, 8 AM PT / 11 AM ET / 5 PM CET. Make sure to register in our Discord to secure your spot in this epic raid (yep, pushing this MMORPG theme)!

Day #1: 🐲 The Loot AKA new features - here's what we took from the dragon!​

I actually think it's not very nice to steal stuff from dragons. I'm sure some of them worked quite hard to get all that treasure and organise it nicely in their cave (maybe even used a label maker), and then a bunch of drunken dwarves shows up and starts waving their axes and yelling like crazy.

Dragon rights and prejudices aside, on Monday we'll present everything new we added to Wasp. The star of the show is wasp build start - a new CLI command that let's you test your production build locally before you deploy your app. That way you can catch dependencies on your local environment and stuff that's otherwise easy to miss (before your users see it), like a missing environment variable which you set only locally.

We also shipped a bunch of QoL improvements and bug fixes - e.g. Node.js and Vite versions got bumped and we switched to ECMAScriptModules instead of CJS for Tailwind config files. Not to spill all the gold - more on the day itself!

Day #2: 🔧 Under-the-hood day - an unexpected journey of testing a full-stack framework: CLI to example apps​

Well, it was kinda expected - stuff has to be tested. What was probably less expected is how much work and effort will go into this. But, engineers are famous for underestimating so that was also expected in the end. Still, I needed a cool fantasy inspired subtitle (from The Hobbit, for the uncultured goblins) so here we are.

Anyhow, if you enjoy tasting in all its flavors, this one is for you. We've got everything from unit tests and snapshot testing all the way to Playwright e2e tests. And then you also need to orchestrate it all in the CI, and add invariant testing in the future. Sounds like fun, no?

I can't think of a better way to end your Tuesday.

Day #3: 🔦 Community Spotlight Day - Live Demos! 🎙️​

What we started the last Launch Week has become a tradition by now (we move fast): we give spotlight to you, Wasp builders!

We selected a few of amazing community members and builders who will share what they built (live demo, woohoo!), what it took, and how Wasp helped in the process. And you get to ask them questions, too!

Nothing better than to share stories over a barrel of finely aged meadow with fellow warriors and dragon-slayers - make sure not to miss this one!

Day #4: 🧩 Ecosystem day - Even more Railway + welcome Mastra - a Langchain for JS!​

You all know the old adage: "A web framework is only worth as much as you can integrate it with other tools in the ecosystem." And who are we to say anything to that, but to keep adding more!

Deploy OpenSaaS template to Railway with one click!​

During LW #10 we announced a native integration with Railway in Wasp's CLI, allowing you to deploy your Wasp app with a single CLI command. Now, Railway has returned the favor - Open SaaS is one their verified template starters! You can take a look at it here.

That means you can deploy a fully working Open SaaS app to production even before you start writing any new features. This greatly speeds up the feedback loop and makes it incredibly easy to deploy as often as possible. High five, Railway!

Welcome Mastra - the best way to lang your chain in JS!​

We love trying new things and figuring out the best ways to use them in Wasp. Especially if its open-source and you can easily self-host it. Mastra checks all the boxes and we kept hearing about it, so Vinny finally gave it a go!

The result is, of course, an app. And it's something like you've never seen before - a recipe app! 🤯🤯

The cool part about Mastra is that it gives the AI part of your app a neat structure and a bunch of features you'd otherwise have to (re)invent yourself. It's actually kinda like Wasp, but for the AI.

Full video tutorial coming on Thursday!

Day #5: 🤖 AI/Vibe-coding day - Open SaaS x Claude Code = Magic 🧙​

Everybody keeps talking about the best stack for AI-assisted coding (or "vibe-coding", as the cool kids call it), and Claude Code has definitely become a front-runner lately. And being curious as we are, we also gave it a go and did our best to figure out the best workflow to use it with Open SaaS.

We collaborated with one of our favorite creators on this one, and some of you already might know him from the community and videos he made previously. This is one of his most extensive tutorials so far in which he builds a full-stack app from scratch (not a recipe app, I promise. It's a todo list, of course), so stay tuned!

Day #6: 🎨 Design-a-thon - redesign our landing page and win cool prizes!​

It's been a while since our last hackathon, so we decided it's about time to bring it back up. And this time, it's a bit different - we're not asking you to code, but design (using all the AI you want, of course)! We're looking to refresh Wasp's brand and we thought what could be better than to ask our community to have fun with it? We will reward the best ideas and use them as an inspiration (aka steal team) for our upcoming rebrand.

More details on everything (the process, awards - they will be well designed, that much I can share) coming soon.

See you there, player!​

Thanks so much for reading! We hope all (or at least some) of this sounds interesting and that you will join our Launch Week! As always, we're very much excited about all and any feedback and you might have for us, so please share it with us whenever - on Discord, Twitter/X, GitHub - you name it, we're there!

And, as usual - to stay in the loop, follow us on Twitter/X and join our Discord - game on! 🐝🐝

We’re building Wasp, a full-stack web framework the sweats the details and the boilerplate, so you go straight into building. It’s like having a senior engineer set up your architecture (server APIs, client routing, authentication, async jobs, and more!), so you focus only in the interesting parts of your app. Try it out!

Have you ever heard the expression the cobbler's children alway go barefoot? Lately, it has felt a little too close to home. We’re so focused on working for you, that at times we forgot to work for ourselves!

But in this Launch Week, the team has taken some time between shipping features and fixing bugs, and looked at the tools we were using ourselves. What we found won't surprise you: the process by which we build Wasp needs a serious tune-up. Our features have changed a lot from the initial to-do apps, to the real projects that are shipping today; made by hobbyists, startups, and enterprise. Now, we need to update our approach for our current scale, without losing our open identity.

So… we’re giving you a tour!

As an open-source project you can see all of our warts (and all of our genius code) by yourself, whenever you want. But today we’re taking you on a guided tour as we inspect our own engine. It’s about time your cobblers stopped walking around barefoot and get themselves some decent shoes!

First stop: coding faster​

The speed at which we can write robust, testable code directly impacts the speed at which we can deliver new features to you. Our foundation is functional, but as we're ramping up, some parts are holding us back. We've targeted two key areas for a complete overhaul.

From brittle templates…​

Here’s a fun fact: the Wasp compiler creates your app by analyzing your code and processing a bunch of Mustache templates¹:

const defaultViteConfig = {
  base: "{= baseDir =}",
  plugins: [
    validateEnv(),
    react(),
    detectServerImports(),
  ],
  server: {
    port: {= defaultClientPort =},
    host: "0.0.0.0",
    open: true,
  },
  // etc
}

When you run wasp start, we read your .wasp files and stitch together your app by surgically inserting your code into these templates. This approach got us off the ground, but it can be painful². Here, let me show you what that template actually looks like in our editors:

Yeesh... templates are very unpleasant to maintain at scale. Can you think of all the nice features you have in modern JS land?

• Linting
• Import checking
• Automated refactoring
• Autocompletion
• Type-checking 🫨

Yeah, we have a hard time with those. With templates you can't easily test in isolation, reasoning about logic is a chore, and editor tooling offers little help.

To ensure a change doesn't break anything, we usually have to build an entire Wasp app that uses a specific feature just to test and type-check the generated code downstream. At times, it is slow and painful, a cycle of "change, generate, dig through the output". And unsurprisingly, this dance discourages community contributors.

…to bulletproof libraries​

So now, we’re planning to systematically pull this system apart, and replace our template pile with standalone TypeScript libraries. Just normal libraries. This way, we can work on them with familiar, battle-tested tools. Instead of templating thousands of lines of code, the Wasp compiler will only have to stitch together our provided libraries, for different features of your app. Maybe in just a couple of lines.

For you, our users, this process will be entirely transparent. We’re still taking advantage of having a smart compiler that knows about your app. And we're not planning to make you install a hundred different libraries, don't worry! The Wasp libraries will be a completely internal implementation detail. But thanks to it, you'll see your builds becoming faster and more robust.

This is a big undertaking, but the payoff will be a more stable, testable, and performant Wasp compiler. For us, it means faster, more confident development. For you, it means a more reliable tool that we can build upon for years to come. You can follow this epic refactor on our public GitHub issue.

Killing the app sprawl​

Just a few months ago, our internal project landscape had become a sprawling affair. We had three distinct starter templates scattered across two different repositories; plus four separate, independent "example" apps that we used for internal testing.

That was... annoying. Keeping everything in sync with the latest version of Wasp was a manual chore. A change in the compiler required hopping between repos, and hoping we didn't miss anything-a perfect recipe for version drift.

But, when Earth most needed them, Franjo and Miho came through!

First, we consolidated the starters. We now have two, and only two, official starters, living directly inside the main Wasp repo: one for a basic app with guidance on enabling common features, and a minimal one for users who know exactly what they want. Gone are the super-specialized starters that saw basically no usage. Don't worry though, OpenSaas and Mage are still offered in wasp new to help you with more advanced needs.

Second, our four separate test apps have been merged into a single, comprehensive "kitchen sink" example project. And instead of having to know a route for a specific test, the app is well laid out and explained. And this app is covered by a suite of end-to-end tests that run against every single pull request.

Monorepo for the win!​

By co-locating the compiler, starters, and test apps in a single repo, everything evolves in lockstep. We can make a change to the compiler and instantly update and validate it against our starters and test suite. No more context switching, no more repo-hopping, no more "did we update the X starter?". Just a clean, consolidated, and thoroughly tested codebase.

Second stop: testing faster​

Testing shouldn't be an afterthought, but it also shouldn't be a pain. We realized our internal testing workflows were full of friction, friction that we could remove not just for ourselves, but for every Wasp developer.

Introducing wasp build start, a dress rehearsal for your app​

How do you really know your app is ready for production? The wasp start dev server is great for development, but a production build is a different beast - assets are bundled and optimized, environment variables are handled differently, and the server runs in a hardened mode.

Internally, our method for testing this is a collection of ad-hoc scripts. First of all, these rely on you knowing Filip and asking him for his scripts. And second, they depend on our developer machines’ setups, and that's not something we could ever ship to you. We need a first-class solution.

That’s why we’re developing a new CLI command: wasp build start. This command will take your built production output (the result of wasp build) and start your app locally, using the generated client files, and the server Docker container. It’s a one-step dress rehearsal for your deployment.

This lets you debug production-only issues on your own machine, long before your users do, running the app in the same way that it runs when deployed. That is perfect for the internal team, but the tool will also be available to everyone soon. You can track its development here.

Smooth deployment makes a smooth launch​

Wasp aims to make deployment a breeze, but how could we be sure our deployment adaptors for providers like Fly.io and Railway were always up-to-date? A subtle API change on their end or a small bug in our Dockerfile could break the process without us knowing. Of course, we test it, but doing it manually can risk us missing stuff.

To solve this, we built an automated testing pipeline specifically for deployments. This system will automatically deploy our example Wasp apps to our supported providers on a regular basis. It will act as a continuous smoke test for our entire deployment story.

This means we can:

• Instantly catch regressions caused by our own changes.
• Proactively detect breaking changes from hosting providers.
• Guarantee that our documentation and deployment templates are always accurate and working.

We have some example apps that we deploy with the latest changes:

• Waspello (from this blog post)
• Waspleau (from this blog post)
• Websockets Voting (from this blog post)

This isn't just about testing our code; it's about testing the entire ecosystem you rely on. You can see the plan for this initiative on GitHub.

Third stop: release faster​

Our current release process is, to put it mildly, long. You can see the checklist for yourself. It's a long document with dozens of manual steps:

• Running local scripts
• Bumping version numbers across npm and cabal files
• Drafting changelogs
• Creating git tags
• Testing apps
• ...and more

A major release can easily consume a full day of an engineer's time. If bugs are found, it can extend to more days and more engineers. It is a tedious, high-stakes process where one wrong move derails the whole thing. This manual toil can be a bottleneck - and from the ones I've done, nerve-wracking!

We are now on a mission to automate every possible step. We're building a new system to handle the entire process. This involves automatically bumping versions, creating the changelog, testing everything, and publishing our releases.

The goal is to transform our release process from a day-long manual slog into a single, push-button operation. This means more frequent, more reliable releases, getting bug fixes and new features out of our door and into your hands faster than ever. Follow the automation effort here.

Now it's your turn to go fast​

We're sharpening our own tools so we can build better ones for you. These internal improvements -a modern codebase, streamlined testing, and automated releases- are all designed to shorten the distance between an idea and a shipped feature in your hands.

And because Wasp is an open-source citizen, we can take advantage of our community input, learn from other frameworks, and work in the open.

We've shown you our warts, but the cobbler's workshop is finally making some top-quality shoes for the family. We're getting faster so you can be faster.

Now, go build something amazing. Try Wasp today and see how fast you can really move.

But don't take our word for it. Here are three founders, in their own words, that use Wasp and its free Open SaaS template to turn their ideas into successful SaaS apps, fast.

Case Study 1: Kivo - Democratizing Data Reporting​

The Challenge​

Data analysis is messy. Dimitris, one of Kivo's co-founders, was tired of juggling countless tools (Excel for data, Python for analysis, and Word for reporting). He knew they could simplify the whole data analysis pipeline.

The Solution​

Kivo is a beautiful, unified platform for creating data-driven reports. Think Notion, but with powerful, AI-assisted data editing capabilities built right in. You upload a file, Kivo helps you clean it, and you can generate full reports, charts, and more using prompt-based tools.

How Wasp Helped​

For Kivo, speed was everything. They needed to build a complex, data-intensive application with a small team.

• Rapid Development: Wasp allowed the team to go "from zero to one real fast" while Open SaaS took care of the SaaS-specific boilerplate.
• Powerful Backend: Wasp's integrated APIs and background Jobs made building their data processing and report generation pipeline 10x faster.
• The Founder's Take: "The reason that Kivo is a reality is because of Wasp."

Kivo is an impressive app and proof that a small, focused team can build a sophisticated product when the framework handles the heavy lifting.

// This is how easy it is to add a custom API endpoint to your Wasp app. 😎

api fooBar { 
  fn: import { fooBar } from "@src/apis",
  httpRoute: (GET, "/foo/bar")
}

Case Study 2: MicroInfluencer - Finding Niche Creators with Precision​

The Challenge​

How do you find the right influencers? For marketers, finding and vetting a creator that will be a good fit for your product can be a massive cost.

The Solution​

MicroInfluencer is a smart analytics and research platform that helps brands discover and vet niche creators. It uses an AI-powered search to provide deep, data-driven statistics that reveal a creator's true value.

How Wasp Helped​

As a solo founder, Cam needed the agility to pivot and iterate quickly.

• Frictionless Pivoting: Wasp's structure on top the Open SaaS template allowed him to quickly rebuild his SaaS from a marketplace into the powerful analytics and discovery tool it is today.
• The Perfect "Battery": He calls Wasp's Cron Jobs his favorite feature and the backbone of the app. They run constantly to keep creator data fresh and even power an automated B2B lead generation system. He was able to add the AI search feature in just one evening.
• The Founder's Take: "I think it is just the frictionless features like Cron Jobs. Just how quickly you can get something up and running that is genuinely so commercially useful."

MicroInfluencer shows how Wasp gives solo developers the space and leverage to build data-heavy, commercially valuable applications without a big team or budget, but just some free time and determination instead.

// This is how easy it is to add a cron job to your Wasp app. 😎

job mySpecialJob {
  executor: PgBoss,
  perform: {
    fn: import { foo } from "@src/workers/bar"
  },
  schedule: {
    cron: "0 * * * *",
  }
}

Case Study 3: CTO Box - Empowering Engineering Leaders​

The Challenge​

Most engineering managers lack purpose-built tools for crucial tasks like running effective 1-on-1s or building clear career ladders, often relying on messy spreadsheets and random templates.

The Solution​

CTO Box is the toolkit that founder Sergio, a long-time engineering leader, always wished he had. It's a focused app that helps managers run better dev teams with structured 1-on-1s, AI-powered action items, and a dedicated career ladder builder.

How Wasp Helped​

Sergio wanted to build his solution without falling into the "hobby project curse" where endless boilerplate kills your motivation.

• Overcoming Boilerplate Fatigue: The Open SaaS template was the "killer feature" for him. It provided the foundation (auth, DB, payments) he needed to get started immediately.
• Focus on What Matters: Wasp let him focus on the important features and get feedback from real users to iterate on.
• The Founder's Take: "It allowed me to just jump into the idea and forget about the boilerplate code."

CTO Box, which is still in private beta (but now accepting waitlist signups), proves that with the right foundation, you can finally build that tool you've always needed and get valuable feedback to bring it to market before you run out of steam.

Your Turn to Build​

The common thread here is simple: Wasp provides momentum and allows builders to focus on the unique features of their app.

By handling the boilerplate, it empowers developers and small teams to build, launch, and iterate on complex applications faster than any other framework.

If you've been sitting on an idea, let these stories be your inspiration:

• Get started by installing Wasp
• Then pull a fresh Open SaaS template with wasp new -t saas
• Check out the Docs for more info

Why Railway?​

Railway recently introduced Railway Metal which is their cool way of saying they have their own independent infrastructure. They’ve been able to optimize their server costs and lower the prices for everybody. This makes Railway not only a powerful and stable platform but also a very reasonably priced option for many projects.

That’s why we are excited to announce that we added support for Railway one-command deployment to Wasp! (Fun fact: This is provider #2, Wasp CLI already had one-command deployment with Fly.io.)

How it works​

Wasp takes the Railway experience a step further by giving a Wasp-specific deployment command. Instead of manually configuring each service of your application (the database, the server and the client), Wasp orchestrates the entire deployment with a single command:

See it in action​

Here's a a 30-second video to showcase how simple it is to deploy a Wasp app to Railway - it takes a single CLI command and ~3 minutes!

All you need to do is run "wasp deploy railway launch". Behind the scenes, the Wasp CLI:

• Deploys a PostgreSQL database
• Sets up your server
• Deploys your client application
• Wires everything together with the environment variables

This is how your Wasp app looks in the Railway dashboard after deploying

After the deployment process finishes you’ll get a URL to your client app which you can share with your grandma. Time to get those cookies as a reward!

Deploy your app to Railway today​

We are shipping this feature with the latest Wasp 0.17.0 version.

If you want to deploy your app to Railway:

1. Make sure you have the latest version of Wasp installed
2. Register for Railway and download their CLI
3. Navigate to your Wasp project directory
4. Run the command: wasp deploy railway launch <your-project-name>

That's it! Your application will be deployed to Railway, complete with database, server, and client services all properly configured and connected.

For more details on deploying your Wasp apps with Railway, check out our deployment documentation.

Use it today and speedrun your app deployment with Wasp. We can’t wait to see what you build next!

Read on to learn about the Why, How, and What of the roadmap.

Why the public dev roadmap​

So far, this is how we've been doing our planning at Wasp:

• Each quarter, plan quarterly objectives for the next 3 months, with the big vision in mind.
• Each sprint, plan sprint tasks for the next 2 weeks, with the quarterly objectives in mind.

The tricky part was, that while we always had a big plan and vision in our minds, it was always somewhat implicit, an oral tradition among the team members. There'd be multiple, quite similar but different "big planning" pages on Notion with ideas and prioritized features that would quickly become outdated, and new Notion pages would replace them.

And it made sense: Wasp was changing fast, we were ideating, experimenting, and the team was small enough.

But, that changed: our team grew to 8 people (and will grow more), ideas stabilized, Wasp itself grew more complex, people building with Wasp (aka Waspeteers) started asking more often when is which feature coming, and finally, we put our focus on the 1.0 release of Wasp and planning for it.

So that's why we're introducing our public development roadmap!

Firstly, it makes our plans transparent, allowing everybody to know what to expect for Wasp's future and what they are betting on when investing their time into it, and secondly, it also serves as a central, living place for our "big" plan. It also shifts our quarterly planning from "big replanning" to just adjusting the roadmap.

The How of the roadmap​

Check the Wasp repo and you'll see that we track all our ideas as GitHub issues.

Existing feature improvements, crazy experimental ideas, new big features, documentation improvements, discussions, stuff that annoys us, bugs, …. If you wonder about how we plan to support something in Wasp in the future, there is a fair chance you will find the GitHub issue for it in our repo.

So, where did we decide to put the roadmap tasks? Well, in GitHub issues, of course!

We decided to implement the roadmap as a GitHub project that is a collection of epics (GitHub issues with "issue type" of "Epic").

No regular issues are allowed in it, only epics, and there can't be too many, a couple of dozen. These epics then have subtasks which are normal Github issues.

Therefore, the roadmap serves as a high-level overview of how we plan to execute on all those GitHub issues of ours that we already had.

What is in the roadmap: Wasp 1.0, AI, wild ideas & more​

The big motivation for creating the roadmap was planning for the 1.0 release of Wasp: we felt like we knew enough at this point to make a detailed plan of everything that should be a part of the 1.0 release; therefore, most of the epics are labelled with the 1.0 milestone.

We also added a couple of epics that are still in the idea stage but that get mentioned/requested regularly or that we are excited about, like access control ((RBAC/ABAC), modular database (imagine choosing between Drizzle and Prisma), Wasp Studio, ….

It’s hard to ignore AI these days, so you will also find the epic for ensuring the best experience in Wasp when using it with vibe/AI-assisted coding: starter Cursor/Claude rules for a fresh Wasp project, llms.txt, Wasp MCP, ….

The dominant bulk of the roadmap is 1.0-focused epics, though, and we can roughly divide them into a couple of big categories:

• ✅ The essentials
• 🚀 Main features
• 🧪 Experimental features

✅ The essentials - getting it right​

The focus here is on getting the core parts of Wasp, both internal and external, in order and working great for everybody using it and for us while developing it.

While developing pre-1.0 Wasp, a big part of what we do is trying out new concepts and ideas and making sure they work well together (e.g., DSL, code generation, integrated Auth, TS spec, query invalidation based on entities, …).

Since this means that we often do things in a non-standard way for a typical web framework (that is kind of our thing), it also means that we sometimes get non-standard rough edges as a result.

Once those accumulate somewhat and we learn more about them, it also becomes clear how to solve them, and that is a big part of what we are doing here.

To give you an idea, some big epics here are:

• Making Wasp "right": polishing rough edges regarding the IDE support, standard config files for JS projects, how the generated Wasp project is structured internally (e.g., start using npm workspaces), …. A lot of stuff you don’t see if it works as it should, but will notice if it is not.
• Polishing basic DX: with time, we learned a lot about all the little bumps on the road to using Wasp, and while we try to fix them regularly, we often prioritized working on bigger features. Now is a good time to take a look at all those together and do a big clean-up!

🚀 Main features - leveling up!​

The main features of Wasp (Operations, Entities, Jobs, Auth, …) have been stable for some time, and we learned a ton about them in the recent period, both based on our usage and also based on the feedback and questions from all the awesome people in our community (Discord, Github) that are using Wasp.

For each of the features, we now have a clearer plan of where we want that feature to be for 1.0; therefore, most of these epics are about taking the existing features to the next level.

This means expanding them (e.g. adding account merging to Auth), fixing rough edges (e.g. more flexibility when using web sockets), and also redesigning and rethinking some central parts (e.g. Operations, Custom API, and their relationship) while keeping what you all like the best about them and doubling down on improving the parts that could be better.

🧪 Experimental features - Full Stack Modules, Wasp Studio, …​

We have some ideas that we have been mulling over for a long time, always considering them, but despite our excitement, we haven't found the time to prioritize them so far.

Some of those that we feel are both ready and important enough for shaping up Wasp into 1.0, we added to the roadmap!

A big one is FSMs (Full Stack Modules), a concept we have been discussing for years now: "Oh yeah, this will likely be solved by FSMs", or "We could just extract this part into an FSM once we have them".
FSMs will be a way to define pieces of Wasp apps (e.g., file uploading, Stripe integration, or AI chat) in a modular and distributable way, spanning the whole stack, from frontend to the database (Imagine Ruby on Rails Engines, but in Wasp style)! Libraries/packages, but truly full-stack. Will it work? We don’t know yet, but if it does, it could be awesome!

Where next​

We are inviting you to follow the roadmap, share feedback, and contribute!

Let us know if there is something that you think should be on the roadmap but is missing, if you would do something different, or if you think one of the epics we picked for the roadmap is a great choice and we should double down on it.

You can comment directly on our GitHub project/issues, or in our Discord where the whole Wasp team is very active.

If a specific epic particularly interests you, you can subscribe to it easily: click on “Subscribe” at the bottom of the sidebar on the right of the GitHub page for that issue.

Also, let us know if there is some other part of Wasp besides the roadmap that you would like to learn more about and get more transparency into!

In the future, we plan to regularly update the roadmap as we work on epics, refine them, and release them, and also on a quarterly basis or on demand as we possibly replan parts of the roadmap.

p.s. You will notice there was no mention of Open SaaS, our flagship Wasp starter template, in the roadmap; that is because Open SaaS has a development cycle of its own. You can find all the plans for OpenSaas in its Github repo, though (e.g., there are plans for adding more payment providers soon), and we will, as always, also be updating it with every new version of Wasp so it uses the latest and greatest (imagine Open SaaS using FSMs → woah!).

Evening, Waspeteers. The web dev city have been awfully quiet lately. A bit too quiet for my taste (going for the noir vibes in this one 🧥 🔍).

But not for long—we're back! Not more, not less, but with exactly Launch Week #10. Since our beloved mascot has been wandering the streets and harassing passersby with its latest news, let's see what that's all about.

As always, we’re throwing a community call where we’ll celebrate and show you what we're launching. It will take place next Monday, July 14th, 7.30 AM PT / 10.30 AM EDT / 4.30 PM CET! To reserve your spot, visit the event in our Discord and mark yourself as interested.

Day #1: 🗺️ Wasp 1.0 Roadmap - it's finally here! 🎉🎉​

We open it up with a big un' right off the bat - Wasp's public roadmap for getting to 1.0, and beyond!

As we shared during the last Launch Week, we knew it was time to sit down, reflect, and re-examine every aspect of Wasp starting from the fundamentals. And being only as good as our word, that’s exactly what we did! Behold the Wasp Roadmap:

We'll explain everything in more detail next week, but you can already give it a peek here.

Day #2: 🧩 Integration day - native CLI support for Railway + Slack auth!​

Who doesn't like a nice, cold integration after a long day at work? I sure do, pal, and I'm pretty sure y'all do, too. That's why we're bringing Railway deployment via Wasp CLI and Slack Auth!

While we've had a native CLI integration for Fly for a while, Railway has proven to also be an amazing deployment platform. Besides the ease of use, their unique GUI approach to visualizing your resources is really cool!

Join us for the community call on Monday (or just follow us on Twitter/X) and learn all about it!

Day #3: 🔦 Community Spotlight Day - Live Demos! 🎙️​

We all know it by now - Wednesday is where we stop talking about Wasp and how we'll finally make it "right" and focus on you, the builders!

But, this time, we have something special - live demos by amazing folks building their apps with Wasp & OpenSaaS! We went ahead and asked a couple of our community members who have been sharing their work with us for a while to join us on a call, and they all said yes!

They will give us a 3-minute demo of what they're building, share how they got their first customers, why they chose Wasp and what they'd like to see next. You will also get to ask them questions and chat with them during the call!

Day #4: 🎨 Open SaaS 2.0 - a complete redesign + ShadCN!​

Since we launched Open SaaS less than two years ago, it has quickly become one of the most popular open-source SaaS starters, with over 11,000 stars on GitHub.

During that time we kept improving the template, and adding new features and integrations. But we also learned from you, watching you build and understood how we can make it better. We realized that the professional looks and the design of the template is equally important as how it works under the hood (which is via Wasp, of course).

That's why we decided to partner up with an extremely talented designer, Fran, to bring you a fresh, sleek looking redesign of Open SaaS! Along with the revamp, we're also introducing ShadCN as a default component UI library.

We'll celebrate by launching Open SaaS on Product Hunt - stay tuned!

Day #5: 🏎️ Under-the-hood day - Making Wasp Dev Faster​

We reserved the final day of our Launch Week to introduce a new category to the roster - sharing with you how things at Wasp work on the inside!

Along with the whole rethinking of Wasp as a framework, a logical topic that appeared next to it was how we as maintainers contribute to and develop Wasp. How we release, how hard is it, and how we can make it easier?

As a result, we realized that after five years of building there is a lot of technical debt there and we decided to put some serious effort into it. We will share all about how we test, build and release your favorite framework (it better be Wasp), and as a bonus you will learn where Wasp logo comes from (hint: Mustache)!

That's it - bee there! 🐝​

Thanks so much for reading! We hope all (or at least some) of this sounds interesting and that you will join our Launch Week! As always, we're very much excited about all and any feedback and you might have for us, so please share it with us whenever - on Discord, Twitter/X, GitHub - you name it, we're there!

And, as usual - to stay in the loop, follow us on Twitter/X and join our Discord - let's buzz that pizzazz! 🐝🐝

On May 23rd, 2025, we learned about a security vulnerability in Wasp auth related to our OAuth support in Wasp 0.16.5 and earlier. Users with same IDs with different casing (e.g. abc and ABC) were considered the same person which could lead to users gaining access to other users' accounts.

Only users using Keycloak with non-default case-sensitive IDs are affected.

All other configurations (Google, GitHub, Discord, or Keycloak with the default case-insensitive configuration) are not affected. Email and username auth providers are also not affected.

Users should upgrade to Wasp version 0.16.6 which contains the fix. Affected Keycloak users will need to migrate their user IDs in the database.

Description​

Wasp has a concept of a ProviderId which contains the provider name and the provider-specific ID.

For example:

• (email, alice@wasp.sh) for Email auth
• (google, 10769150350006150715113082367) for Google auth

Wasp takes the provider-specific ID (the second part), converts it to a string and lowercases it to keep the IDs normalized.

This approach made sense for:

• email - emails are case insensitive (e.g. you can't signup for Gmail with johnnY@gmail.com if johnny@gmail.com already exists)
• usernames - we don't want users to impersonate each other with similar usernames

However, the OpenID spec states the following for the sub property (which we use for OAuth as user ID):

REQUIRED. Subject Identifier. A locally unique and never reassigned identifier within the Issuer for the End-User, … The sub value is a case-sensitive string.

Treating the ID we receive as case insensitive violates the OpenID spec, but in practice, for providers that use numerical IDs, lowercasing the ID had no impact.

It worked fine for:

• Google - uses numeric ID (10769150350006150715113082367)
• GitHub - uses numeric ID (1)
• Discord - uses numeric ID (80351110224678912)

It was problematic for:

• Keycloak - uses lowercase UUID string (25a37fd0-d10e-40ca-af6c-821f20e01be8) by default, but you can configure Keycloak so that the IDs are case sensitive, which current Wasp auth ignores

  For example, two different users with Keycloak IDs abc and ABC would be considered the same person:

  • Example 1: abc person adds their credit card → ABC gets access to their credit card
  • Example 2: admin person exists → ADMIN gets admin rights as well

The source of the problem is the createProviderId function that normalized the received ID:

export function createProviderId(
  providerName: ProviderName,
  providerUserId: string,
): ProviderId {
  return {
    providerName,
    providerUserId: providerUserId.toLowerCase(), // <--- incorrect behavior
  }
}

Applied fix​

Wasp has released version 0.16.6 which includes a fix for the vulnerability - Wasp no longer lowercases user IDs received from OAuth providers, only the email and username user IDs.

Users who use Keycloak auth with a configuration that makes the user IDs case sensitive should upgrade immediately to Wasp 0.16.6 to keep their Wasp apps secure.

Upgrade to the latest Wasp version by running:

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

Migration for Keycloak users​

If you did have case sensitive IDs set up, your users will need to register again with Keycloak since their old Keycloak account ID won’t be correct.

If you wish to avoid this, you’ll need to manually update the database table called AuthIdentity to contain the correct user ID casing.

You will need to update the providerUserId column for all affected users to match the IDs in Keycloak. Read more about the AuthIdentity table in the Wasp docs.

Timeline​

• May 23rd: Received report from @Scorpil
• May 26th: Confirmed the vulnerability
• June 4th: Prepared the fix
• June 4th: Drafted a GitHub Security Advisory and requested a CVE
• June 4th: Notified most likely affected users on Discord privately
• June 9th: Released Wasp version 0.16.6 with the fix
• June 9th: Published the GitHub Security Advisory (CVE-2025-49006)
• June 9th: Notified users on Discord publicly
• June 20th: Published this incident report

The fact is, scheduling is synonymous with infrastructure complexity. But sometimes you're just working on your trusty little Node app, and all you really need is something simple — like sending a daily reminder to users about today's coding challenge. That's exactly the kind of lightweight scheduling we'll dive into in this article.

Scheduling Jobs with Wasp and PgBoss​

What is PgBoss?​

PgBoss is a job queue built on PostgreSQL. It leverages the database's reliability, transactional safety, and scalability to manage background jobs efficiently. Unlike Redis-based queues, PgBoss doesn't require additional infrastructure — just Postgres, which is a great fit if you're already using it as your database.

Key features:

• Transactional safety – jobs are stored in Postgres, ensuring they survive crashes.
• Retries & timeouts – failed jobs can be automatically retried.
• Scheduling – supports both delayed and recurring (CRON) jobs.
• No extra infrastructure - only Postgres needed.

Why Wasp Makes It Even Better​

Wasp is a full-stack framework for React & Node.js that simplifies web app development by handling boilerplate for you. When combined with PgBoss, Wasp provides:

• Declarative job definitions – define jobs directly in your Wasp config.
• Everything just works – no need to manually set up workers or queues.
• Type safety – jobs are type-checked, reducing runtime errors.

NOTE: Since PgBoss runs in the same process as your Wasp app, CPU-heavy jobs can impact API responsiveness. For high-load scenarios, consider offloading to a dedicated worker process.

When Should You Consider a Different Solution?

For most side projects and early-stage startups, this setup will work perfectly fine. As a rule of thumb, if you're processing less than 1000 jobs per day or your jobs are mostly lightweight operations (like sending emails or updating records), you can stick with this solution.

However, you might want to consider a dedicated job processing system when:

• Your jobs take more than a few seconds to complete.
• You're processing thousands of jobs per day.
• Your jobs involve heavy computational tasks (like image processing or data analysis).
• You need to scale job processing independently from your main application

A dedicated system means running your jobs on a separate server or process, isolated from your main application. This prevents long-running jobs from affecting your app's performance.

But remember: premature optimization is the root of all evil. Start with this simple solution, and only upgrade when you have concrete evidence that you need something more robust.

We'll look at two use cases:

1. One-time scheduled jobs (e.g., send a reminder email at a specific time).
2. Recurring (CRON) jobs (e.g., daily digest emails).

We are going to use the Wasp Tennis Score example app to demonstrate the functionality.

This is a neat little tennis score tracking app we've built. Think of it like this: you're running a tennis tournament and need to keep track of who's winning. The judges can punch in scores as the matches happen, and everyone watching can see the results.

To run the app, you'll need to clone the repo, create a new .env.server file (copy example.env.server as a starting point), populate it with the required values and execute the sequence of commands listed in the README file here.

Requirements:

• Node.js ≥20 installed — I recommend using nvm.
• A Postgres database connection URL — but in our case for development you can just use wasp db start.
• Google OAuth credentials (Client ID and Client Secret)
• Mailgun config (API Key, Domain, API Url)

How to Create Scheduled Jobs with Wasp​

After cloning the repository, you can check out the working example implementation of the scheduled job feature by running the following command:

git checkout scheduled_job_added

Start the app with wasp start and authenticate with Google.

You'll be met with a UI that displays a list of tennis matches. Ongoing (i.e. Live) matches on the top and Completed Matches below.

In the header you will find a "Schedule Summary Email" button. That button is configured to send you a summary of the previous day's matches to your email.

Click the button and check the email address linked to your Google account. You should see something similar to the screenshot below.

Since this is a new account without any record of previous day's matches, the summary will be empty.

By default, the feature sends the email immediately for easier testing and development. I'll walk you through the implementation below.

Two resources in the main.wasp file do the heavy lifting for us: an action and a job.

// main.wasp

action scheduleEmailSummary {
  fn: import { scheduleSummaryEmail } from "@src/matches/operations",
  entities: [Match]
}

job sendEmailSummaryJob {
  executor: PgBoss,
  perform: {
    fn: import { sendEmailSummary } from "@src/workers/schedule",
  },
  entities: [Match]
}

The sendEmailSummary job retrieves matches, converts the results into a human-readable format, and delivers the email through Mailgun.

// src/workers/schedule.ts

export const sendEmailSummary: SendEmailSummaryJob<Input, void> = async (
  { email },
  context
) => {
  // Find yesterday's completed matches
  const matches = await context.entities.Match.findMany({
	  // ...
    // Query
  })

  // Generate summary
  const { textContent, htmlContent } = generateMatchSummary(matches)

  // Send Summary
  const summary = await emailSender.send({
    // ...
    // Config
    text: textContent,
    html: htmlContent,
  })
}

The scheduleEmailSummary action on the other hand controls when the code associated with the job should be executed

// src/matches/operations.ts

export const scheduleEmailSummary = async (_, context) => {
  // ...

  const { email } = context.user
  
  // ...

  // TODO: Update this date with the value you need (for example, tomorrow morning)
  const sendAt = new Date().toISOString()

  await sendEmailSummaryJob.delay(sendAt).submit({
    email,
  })
}

As you can see above, the sendAt variable determines the job's execution time. Just provide a date to the delay() function, and the job will execute at that specified time.

This is the meat and potatoes of the functionality, the only thing left is to decide when are you going to run the scheduleEmailSummary action.

I chose to simply hook it up to a button click listener, but you can let your imagination run wild and call it from wherever you want in the code.

You can find the current implementation in the IndexPage.tsx file.

// src/matches/IndexPage.tsx
import { scheduleEmailSummary } from 'wasp/client/operations'

// ...
const handleScheduleSummaryEmailClick = () => {
  // Call the action
  scheduleEmailSummary()
    .then(() => {
      // ...
    })
    .catch((error) => {
      // ...
    })
    .finally(() => {
      // ...
    })
}

// ...
<button
  onClick={handleScheduleSummaryEmailClick}
  // ...
>

That's all it takes — just a few lines of code to set up lightweight job scheduling. This implementation demonstrates the core functionality, but you can easily customize it to match your specific needs.

Finding this article useful?​

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! 🐝 Click on the button below to give Wasp a star and show your support!

How to Create CRON Jobs with Wasp​

If that seemed easy, you're going to like what comes next.

Setting up a recurring job is even simpler than a scheduled job, because we don't need an action to execute it. We can simply define the interval in the job declaration.

Define your job like this:

// main.wasp

job sendEmailSummaryJob {
  executor: PgBoss,
  perform: {
    fn: import { sendEmailSummary } from "@src/workers/cron",
  },
  schedule: { cron: "0 8 * * *" }, // <-- Notice the `cron` expression here
  entities: [Match]
}

The import statement connects to the function that will run according to the specified cron schedule. Here's how the function works:

// src/workers/cron.ts

export const sendEmailSummary: SendEmailSummaryJob<{}, void> = async (
  _,
  context
) => {
  // Fetch all users with email summaries enabled
  const usersWithSummaryEnabled = await context.entities.User.findMany({
    // ...
    // Query
  })

  // Find yesterday's completed matches
  const matches = await context.entities.Match.findMany({
    // ...
    // Query
  })

  // Generate summary
  const { textContent, htmlContent } = generateMatchSummary(matches)

  // Send emails to all users with summaries enabled
  for (const user of usersWithSummaryEnabled) {
    await emailSender.send({
      // Config
      // ...
      to: user.email,
      text: textContent,
      html: htmlContent,
    })
  }
}

That's it! Your function will now execute automatically according to the schedule you specified in the cron expression.

To receive game summaries in your email, go to your Profile page and enable them using the toggle switch under Settings as shown in the screenshot below.

Conclusion​

As we've seen, scheduling doesn't have to mean spiraling into infrastructure complexity — especially when you're looking for a lightweight solution.

Whether you're queuing up daily digests, reminders, or any time-based workflow, the setup is refreshingly simple:

• Define a job in your Wasp config.
• Use .delay() for specific future times.
• Use cron for recurring schedules.

That's it! No need to spin up external services or maintain a separate job runner infrastructure.

So if your app needs a simple scheduling feature, let Wasp and PgBoss keep track of the clocks ticking.

GLHF!

Ciao Wasp gourmets aka Waspeteers,

we are back! It’s time for a freshly baked Launch Week (#9, if anyone is counting), and oh boy, are we cooking. We’ve been hard at work for the past three months, and can’t wait to show you what’s on the latest Wasp menu.

As always, we’re throwing a nice and cozy community call where we’ll show you what we baked and sautéed (ok, no more cooking references. And yes, I’m lying). It will take place next Monday, April 14th, 11 AM EDT / 5 PM CET! To reserve your spot, visit the event in our Discord and mark yourself as interested.

So, without a further ado, let’s put the stove on (I warned you) and get cooking:

#1: Big Thinking - what’s that all about?​

With this Launch Week, we start a new chapter - we’re now officially putting our sights at bringing Wasp to 1.0 version. In order to do that, we needed to stop for a moment and compile everything we learned in the last four years of building, and decide what comes next.

The vision behind Wasp remains the same - create the best, most intuitive and truly full-stack web framework out there. We are bringing back that Laravel/Ruby on Rails feeling of super productivity everyone is calling for, but for the modern JavaScript, AI-infused ecosystem.

Some of the things we did along the way turned out great, and some turned out not so practical, and sometimes for the different reasons that we expected (e.g. IDE support for our own spec format). But, with all the experience and feedback you generously shared with our since Alpha (remember that?), we feel we have more clarity on the direction of Wasp than ever, and the road to 1.0 is fully open.

A lot of coming features still have to be ironed out, but we feel we have all the right questions we need to ask. And that’s exactly what we want to ultimately share with you - a full, transparent roadmap for Wasp to get to 1.0. We want to share everything we’re thinking about, how we are seeing the ecosystem and then again get your feedback on how Wasp should fulfill all these requirements to become a truly production-ready framework.

Can’t wait!

#2: Wasp team is growing!​

We’ve introduced new Waspeteers to our core team, and they can’t wait to meet you all! Being a 100% remote org, Franjo and Carlos joined us from sunny Barcelona and Croatia. They both come with unique experiences and interest which makes them a perfect to fit to work on the future of web development.

We all gathered in Croatia a few weeks ago and finally got ourselves a nice team photo:

Of course we went Ghibli with it. But my personal favorite is then going back to the original photo from it (warning: don’t click it. Seriously, don’t do it).

Join us on the community call on Monday and meet everybody in person! Franjo and Carlos will introduce themselves, share what convinced them to devote their lives to Wasp (too soon?), and we’ll chat a bit about hiring process at Wasp in general (aka why we don’t ask algorithms and all you have to do really is send us a t-shirt).

#3: Community day aka the cool stuff you’ve been building​

I repeat this every Launch Week, but this has been the busiest quarter we’ve ever seen, in terms of the quality and quantity of the new Wasp apps!

Your designs are getting more stunning, time to production is shorter and shorter (thanks, Cursor and Gemini 2.5!), and your apps are more innovative than ever! From LLM-powered SaaS-es, B2B services and all the way to internal tools in your enterprises - we’ve seen it all! You’ve been giving us incredible feedback and we’ve learned a lot from watching you build, ship and sell.

Nothing else to add except - time to build!

#4: Open SaaS day: 10k stars, Shadcn, QoL improvements and more!​

Open SaaS broke 10,000 stars on GitHub! That’s a pretty huge milestone, making Open SaaS one of the most popular React/Node.js SaaS starters on GitHub. We will talk more about how we got here, what developers are asking for and what’s coming next!

We also keep improving Open SaaS every day! There’s been a bunch of Quality of Life updates (Zod runtime validations, S3 file upload type-safety, atomic server-side actions, …)

Finally, we’re gearing up for a big redesign of Open SaaS! The initial design worked great to get things started, but since Open SaaS got so popular we realised it deserves a new coat of paint to help your apps stand out even more.

We are also playing around with integrating Shadcn - you can see the GitHub issue and share your thoughts and ideas here.

#5: See you there!​

This is it - as you can tell, we have a lot of new initiatives going on and we’re extremely excited to hear what you think about it! As Wasp is maturing and its direction and shape are becoming more and more clear, it is time we started investing in longer term efforts, thus all the Big Thinking ™.

And, as usual - to stay in the loop, follow us on Twitter/X and join our Discord - buzz you around! 🐝🐝

Today, we're introducing Carlos, who recently joined us as a framework engineer. Through this interview, you'll get to know more about his interests and what drew him to join Wasp.

Let’s start with two truths and a lie about yourself.​

1. I was entered into a baby model agency and had a professional photo book done.
2. I’m a chair expert and can name most of the ones you might see in a museum.
3. I won a hackathon for making innovative sex toy tech.

Which statement was the lie above? Any interesting stories to share?​

I’m not a chair expert! I come from an industrial design background, and the education was very heavy on studying the history of chairs. But I forgot a lot, so I can recognize some of the most famous ones, just please don’t ask me to name them 😅.

However if anyone who reads this is missing some Spanish-language chair content in their life, I can recommend this TikTok account.

This is a cool one we had in my faculty! Uncomfortable af though.

Unfortunately, both the other stories were one-offs. But if we ever meet in person, I’ll show you the picture they took of me simulating this classic Bill Gates photo when I was nine.

Editor’s Note: The original image is way cuter! Do ask Carlos to show it to you!

Why did you join Wasp? What did you do before?​

I started programming when I was around eight years old, but only as a hobby. I actually did my studies in Industrial Design, and while I lived in the Netherlands I was working as a teacher assistant on one of the more tech-focused courses. That was when I discovered that I was good at understanding what other people need from a specific tool or process, even across people from different cultural and professional background. And that I just really needed doing that from a tech position rather than a design one.

Here's a picture of me at a design futures exhibition in the Netherlands, explaining the visitors a weird scifi story to go with our project, an Arduino-based game.

At some point I dropped out and came back to Spain. I taught programming to children, and worked in a consultancy as a programmer; but my favourite job was in an HR tech enterprise where I was part of the internal frontend support team, doing Inner Source platform work.

When I found out about Wasp, I immediately got excited thinking that it could be a continuation of the kind of work I love doing the most. I just really like speaking with developers in the open, and creating robust tools to simplify their work!

What is your favorite language?​

I know you probably were expecting a programming language, but I’ll be a cheeky and say a human one: in the past few years, I’ve been listening to a lot of music in Catalan and Occitan, and I really love how they sound.

But on the computer side, my current favorite (and for quite some years already) is doing dark type magic in TypeScript. Although I would resurrect LiveScript if I could.

What are you most excited about in Wasp?​

The opportunity to really cut down on the time spent from having an idea, to writing code for it, and not configuration and boilerplate. We take care of all the boring stuff and people just need to care about the code that makes their app unique. And you can be sure that this is how a senior engineer would do it, with best practices and top library choices baked int.

What’s a feature or project you’re most proud of?​

A few years ago some friends had the idea for vecinoscabrones.com and we made it together. It’s a search engine that can search for any sentence in a famous Spanish sitcom, and get you the exact moment they said it, links to that moment in streaming sites, and make a GIF out of it. And I’m very proud that I got the whole GIF subtitling and generation done on the client!

You can see this gif here.

How did you start coding?​

I was obsessed with being on the family computer as a kid. First it was The Sims, but on occasions I went into C:\ and touched things I shouldn’t, and crashed it. At some point, my parents bought me my own second-hand laptop, and by chance it had Macromedia Dreamweaver and Flash installed.

I somehow found them and started playing with first their editors and then with the code, and the rest is history. I remember one of the first things I “created” was a HTML file with the lyrics to “American Idiot” by Green Day, that I then burned to a CD to hand to my friends.

Your dev setup?​

Just a MacBook, VS Code, and Apple Reminders! I used to get really carried away trying to get everything super customized but now I’m a believer in the zen of defaults.

What is your current favorite gem, library, tool, or anything else that helps you with your work? Why?​

The most important tools I’ve found lately have been Raycast, OrbStack, jj, and mise. Specifically jj makes my work so much faster.

Lastly, where can people find or connect with you online?​

On Bluesky, Twitter, GitHub, and LinkedIn. Also IRL in Barcelona, Spain.