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/claude-plugins

# install the plugin from the marketplace
claude plugin install wasp@wasp-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/claude-plugins

2. Install the plugin:

claude plugin install wasp@wasp-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.

In this post, we'll go from the basics of developing your app and applying database migrations locally, before we progress to the more advanced scenarios:

• For this post, I'm using Prisma, but the steps can be reproduced for any other setup as well.
• We'll update an existing production database (without losing user data).
• We'll change the database in a way which introduces a breaking change. It will feel like you have to refuel a fighter jet mid-air, but don't worry, we'll go step by step!

One great analogy by Vadim Kravcenko (who wrote a great migration post, linked below):

Doing migrations is like working with live wires. You have a new lamp that you need to hang on the ceiling, but you're doing that without turning off electricity.

Vadim Kravcenko

Let's first introduce the app that we will work on.

Tennis score tracker app​

We've built a small but complex enough tennis score tracking app:

Imagine you are organizing a tennis tournament and you want to keep track of the scores in real-time. Judges can update the scores live and the app users can see all match scores.

We've built this app with Wasp framework which provides a nice and easy way to build full-stack apps like these (it uses Node.js, React and Prisma under the hood).

Users can log in and create matches…

… enter match scores and track all other users' matches.

Since Wasp uses Prisma as its database abstraction layer, we'll show all the database schema changes in Prisma, but all the ideas and techniques are pretty much universal. This means all the steps apply with using only raw SQL or Drizzle.

Database Migration Scenarios

We'll cover database migrations in three different scenarios:

1. Developing the app locally and deploying it
2. Introducing the new database field, no breaking change: Adding the concept of private matches → deploying the update
3. Introducing a complex schema change, a breaking change: New score storing format → releasing it in multiple deployment steps

Database Migration No. 1: Using database migrations with local development​

While we are developing our app, we'll go through multiple iterations of our data schema. We'll think of one data model, start building our app, realize we need extra fields or we need to organize them differently etc. and our data model will evolve.

For our tennis score-tracking app I came up with this:

• User represents a user of our app
• Match contains all the match info/score info
  • player names
  • player points and games for the current set
• Set model to keep track of all played sets

Let's focus on the matches table to keep things a bit easier to follow:

model Match {
  id         String   @id @default(uuid())
  createdAt  DateTime @default(now())
  isComplete Boolean  @default(false)
  currentSet Int      @default(1)
  server     Int      @default(1)

  // Relations
  createdBy   User   @relation("CreatedBy", fields: [createdById], references: [id])
  createdById String

  // Player details
  player1Name String
  player2Name String

  // Current score (for the ongoing set)
  player1Points String @default("0")
  player2Points String @default("0")
  player1Games  Int    @default(0)
  player2Games  Int    @default(0)

  // Set history
  sets Set[]
}

Once you've written a Prisma schema for your app, you'll need to create a migration file. This file will contain SQL commands needed to update your database, such as creating new tables or modifying existing ones, or adding database indexes, etc. Let's run wasp db migrate-dev which uses the Prisma CLI in the background and you'll get the following code in the migrations/ dir:

-- CreateTable
CREATE TABLE "Match" (
    "id" TEXT NOT NULL,
    "createdAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP,
    "isComplete" BOOLEAN NOT NULL DEFAULT false,
    "currentSet" INTEGER NOT NULL DEFAULT 1,
    "server" INTEGER NOT NULL DEFAULT 1,
    "createdById" TEXT NOT NULL,
    "player1Name" TEXT NOT NULL,
    "player2Name" TEXT NOT NULL,
    "player1Points" TEXT NOT NULL DEFAULT '0',
    "player2Points" TEXT NOT NULL DEFAULT '0',
    "player1Games" INTEGER NOT NULL DEFAULT 0,
    "player2Games" INTEGER NOT NULL DEFAULT 0,

    CONSTRAINT "Match_pkey" PRIMARY KEY ("id")
);

-- CreateTable

-- ... some more SQL here ...

