Wave (thedevdojo/wave): A Laravel SaaS Starter Kit With Billing, Roles and an Admin Panel

What Wave Is and Who It Is Built For

Wave is a SaaS framework built with Laravel. The README states the goal plainly: it should let you "quickly transform your idea into a profitable SaaS product." The feature list reads like the checklist a solo developer writes before starting a subscription product: authentication, user profiles, user impersonations, billing, subscription plans, roles and permissions, user notifications, a changelog, a blog, pages, an API, an admin panel, themes and plugins.

That list is the product. Wave is not a library you call from your own application; it is a Laravel application you clone and then modify. The repository layout confirms this. There is an app/ directory, routes/, resources/, database/, config/, and an artisan file at the top level, alongside a wave/ directory that appears to hold framework-specific code. The package.json is marked private, which is what you expect from an application rather than a distributable package.

The audience is narrow and clear. You need to be comfortable in PHP and Laravel, and you need to be building something that charges users on a recurring basis. If your product is a one-time purchase, or a free tool, most of Wave's value is unused weight. If you have never worked in Laravel, the starter kit will not teach you the framework; it assumes it.

How Wave Is Assembled: Laravel, Vite, Tailwind and a Theme File

The frontend build is Vite 6 with the Laravel Vite plugin, Tailwind CSS 4 through the @tailwindcss/vite plugin, and Alpine.js. The package.json scripts are only two: dev runs vite, build runs vite build. There is no separate asset pipeline to learn.

The .env.example shows the default database connection is sqlite, with MySQL settings present but commented out. Cache and session default to the file driver, the queue connection is sync, and mail points at smtp.mailtrap.io on port 2525. Those defaults are development defaults. A sync queue means queued work runs inside the request, which is fine locally and wrong in production once you have real traffic.

Billing is configured through environment variables rather than code. The file sets BILLING_PROVIDER=stripe and then supplies both Stripe keys (STRIPE_PUBLISHABLE_KEY, STRIPE_SECRET_KEY, STRIPE_WEBHOOK_SECRET) and a Paddle block (PADDLE_VENDOR_ID, PADDLE_API_KEY, PADDLE_ENV, PADDLE_PUBLIC_KEY, PADDLE_WEBHOOK_SECRET). Both providers are wired into the configuration surface, so switching is a matter of environment values and whatever the docs require beyond that. The README does not describe the billing flow itself; it links to a billing page in the external documentation.

The theme system has its own top-level file, theme.json. Wave ships themes, and the README points at a live demo where you can preview the available ones. Plugins and themes are listed as features, but the repository does not contain a plugin marketplace or a theme specification document, so treat extensibility as something to inspect in the code rather than something the README explains. There is also a WAVE_DEMO flag in .env.example, which suggests the demo mode shown on the project site is a configuration switch rather than a separate branch.

Installing Wave and Getting to a First Login

The README gives two installation paths: an automated installer or a manual install. It does not reproduce the steps. It links to devdojo.com/wave/docs/install for the full instructions, and the README also carries an "Install with Herd" badge pointing at herd.laravel.com with the starter kit parameter devdojo/wave. So the three entry points named in the repository are the automated installer, the manual route, and Laravel Herd.

Because the README does not print the manual steps, the honest position is that you should follow the linked installation page rather than improvise. What the repository does tell you is what the application expects once it is running. The .env.example is the contract: copy it to .env, and the defaults assume SQLite, file-backed cache and sessions, and a sync queue. The APP_KEY in the example file is a real-looking base64 value, which is a reminder to generate your own rather than reuse the sample.

The frontend has to be built before the UI is usable, and the two scripts in package.json are the whole story:

npm install
npm run build

For local development, npm run dev starts the Vite dev server instead, which is the mode you want while editing Blade templates and Tailwind classes.

Billing is the first thing most people configure, because a SaaS starter kit that cannot take a payment is not doing its job. The environment block for Stripe looks like this:

BILLING_PROVIDER=stripe
STRIPE_PUBLISHABLE_KEY=pk_test_...
STRIPE_SECRET_KEY=sk_test_...
STRIPE_WEBHOOK_SECRET=whsec_...

The values in .env.example are placeholders of the correct shape, not working credentials. You replace them with your own test keys, and the webhook secret has to match the endpoint you register with the provider. The README does not document the webhook route, so that detail has to come from the external docs or from routes/ in the repository.

One more environment value deserves attention before you invite anyone to look at your install:

WAVE_DEMO=false

Leaving demo mode on in a deployment that holds real user records is the kind of mistake that is easy to make and hard to notice.

Where Wave Stops Short

The most concrete limitation is documentation placement. The repository is a Laravel application with a README that functions as a signpost. Installation, billing, themes, plugins, the API, roles and permissions all resolve to pages under devdojo.com/wave/docs. If that site changes, moves, or gates content, the repository does not carry a fallback. There is a CLAUDE.md file at the top level, which suggests some guidance for AI coding assistants exists in-repo, but that is not a substitute for user documentation.

