awesome-saas-boilerplates VS cats

Amazing to see more options in the market! Consider adding your solution to: https://github.com/smirnov-am/awesome-saas-boilerplates .

I'm obviously biased, so take what I say with a grain of salt, but I also probably know more about this space than ~anyone else. I'd say that your characterization is pretty accurate. There are many similar products to Pegasus (you can find a pretty comprehensive list here: https://github.com/smirnov-am/awesome-saas-boilerplates) but most of them are either more focused on infrastructure/setup (e.g. cookiecutter-django or - as you noted - far less mature/maintained (most of the others on that list).

Don’t worry about technology too much. Google for “SaaS boilerplate” and use one that suits your existing skills. Example: https://github.com/smirnov-am/awesome-saas-boilerplates

https://github.com/smirnov-am/awesome-saas-boilerplates collects such frameworks, it lists 4 for Rails.

If you end up building one, please add it to https://github.com/smirnov-am/awesome-saas-boilerplates

I think what you're describing is an entire product category, often referred to as a "SaaS boilerplate" or a "SaaS Starter". There are a huge number of them, and you can find lists of them on github as well as places like starter.place.

https://github.com/smirnov-am/awesome-saas-boilerplates There are also some golang based

Skip team features until a customer (or somebody ready to pay) is asking for it. In our B2B SaaS we have Fortune 100 companies as customers and even they are so far fine with individual accounts. We implemented two-factor-auth after customer requests but it's shocking how few of our users actually switch it on, definitely not relevant to grow or get more sales.

Start with a framework that includes authentication. It will save weeks of work. https://github.com/smirnov-am/awesome-saas-boilerplates

Good luck for your MVP/launch.

Out of this frustration I've built: https://github.com/Endava/cats. It's for APIs, but mostly addressing exactly this case: don't use strings for everything, if you choose to use it though, make sure you add patterns for checking if things are valid, make sure you think about all the corner cases and all the weird characters that can brake you app, and so on.

If the API has an OpenAPI spec available, you can use: https://github.com/Endava/cats

This is why we need better tools which will give benefits for the added complexity. If you need to create both the feature files AND the code, it's just complexity with little benefits. But frameworks like https://github.com/karatelabs/karate or https://github.com/Endava/cats are hiding this complexity and remove the code layer entirely. Which, in my view, this is where you need to be in 2023, particularly for API testing.

I've built a tool specifically to test if these kind of characters will reach API backends: https://github.com/Endava/cats. My idea was that APIs should explicitly reject or sanitise input containing such characters.

Cats by Endava