#DEVDiscuss: Developing SaaS Products

Time for #DEVDiscuss — right here on DEV 😎

How To Build a Scalable SaaS Backend in 10 Minutes With 100 Lines of Code 🚀

JS for ZenStack ・ Jun 21 '23

#webdev #javascript #typescript #architecture

Inspired by @jiasheng's Top 7 post, tonight’s topic is...developing SaaS (software as a service) products!

In their post, @jiasheng shares about their project @zenstack and how it can be used to build "a scalable SaaS backend in 10 minutes with 100 lines of code" 🔥

It’s hard to build a scalable SaaS system. Having been involved in the development of four commercial SaaS products at my previous company, I've come to realize the multitude of complexities that arise compared to typical consumer products. Among these complexities, one prominent area lies in the intricate realm of permission control and access policies.

Questions:

• What's more important to you when building a SaaS: reducing complexity, or having lots of features and functionality?
• How have you approached access control with SaaS apps in the past?
• How does building SaaS at the startup level differ from working on a SaaS at the larger, commercial level?
• Any triumphs, fails, or other stories you'd like to share on this topic?

Comments

[JS]

Let me throw a brick to get you started 😁

1. In my humble view, I believe that reducing complexity does not necessarily conflict with adding functionality. However, it does demand expertise, knowledge, and skill to pursue simplification effectively. Check out our own experience shared by my partner @ymc9
   

   

   

   For Most of Us, Simplification Rules

   ymc9 for ZenStack ・ May 7 ・ 4 min read

   #architecture #career #programming #startup

2. Yes, we have built more than 5 SaaS products. There are some common things we have to implement every time with different stacks like:

   • Multi-tenant
   • Soft delete
   • Sharing

   It’s not only tedious but also hard to make it right. That’s one of our own pain points and the big reason why we built ZenStack.

3. Based on my personal experience, I have found that at the startup level, prioritizing speed is crucial as it allows for rapid validation of product-market fit. This agility enables quick adjustments and changes in direction if needed. However, at the commercial level, you need to put more focus on stability and extensibility because there are people running business on it already.

4. If you are planning to build a new product, you could verify people’s responses before building it. In one of our cases, we simply created a website with the normal registration process as if it’s already fully launched. Then we did SEM to get traffic to our website to see what’s the click rate and conversion rate for our website. If it doesn't meet the expectation, we know we went in the wrong direction. Of course, for the people who registered, you should tell them the truth and give them some credit as your early adopters. Most people are actually very nice about it.

[Fyodor]

Thanks for the valuable insights 👍

Would be interesting to hear your "unopinionated opinion" on possible overheads (and future maintenance hassle) of adding such kind of new abstraction level over the codebase (as ZenStack, or refine, for instance) as compared to kinda "barebones" way (with all the mutual tradeoffs).

[JS]

That’s a good question. I’m trying to be unopinionated, but as I’m the creator of ZenStack, you’d better make your own call. 😁

In my humble view, the major overheads of adding an abstraction are:

1. The learning curve for something new.
2. Loss of flexibility.
3. Stability.

But coming to the trade-off, I would think it has to be opinionated for each individual. For example, personally, I think it’s painful to write raw SQL and maintain it, whereas not for some people; They might find running a generation command every time to be cumbersome, whereas I do not. The more general case is that I consider type safety to be of utmost importance, although I am aware that some individuals, such as the founder of Basecamp, still prefer JavaScript over TypeScript:

twitter.com/dhh/status/16550766687...

Also, I can’t deny that trust is also a big factor that also varies with each individual. It’s what we keep working on and sometimes it takes time.

As always, there is no one-size-fits-all approach, and you have to make your own trade-off. For me, that’s the beauty of the software development world.

[Venkatesh KL]

1. What's more important to you when building a SaaS: reducing complexity, or having lots of features and functionality?
   • As many questions it depends.
   • If I am in an early stage SaaS, I would prefer to get a decent set of feature set that would sell or bring more revenue.
   • In an established state, I would go with making it easier to scale AND/OR for more engineers to work on.
     • It may be something like a simple & shared ACL(Access Control List) so that everyone else don't need to worry about that.
     • Or a micro-service approach(if possible), so that each micro-team can work on their feature alone without any(or little) dependency on someone who's been in the system for a while.
2. How have you approached access control with SaaS apps in the past?
   • I have worked on building an ACL layer for a SaaS startup. We have just built it a user & org/client level for that, i.e., we would assign roles to users for that specific client. It processed rules using a yml file(little crude but worked).
   • Every user is authorized for org level access & denied by default to write, unless they had explicit write access to that client org(or is super admin).
   • It would be a simple way like, if the user is:
     1. Customer/Customer Success - Admin access for clients they own
     2. QA - Read Access for clients they work for
     3. Support Engineer - Read access to all client apps
     4. Senior Devs/HotFix Teams - Admin access across all clients. These are mostly people who understand in & out and will not mess up any config unless necesary.
   • This is not a foolproof solution & I think it's been working well for them for quite sometime. I don't work there anymore, I have not received any complaints from my ex-colleagues yet.
3. How does building SaaS at the startup level differ from working on a SaaS at the larger, commercial level?
   • Startups are more focused on releasing features rapidly as mentioned for question#1, where as large scale SaaS have a very defined process structure which would make entire engineering/product pipeline much strict.
   • For example, early stage startups(most of them)
     • are not afraid to fail-fast & will be more interested to show-off to their customers on the no. of features available compared to competitors. They
     • look to cross-sell more features as they are built.
     • If a feature needs to be enhanced, they will mostly see if existing will be sufficient & cramp it there otherwise build everything fresh(at least it was how where I worked before).
     • Not clear process nor roadmap. If it's present will be dominated whenever a high-paying client needs something, which is pretty frequent.
     • Everybody is expected to do everything. No clear separation between Dev/Ops/Support. Everyone in Engineering is generally exposed to everything.
   • In a large scale SaaS,
     • Engineering Delivery & Process is generally good & extremely streamlined.
     • Good coding & QA practices
     • very clear teams(Dev & Ops may be separate teams) with clear responsibilities.
     • Engineers may have to scratch their itch to understand how other pieces of the puzzle work.
4. Any triumphs, fails, or other stories you'd like to share on this topic?
   • Worked on a feature known as User Generated Content(reviews, customer feedback, coupons, social media integration & much more) & it was(and still) is on hold as users were happy with the existing crappy UI which was sufficient for most of them.

My suggestion for anyone would be "Don't get disheartened if lot of your hard work is scrapped or goes unnoticed"