There is also a commercial layer sitting next to an MIT-licensed codebase. The README's support section asks readers to subscribe to DevDojo Pro for "premium content" and states that the video course requires that subscription, with only the first few videos free. The code is MIT; the surrounding learning material is not. That is a legitimate model, but it means the free path through Wave is the code plus the written docs, and the guided path costs money.

The default environment is another place to be careful. SQLite, file cache, file sessions, and a sync queue are all fine for development and all wrong for a production SaaS with concurrent users. Nothing in the README warns about this. You are expected to know it, or to find it in the docs.

Finally, consider the stack constraint. Wave is PHP and Laravel. If your team is a Node or Python shop, adopting Wave means adopting an entire ecosystem, not adding a dependency. That is a much larger decision than the feature list makes it look.

Wave Against Laravel Jetstream and Spark

The obvious comparison is with other Laravel starter kits, and the difference is scope. Jetstream, also from the Laravel organisation, covers authentication, teams and profile management, and leaves billing to a separate package. Wave bundles billing, subscription plans, roles and permissions, an admin panel, a blog, pages, a changelog and a theme system into the same application.

That is a real distinction in approach, not a marketing one. With a narrower starter kit you assemble the pieces you want and own every integration decision. With Wave you inherit a working set of features and then remove or adapt what you do not need. The second path is faster when the bundled feature list matches your product, and slower when it does not, because you are deleting code and untangling configuration rather than writing fresh code against a clean surface.

The billing configuration illustrates the trade-off. Wave's .env.example carries both Stripe and Paddle credentials, which is convenient if you have not decided, and is also two providers' worth of configuration to understand before you ship. A minimal setup would carry one.

The other comparison worth naming is a plain Laravel install with Cashier. That gives you billing and nothing else, and you build authentication, roles and the admin panel yourself. Wave's argument is that those pieces are tedious and similar across projects, so shipping them pre-built is worth the extra surface area. Whether that holds depends on how closely your product matches the bundled feature list.

Maintenance, Licence and What an Upgrade Costs You

The repository is not archived, and the last push was on 2026-07-31. The most recent release listed is 3.1.5 on 2026-01-10, preceded by 3.1.4 on 2026-01-02 and 3.1.3 on 2025-12-31. Those three releases land within eleven days of each other, which looks like a patch burst rather than a steady cadence, and the gap between the January release and the July push is worth noting if you depend on tagged versions rather than the main branch.

The licence is MIT, and the repository carries a LICENSE.md file. MIT is permissive: you can use the code in a commercial product, modify it, and redistribute it, subject to the terms in that file. This is not legal advice, and if your organisation has specific obligations around attribution or redistribution, read LICENSE.md and get proper advice.

The upgrade cost is the part that is easy to underestimate. Wave is an application you fork, not a package you update. Once you have modified the bundled authentication, billing or admin code for your product, pulling in a new release means reconciling your changes against upstream. The release history above shows how quickly patch versions can follow one another, so a fork-and-modify workflow can accumulate merge work fast. The pragmatic approach is to keep your own changes in as few files as possible and in clearly separated directories, so that the diff against upstream stays small. The repository does not document an upgrade procedure; the README is silent on it.

What Wave Is Not For

Wave is the wrong tool in several specific situations. If your product does not charge recurring subscriptions, the billing and subscription-plan features are dead weight you will spend time understanding before you remove them. If your team writes JavaScript or Python and has no Laravel experience, the starter kit's speed advantage disappears into learning the framework. If you need a headless API with a separate frontend, Wave's bundled Blade views, Tailwind setup and theme system are a mismatch, even though an API feature is listed.

There is also a fit problem around the admin panel and role system. If your application has one user type and no administrative surface, you are inheriting Voyager-derived admin tooling and a permissions model for no reason. The repository topics include voyager, which points at the admin package lineage, but the README does not explain how the admin panel is wired or how far it has diverged from that lineage.

The honest summary is that Wave is a strong starting point for one shape of product: a subscription web application built in Laravel by a small team that wants authentication, billing, roles and an admin panel working on day one. Outside that shape, the bundled features become something to remove rather than something to use.

Editorial conclusion

Adopt Wave if you want a Laravel subscription product and would rather start from working authentication, billing, roles and an admin panel than wire them yourself. Do not adopt it if you need a non-PHP stack, or if you expect the repository to explain every feature: the README defers to devdojo.com/wave/docs, and the install instructions are not in the README at all. Before committing, verify the billing provider you intend to use is the one configured in .env.example, check that the theme.json file matches the theme you want to build on, and confirm which PHP and Laravel versions the current release targets, since that is not stated in the README.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. thedevdojo/wave on GitHub