What tech stack do you use in your SaaS product?

I use Ruby on Rails because it allows me to iterate quickly on ideas and test them out. But I really use it because I want to focus on building the product / service / widget. Being a trained software engineer it is nice every once in a while to try out a new framework or something. But then I have two problems. Learning a new language, framework, or paradigm coupled with navigating what to build. So sometimes the new thing I'm learning has examples and it pidgin holes me.

I think that's why I like building products with Rails. I know it enough that I'm not having to learn anything new all the time. I can let my creatively flow into the product and into writing simple code to accomplish the things I need it to. If this was art, Ruby on Rails would be a deluxe oil paint set with tens of brushes for all the possibilities I could paint. Learning a new language or framework is starting over again with a single paintbrush and 8 water color paints.

When I saw this question I knew the answer for me. But four or five years ago I wouldn't not have seen the question beneath the question. Am I building with a stack that can build a product? Will I be successful with this language or framework?

I used to care a lot about the underlying technology. My passion for computers and the internet was catalyst by programming and growing my depth and breadth was only goal. But I started to realize that this of course matters to some degree. But the fact that I use Ruby or Node or Go doesn't mean anything to a customer's browser parsing HTML.

What matters is that you deliver a product that provides value. Arguably if that value is tightly coupled with performance and reliability then the underlying tech stack does make a larger difference.

But for the majority of SaaS, especially the user, account, billing, and general CRUD operations, any stack that will allow you to build fast is good enough.

It was a difficult concept for me to grasp that different maturity levels of products require more engineering rigor. For example I have a product, splitforynab.com that is powered by Ruby on Rails, PostgreSQL, and a digital ocean droplet. It has exactly 2 unit tests. Both are testing a really gnarly function I have for parsing an Amazon orders CSV and mapping that to transactions in YNAB. Nothing else has tests. But I definitely didn't want to break this function (and it took a little while to write). If this product were to get larger and make money, then I might think about testing more. I might need to scale the services different (or even have multiple services ;) ). But for now I'm still able to iterate on the product.