#DEVDiscuss: Developing SaaS Products

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.

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"