The problem is that there's a lot of work to do before you even start building your product — adding support for recurring subscriptions, billing, GDPR compliance, authentication, . . . maybe your SaaS needs support for teams, scoped memberships, API key pairs, etc. etc., the list goes on.
Introducing Staart — the starter template for SaaS products. Written in Node.js/TypeScript with a beautiful Vue.js/Nuxt.js Progressive Web App (PWA), Staart takes care of all the boilerplate required when building a SaaS product, so you can focus on what really matter — your core product.
I'd love to hear what the community thinks!
Check it out on Product Hunt: https://www.producthunt.com/posts/staart
GitHub: Staart (backend) and Staart UI (frontend) https://github.com/o15y
Live demo: https://staart-demo.o15y.com
1) Define the product
2) Determine what features and functions are needed, and how it will influence architecture decisions.
3) Pick a stack to start with.
Normally, from node up to the front-end, I'm flexible, but these kits typically also are tied to specific databases, with specific auth solutions, and assumptions about the type of dev environment and flow that people want to see. If you are adding in billing and subscriptions, there are even more places we might end up on different pages.
Now, if the stack I choose ends up matching a solution like yours, terrific. I'll use it and be happy. But the more complete the solution, the less likely it is to be a match.
Perhaps a "Staart builder" is an interesting idea where you pick and choose what features you want for your starter and build from there.
The more important things to a SaaS is the actual product and not the authentication / backend / DB.
99.99999% of all early stage SaaS have absolutely no need for even 2FA, let alone multitudes of authentication.
It's just a lot of clutter and cruft for an MVP, which is what should be built.
I think a better framework would be focusing on the essentials, a very simple username + pwd, drop-in DB with a generic schema (Put it in JSON and export it from a file, rather than wrapping in an ODM / ORM object).
Finally you could wrap it up with a nice landing page template.
I would pay money for someone to give me a light, nice-looking landing page that is easily templated and it focuses on being light.
---
One issue with this kind of project is that it is difficult to adopt and build on to. It might be a great starting place, but it presents a fork of either total rebuild or stumbling through unfamiliar, cluttered code.
I agree with you that 2FA, auth rules for teams, etc., may be overkill, but the projects I'm working on (primarily focused as enterprise software alternates) all needed them, which is how Staart was born.
I am more and more pushed in the direction of a "check the features you want to keep and build your Staart package".
Perhaps that last part can be solved with thorough documentation about how to build on top of it. I am currently doing this by only working on project-specific files ("core product") and letting Staart handle auth/etc., but the second these need to be updated to be project-specific too, it will result in merge errors when updating Staart and so on. You're right, it's a problem I need to look into.