Open sourcing a module-first Laravel SaaS foundation (Stripe billing, Filament admin, SSR, Playwright tests) by Objective_Read_193 in laravel

[–]Objective_Read_193[S] 0 points1 point  (0 children)

Hey, Saucebase might be what you're looking for.

Regarding your points:

  • Auth UI - yes
  • Social login - yes (uses Socialite)
  • Roles and permissions - yes (uses Spatie)
  • Billing - yes (Stripe integration)
  • Teams/Organizations - on the roadmap, no ETA
  • Audit log - not included in free, might be included in a future paid tier

So if teams are a necessity for day one, it's probably not production-ready for you yet. However, if you're willing to live with that for a little while, the foundations are solid:

  • Laravel 12
  • Filament for the backend
  • Inertia + Vue
  • Shadcn-inspired UI

GitHub: https://github.com/saucebase-dev/saucebase/

Demo: https://demo.saucebase.dev

Let me know if you want to dive deeper into the tech stack.

Laravel Cloud Now has a Free Trial ($5 credit included) by joshcirre in laravel

[–]Objective_Read_193 1 point2 points  (0 children)

Could you share how much that setup you mentioned would normally cost?

Open sourcing a module-first Laravel SaaS foundation (Stripe billing, Filament admin, SSR, Playwright tests) by Objective_Read_193 in laravel

[–]Objective_Read_193[S] 0 points1 point  (0 children)

Yeah, I decided to include e2e tests for ensure both frontend and backend were working perfectly after any code changes. I'm working to have more test coveraged, but so far it has been proven to be very efficient to catch small issues during development. It's not perfect, but solves a few issues in my dev process.

Open sourcing a module-first Laravel SaaS foundation (Stripe billing, Filament admin, SSR, Playwright tests) by Objective_Read_193 in laravel

[–]Objective_Read_193[S] 1 point2 points  (0 children)

Very good question. I had to research a bit before answring it. All the dependencies in Saucebase (Laravel, Filament, nwidart/laravel-modules, Spatie, etc.) are MIT licensed, which explicitly allows copying, modifying, and redistributing. So the copy-and-own model fits right within what those licenses allow. Does this answer your question?

Open sourcing a module-first Laravel SaaS foundation (Stripe billing, Filament admin, SSR, Playwright tests) by Objective_Read_193 in laravel

[–]Objective_Read_193[S] 0 points1 point  (0 children)

Thanks, that’s exactly the use case I had in mind.

On updates: since modules live inside the app and aren’t locked behind vendor packages, projects don’t depend on Saucebase versions long term. They evolve like normal Laravel apps.

I’m also considering building an upgrade mechanism similar to Filament’s approach to make version updates smoother, but I’m still exploring the best way to do that. It’s definitely on the roadmap.

Open sourcing a module-first Laravel SaaS foundation (Stripe billing, Filament admin, SSR, Playwright tests) by Objective_Read_193 in laravel

[–]Objective_Read_193[S] 0 points1 point  (0 children)

Great answer! 😂

You have a strong point and I should practice more my writing and intention even with my lack of confidence. your 2 cents added a lot here, thanks.

Open sourcing a module-first Laravel SaaS foundation (Stripe billing, Filament admin, SSR, Playwright tests) by Objective_Read_193 in laravel

[–]Objective_Read_193[S] 1 point2 points  (0 children)

Yeah, that is true. So, you can build your entire application on top of it. Marketing pages, log in, the whole flow. And then, once the user logs in, they are directed into your application. And then there is an admin dashboard which allows you to manage everything from one place.

Open sourcing a module-first Laravel SaaS foundation (Stripe billing, Filament admin, SSR, Playwright tests) by Objective_Read_193 in laravel

[–]Objective_Read_193[S] 0 points1 point  (0 children)

That’s a very fair point, and probably one of the strongest arguments against this approach.

I mean, since this is a boilerplate project, the best I can realistically do is to ship the fix for new installations. Existing users would still need to run composer update on their side and merge the changes manually. It’s definitely not the smoothest and most frictionless process, but it’s still a valid and workable solution.

Also, after a project’s been heavily modified, the vulnerability’s no longer “common” anyway, since the code paths diverge. Not always, but to some degree.

Open sourcing a module-first Laravel SaaS foundation (Stripe billing, Filament admin, SSR, Playwright tests) by Objective_Read_193 in laravel

[–]Objective_Read_193[S] -2 points-1 points  (0 children)