Prisma will then apply the change to your local database (we're using PostgreSQL locally that we started via wasp db start) and this will enable the app to connect to the database and create users, matches and update scores.

Here's what your local database table looks like after you've applied the migration:

As you can see, migrations are something we do as we change our database's data schema. They updated your local database to have the tables that match your current Prisma models.

At first, it might sound like needless bureaucracy for something that you could have done manually with some GUI and clicked around to set up the tables you need. What if you need to have the same table structure in multiple databases (e.g. staging and production environments)? The migration files then become essential in keeping production database tables (called database schema more precisely) in sync with what you've defined in your Prisma models file.

When you deploy a Wasp app, the server app's Dockerfile runs a Prisma command that applies any migrations you have in the migrations dir that are not yet applied. This is great! As you deploy your code changes, the database changes are also deployed.

Let's deploy our app to Fly using Wasp's one-line deploy command wasp deploy fly launch and we are live at: https://tennis-score-app-client.fly.dev/

Database Migration Scenario No. 2: Adding a new field to the deployed app​

After some time we realized we want to enable users to play private matches. Not everyone wants the rest of the world to know their low score.

To enable this in the app's UI, we'll add a public/private toggle button:

To support this functionality, you need to add some extra info in our matches model:

model Match {
  id         String   @id @default(uuid())
  createdAt  DateTime @default(now())
  isComplete Boolean  @default(false)

  // We need this new field
  isPublic   Boolean  @default(false)
	// ...
}

Okay, this is just one extra line in the model definition. To be able to use it, run wasp db migrate-dev and your local database is ready to go.

What about the existing rows, which values will they have?​

Let's take a step back and look at one important detail here: the default value.

@default(false)

Since we already deployed our app, this forces us to think about existing production data e.g. matches that our users already created. If we are adding a new field that the app didn't use before, we need a default value so our existing data can still make sense.

Based on our app's logic, we should come up with a default value that makes sense to us. I've put false as the default value which can be right or wrong depending on we are trying to achieve. If it's false, we are saying that all the existing matches in the database will become private. If it's true, the existing matches will stay public unless users change it in the UI.

In hindsight, I think true is the better choice, but I've put it false because I thought being extra careful not to expose private matches made more sense. It depends on your app.

The important lesson here is that when we go to deploy our app changes and the migration file is applied in production, the existing matches will be "migrated" to have the isPublic field with the value of false. No downtime, no data loss, great! This is all because we had a good default value.

Our local and production database now looks like this:

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!

Database Migration No.3: Breaking change with the score-keeping format​

And now for something completely different… a dangerous, complex, multi-step migration. Sounds fun? 😀 These kinds of migrations are usually quite stressful for me because they involve database schema changes that can cause data loss. They can potentially ruin our app and chase away our users.

We'll be using a migration strategy, commonly called expand & contract pattern which will enable us to do a breaking change in multiple steps. This strategy should ensure there is no data loss and our users shouldn't notice anything.

Database backups​

One important step we should take before doing schema migrations is doing database backups. Having automated backups of your database is crucial if you are doing anything serious that involves user data. Servers may fail, disks might get corrupted, data centers burn or a bug in your app might delete your data by accident. How you back up your database will depend on your hosting provider. We used Fly for this app and they have regular disk snapshots which are enough for most use cases and certainly good enough for our demo app.

If we are planning to do a complex database schema migration, you should create a database backup just before doing the migration steps.

For example, we run:

pg_dump -h localhost -U postgres tennis_score_app_server > backup.sql

which will create a backup.sql file that will enable you to restore the database to this point in time if something goes wrong in the next steps.

With that out of the way, let's jump into the breaking change migration.

The new database format​

Imagine we want to change the way we store the score of a match. We will store it in a JSON field called score instead of using 4 different fieldsplayer1_points, player2_points etc. (Let's say that, for some reason, this is really useful for our business case.)

The new JSON format looks something like this:

{
  "player1": {
    "points": "0",
    "games": 0
  },
  "player2": {
    "points": "0",
    "games": 0
  }
}

Again, the main problem is the existing production data that we have in our production database. We can't just delete all the tables in our database and recreate them with the new structure. We'd lose valuable user data.

We will do this migration in multiple steps to change the score format without our users noticing anything. We will deploy the changes after each step, test the app and then carry on to the next step.

The trick - our app will use both new and old fields at the same time​

The "trick" we will use here is that we'll first create the new field, without touching anything else, and the app will still keep using the old format. Then, we'll refactor the app to start using the new field and the old fields both at the same time. Finally, we'll migrate all the "old" data to the new format and remove the "old" fields and logic in its entirety. This is how you do a complex migration like this without any downtime for users.

Let's now see it in action, step by step.

Step 1: Add the new field and start writing to it​

We'll start by adding the new optional score JSON field:

model Match {
  // ...

  player1Points String @default("0")
  player2Points String @default("0")
  player1Games  Int    @default(0)
  player2Games  Int    @default(0)

  // Adding a new optional "score" field
  score Json?
}

The important thing to notice here is that we made the field optional. Our existing data doesn't have that field and the database migration wouldn't work if we made it a required field. Since there isn't a sensible default value we can think of, we'll make it optional (nullable). This will allow our existing data to "adopt", it will have the new extra field without any value.

The next important change isn't in our database, but in our application code. From now on, we will write the score in both the old format and the new format. We'll write the score in the existing fields and ****in the new score field. We are making sure that all new matches have the value filled for the new field.

Visually, it can be represented like this:

You can see that we are writing to both old and new fields, but still reading from the old fields.

Alright, cool, we can deploy this now. Nothing should change for our users, in the background, old matches got a new empty field and new matches will have that score field populated.

Our production database should look like this now:

Step 2: Migrate the existing matches data to the new format​

For our new matches, we write to the new score field, but for existing matches, we don't. We need to "go back in time" and bring our old matches up to speed.

We need to write a migration script that will copy over the data from the old format to the new format.

How you write the migration script is up to you, but I'll write a custom endpoint that will execute some database logic. I did it like this:

import { MigrateToNewSchemaApi } from "wasp/server/api";
import { Prisma } from "@prisma/client";

export const migrateToNewSchema: MigrateToNewSchemaApi = async (
  _req,
  res,
  context
) => {
  // 1. Get all the matches that have an empty score field
  const matchesWithoutJsonScore = await context.entities.Match.findMany({
    where: {
      score: {
        equals: Prisma.DbNull,
      },
    },
  });

  let updatedCount = 0;
  for (let match of matchesWithoutJsonScore) {
    // 2. Copy the data from the old format to the new format
    await context.entities.Match.update({
      where: { id: match.id },
      data: {
        score: {
          player1: {
            points: match.player1Points,
            games: match.player1Games,
          },
          player2: {
            points: match.player2Points,
            games: match.player2Games,
          },
        },
      },
    });
    updatedCount++;
  }

  return res.json({ success: true, updatedCount });
};

We deploy this code without any other database changes and we run the migration script. It should report the number of matches that were updated:

{ "success": true, "updatedCount": 105 }

Now we have our database in a state where all the matches have the match score written in the new format.

Step 3: Start reading from the new format​

We are now ready to finish the migration by making the score field required (not nullable). Our app needs that field, so it's a bad practice keeping it optional - it's a bug waiting to happen.

We'll remove the ? from the Prisma schema:

-   score Json?
+   score Json

Running wasp db migrate-dev gives us this migration file:

/*
  Warnings:

  - Made the column `score` on table `Match` required. This step will fail if there are existing NULL values in that column.

*/
-- AlterTable
ALTER TABLE "Match" ALTER COLUMN "score" SET NOT NULL;

Notice the comment on top, it says the migration will fail if there are existing NULL values in the score column.

That's fine, we took care of that in our previous step when we filled in the score value for all matches. We also made sure that we wrote any score updates to both the old location and the new location for all new matches.

Now that we have the new format ready, we'll start reading from the new format so that our app stops depending on the old format in its entirety:

This change looks like this:

We stop reading from the old format, and start reading from the new format.

After we deploy this change, our app will only read from the new score field. Now we no longer depend on the old format, which sets up for the last step of the process.

Step 4: Remove the old format fields​

After we tested the app and we are certain that the app is no longer using the old fields anywhere, we can remove the old format fields.

We remove the fields from the Prisma schema and generate the migration file in migrations/ dir:

/*
  Warnings:

  - You are about to drop the column `player1Games` on the `Match` table. All the data in the column will be lost.
  - You are about to drop the column `player1Points` on the `Match` table. All the data in the column will be lost.
  - You are about to drop the column `player2Games` on the `Match` table. All the data in the column will be lost.
  - You are about to drop the column `player2Points` on the `Match` table. All the data in the column will be lost.

*/
-- AlterTable
ALTER TABLE "Match" DROP COLUMN "player1Games",
DROP COLUMN "player1Points",
DROP COLUMN "player2Games",
DROP COLUMN "player2Points";

There are some warnings in the migration file: all the data will be lost in the columns we want to remove. That's fine because we migrated the data from the old format to the new format. This is exactly what we want, to clean up the old redundant data.

Dropping the old fields looks like this:

We no longer need the old fields, we remove them and all that's left is the new format fields.

Deploy the app one more time… and we completed the migration.

This is our final database schema:

Since we used Prisma for our database modeling, it was quite easy to see what was going on with the new fields, old fields, and the migration files that Prisma generated with the extra comments.

Conclusion​

In this article, we learned about three types of database migration scenarios:

1. working locally, creating the first migration, deploying
2. adding new fields to an already deployed application (default value is your friend)
3. doing a breaking change using the expand & contract strategy

Database migrations are a serious thing to do in the lifecycle of developing your app, especially when we have users who rely on your app. If you plan ahead, and pick the right strategy, your migration should have a good chance of success.

The most important tips to remember:

• Always do database changes through migrations (they keep local and production databases in sync)
• Make sure you have sensible default values for new fields (they enable easy addition of new fields)
• If you need to do a breaking change, use the expand and contract pattern to migrate your data in multiple steps (minimizes the chances you lose data)
• Back up your database (if something does go wrong, you can revert the change)

The source code of the final app can be found here: github.com/wasp-lang/tennis-score-app and the deployed version here: https://tennis-score-app-client.fly.dev/

Reading materials​

Here are some extra reading materials on the topic:

• https://www.prisma.io/dataguide/types/relational/what-are-database-migrations
• https://www.prisma.io/dataguide/types/relational/expand-and-contract-pattern
• https://vadimkravcenko.com/shorts/database-migrations/

For those of you who are new here, we have been building a full-stack, batteries-included web framework for the last four years. You can think of Wasp as a modern, JS-based incarnation of Laravel, Django or Ruby on Rails. We based it on a custom compiler so it doesn’t depend on the specific stack or the architecture in the long run (currently it supports React, Node.js and Prisma).

Wasp just crossed 16,000 stars on GitHub, with thousands of devs using it both in their startups and enterprises.

Run on vibes, not the compiler​

Still, with the recent developments in the LLM-powered code generation, we realised our current approach simply isn’t feasible anymore. We decided that instead of implementing and maintaning our own compiler, we can simply outsource that to an LLM.

Here's why it makes much more sense and completely changes the game:

Nobody looks at the generated code anymore​

Gone are the days when we as developers argue about which is the best UI or state management library. No more asking our colleagues or on Reddit "what is everyone using nowadays," just to figure out there's a cool new thing you now have to learn.

All of that is now delegated to the AI — it has been trained on millions of codebases, and it can bring a much more sound decision than we can with our limited experience. If it turns out that its weapon of choice is jQuery or Redux v3.7.0 from 2017, so be it. It's not like anybody is ever going to be looking at the actual code and try to refactor it manually.

Full-stack goes “fluid” - never get the same app twice​

We’re now entering the era of a generative and so-called “fluid” UI. Instead of the traditional hard-coding of UIs for the specific pages (e.g. User profile, Settings, Billing, …), the AI will generate a personalized UI for each user. We decided to take that one step further - not only UI should be customized, but rather all the parts of the stack, including backend logic and the database models.

That means each time you change or re-deploy your app, it will be slightly different. Sometimes it might be completely unnoticeable change (e.g. a different hashing algorithm or lodash using another version), and sometimes a feature will work a bit differently than the last time a user tried it.

There are two obvious benefits to this:

• Your UI will always feel “fresh” and keep your users engaged, making sure they don’t get caught up in a rut.
• It’s a great security enhancement - good luck hacking an app that constantly changes it’s implementation

Prompts are the new code, but with less hassle​

With these fundamental changes, Wasp will move from the classical notion of the framework to the novel AI-first, prompt-based system for building full-stack experiences. Wasp will preserve a certain degree of backward compatibility with the previous versions and let developers define their own components, and even the backend logic, but we recommend everyone to start transitioning towards the new paradigm.

We’ve discovered that prompts are vastly superior to the code - they don’t have to be versioned nor shared among the team members. Each new team member can simply browse the app and discover its features, instead of reading through all the tedious code and tests.

Lastly, there is no specialized knowledge required - anybody can start contributing right away.

Thoughts and ideas? We’d like to hear from you!​

As always, we’re grateful for your support and would love to hear from you. We realize this is quite a big change but are confident in the new direction we’re taking with Wasp. AI and LLM-powered code generation offers so many new possibilities and it is our responsibility to find the best way to make use of it.

Let us know what you think on our Discord - we’re looking forward to seeing you there!

As Wasp usage continues to grow, we're steadily expanding our team to better support our community. Today, we're introducing Franjo, who recently joined us as a framework engineer. Through this interview, you'll get to know more about his background, his perspective on development, and what drew him to contribute to Wasp's mission of simplifying web development.

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

1. I’ve tried to build a startup during my university days.
2. I was highly competitive in a niche mod for an old RTS game.
3. I’ve built a graphics engine in C++ with SDL2.

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

The lie is that I never entirely built my graphics engine, only parts of it. Before diving into computer graphics, I never imagined that simply rendering a triangle could bring so much joy. I managed to implement textures, sprites, animations, and basic camera controls, but eventually, the university took over my life, and I never got around to finishing it.

As for the game, it was the Ultimate Apocalypse mod for Dawn of War: Soulstorm. I realized it had completely taken over my life when Steam showed I had racked up ~38 hours in the past week, right in the middle of my midterms.

I’ve tried to build a startup while I was a student, but failed miserably.

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

I’ve always had an affinity for startups and loved building something from the ground up. My journey naturally trended toward smaller companies where I could have a greater impact.

Before joining Wasp, I had a student job at Neos, a medium-sized fintech company, and later moved to a smaller webdev agency, Pixion. At Pixion, I worked on a few smaller projects in small full-stack teams, which allowed me to make a significant impact early in my career. I enjoyed building something from scratch, but it was frustrating to move on to the next project just as things were taking shape. Over time, I realized that I wanted to fully transition to working on products, preferably in a startup.

One day, I came across an open position at Wasp. Everything looked great—until I saw they were looking for senior software engineers**.** Still, Wasp seemed like exactly the kind of company I wanted to be part of, so I applied anyway. Beyond the chance to work on a product, I was excited about the opportunity to learn startup know-how and contribute to open source. Fast forward a few weeks, and I got the position!

I’ve held the student booth twice while being a student myself. Once at Neos, and once at Pixion.

What is your favorite language?​

That’s a tough question! One thing that keeps me from being fully confident in my answer is that I haven’t explored every language out there, so my favorite might still be waiting to be discovered.

I enjoy statically typed languages, especially those with structural typing. The little experience I’ve had with Go was a lot of fun. Beyond that, a rich type system is a huge plus for me. I love how flexible and freeing TypeScript feels compared to something like C#.

I’ve heard great things about Haskell’s type system, but I haven’t had the chance to dive into it yet, so I’ll hold off on commenting for now.

What are you most excited about in Wasp?​

Web development often involves repetitive and boring tasks that are crucial to get right, like security. What I love about Wasp is that I can simply skip those parts, but not just partially—Wasp handles them fully, across both the front end and the back end. It’s an ideal web development framework that lets you focus on what truly matters: your business logic.

Once Wasp reaches stability, prototyping ideas will never be the same again.

What’s a feature or project you’re most proud of that you worked on in the past three months?​

Since I recently joined Wasp, I’ll talk about my time at Pixion. We had just three months to build a fully functional prototype from scratch so it could secure funding. It was an exciting but stressful period, especially since our team consisted of just two people, with the other coworker working only part-time.

In the end, I managed to bring the project to completion just before my notice period ended. I’m proud of how much we accomplished in such a short time while still adhering to best practices like Clean Architecture, DDD, Vertical Slice Architecture, and CQRS.

Oh, and yes—it was a C# project. Why do you ask? 😏

How did you start coding?​

While I had some early exposure to coding, my real journey didn’t start until university. In primary school, we played around with HTML and FMSLogo. In high school, we were supposed to learn quite a bit, but we switched informatics teachers so often that we never actually covered much.

University was where I finally got the chance to dive into the world of programming. Initially, I wanted to become an AI Engineer or work in Computer Graphics, so I dug deep into mathematics. But then, a single Design Patterns course made me fall in love with software engineering—and I’ve been a software engineer ever since.

Your dev setup?​

For most of my life, I worked on Windows. Somewhere during university, I switched to Linux, and it made my dev life so much better. Then, one day, I decided to blindly buy a MacBook, even though I had never used one before. Luckily, the gamble paid off, and I’ve loved developing on MacBook ever since.

My current setup is a MacBook Pro M3 Pro, preferably with an additional external screen. I’ve never really gotten used to traveling and working.

For my tools, I use Homebrew, iTerm2, and Oh My Zsh, along with Rectangle for window management. For web development, Firefox has always had the best dev tools for me.

While I enjoy the ease of macOS, sometimes the lack of customizability irks me.

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

I’d like to take this opportunity to give a shout-out to the Tanstack team. Their libraries have significantly improved my web development experience ever since I first tried them out. In the past, when using alternative libraries, I often found myself asking, "Why isn’t X done in Y way?" With Tanstack, that question has come up much less frequently. While it still happens occasionally, it's a vast improvement. I also love that their libraries are framework-agnostic, which adds a lot of flexibility.

One piece of advice you’d give to budding developers?​

Don’t be afraid to try different things and switch to what you truly enjoy. I’m eternally grateful for my experimentation period in university, which helped me avoid committing to something I wouldn’t enjoy doing daily.

Also, don’t be afraid to work on something before reading all the docs, articles, and blogs, and watching videos about it. Don’t let the need for endless preparation prevent you from gaining real hands-on experience.

I’m thankful that university allowed me to experiment with various fields of computing. I’ve successfully graduated last year!

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

For now, I’d encourage people to follow me on Twitter. I’m not active on other platforms at the moment. However, you can also find me on the Wasp Discord.