
Show HN: Open-Source Starter for SaaS Products - anandchowdhary
For the past few months, I&#x27;ve been thinking about building a few different SaaS products.<p>The problem is that there&#x27;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.<p>Introducing Staart — the starter template for SaaS products. Written in Node.js&#x2F;TypeScript with a beautiful Vue.js&#x2F;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.<p>I&#x27;d love to hear what the community thinks!<p>Check it out on Product Hunt: https:&#x2F;&#x2F;www.producthunt.com&#x2F;posts&#x2F;staart<p>GitHub: Staart (backend) and Staart UI (frontend) https:&#x2F;&#x2F;github.com&#x2F;o15y<p>Live demo: https:&#x2F;&#x2F;staart-demo.o15y.com
======
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.

------
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!