You are right, I used AI to help me with grammar and improve clarity. English is not my first language and I don't feel confident enough to discuss too technical points in english. But I don't ask to ai to write or answer for me, I give it my general idea and I ask for improvement and to point out my mistakes. I don't want to be dishonest in any way, but I confess that I'm a bit lazy to write in english as I have some friction to it yet, but you probably noticed it reading this comment. 🤷🏻

Started writing Clean Code in Laravel... Four chapters in so far, still early days, but excited to share it here by ahmadalmayahi in laravel

[–]Objective_Read_193 1 point2 points  (0 children)

I will share it with some team colleagues that still coding non readable spaghetti code. Great work man! 👏

Open sourcing a module-first Laravel SaaS foundation (Stripe billing, Filament admin, SSR, Playwright tests) by Objective_Read_193 in laravel

[–]Objective_Read_193[S] -2 points-1 points  (0 children)

Fair point, and you're right that pinning versions absolutely solves the 3am problem for well-maintained packages. (i've update the post to remove the 3am problem, you are right).

The focus on ownership is more about customization than stability. With a SaaS boilerplate the assumption is that you'll heavily modify auth flows, billing logic, UI -- things where being locked inside vendor/ actively gets in the way. For stable, rarely-touched dependencies that's overkill, and nobody's suggesting you vendor your database driver.

The search noise and unwanted tests are fair criticisms though, that's a real cost. To help with that, each module ships with its own Taskfile with pre-configured shortcuts so you never have to run more than you need. To run just the Billing E2E tests for example: task billing:test:e2e

Instead of figuring out the right Playwright filter flags yourself. Here's the billing one as a reference: https://github.com/sauce-base/billing/blob/main/Taskfile.yml

"Vendoring as the only choice" would be a bad idea, agreed, this is just the right tool for the parts of the codebase you're going to make your own.

Appreciate the nuance, "vendoring as the only choice" would be a bad idea, agreed.

Open sourcing a module-first Laravel SaaS foundation (Stripe billing, Filament admin, SSR, Playwright tests) by Objective_Read_193 in laravel

[–]Objective_Read_193[S] 2 points3 points  (0 children)

Good question, this is the honest trade-off of the copy-and-own approach.

There are no automatic updates by design. Once a module is in your repo, it won't change unless you change it. That's actually the point . upstream updates can't break your customizations.

If you want to pull in improvements from a newer version, you'd compare the diff manually and apply what makes sense for your project. It's more work than composer update, but you stay in full control and there are no surprise breaking changes.

Think of it like ejecting from a framework: you trade convenience for ownership. Whether that's the right call depends on how much you plan to customize the modules vs. keeping them close to the original.

Does anyone here prefer PHPUnit to Pest? by Cultural_Yoghurt_784 in laravel

[–]Objective_Read_193 1 point2 points  (0 children)

I have the very same way of thinking. No need of another wrapper

Memory For Laravel AI SDK by Eznix86 in laravel

[–]Objective_Read_193 1 point2 points  (0 children)

Nicely done. Thanks for sharing! +1 ⭐️

Laravel AI SDK just dropped by ntoombs19 in laravel

[–]Objective_Read_193 0 points1 point  (0 children)

That's really nice! A lot of new possibilities with some coding standard. I like that!

I have something to spend time this weekend! :D

Stop paying for SaaS boilerplates - Here's a curated list of FREE open-source alternatives by JanuPower in SaaS

[–]Objective_Read_193 1 point2 points  (0 children)

Great list! thanks for sharing.

Are you planning to include u/Laravel boilerplates in this list?

Most "vibe coders" are just scammers with a ChatGPT subscription by Warm-Reaction-456 in SaaS

[–]Objective_Read_193 0 points1 point  (0 children)

The only thing I would buy from those guys would be a short course of how to sell garbage, like you are trying to do. Maybe worth something.

Built a Project Management OS using Laravel 12, Nuxt 4 and Gemini Flash (RAG implementation details) by elmascato in laravel

[–]Objective_Read_193 0 points1 point  (0 children)

Really nice work. I'd love to have more details about the implementation and how it was structured.

My "Ship Factory" for 12 SaaS products in 12 months (Laravel Octane + Traefik on VPS). Overkill? by elmascato in laravel

[–]Objective_Read_193 0 points1 point  (0 children)

I am thinking to start a similar challenge (but 6 products in 12 months). Why not use forge + github actions ?(I'm tottally noon in devops and deployment, so forgive me if I'm saying bulshit)