HN Explorer

Show HN: Open-Source Starter for SaaS Products

4 points by anandchowdhary ↗ HN
For the past few months, I've been thinking about building a few different SaaS products.

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

6 comments

[ 3.2 ms ] story [ 22.9 ms ] thread
ecares
Why didn't you use a querybuilder (like knex) that is db agnostic? Here users are stuck with MySQL.
anandchowdhary
That sounds like a great idea! I found a few ORMs and decided to go that route first (for strong TypeScript support), but later dropped that idea to my current interface-MySQL implementation. Now that I see it, this is the perfect use case for Knex and I'll give it a shot. Thanks again!
codingdave
I love starter templates like this. But I have yet to use them in real products, because they are inherently opinionated. And I like my tech choices to be driven by product needs, not the ease of launch. I'm not philosophically opposed to using something like this, but my process is more along the lines of:

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.

anandchowdhary
I understand and this makes a lot of sense. For me, Staart was a way to streamline my own build-and-launch process and I designed the Stack to fit my personal needs. Based on other comments, I do want to make it as context-agnostic as possible while keeping the basics, like authentication, authorization, etc.

Perhaps a "Staart builder" is an interesting idea where you pick and choose what features you want for your starter and build from there.

madamelic
Great idea, but I agree with codingdave. Too opinionated and only makes things more difficult.

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.

anandchowdhary
Thanks, madamelic. Like I said to codingdave, Staart was built as a tool for me, and I published it to see if others might want to use it too.

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.