What would be your choice for setting up a new SaaS project for 2022?
I’m a bootstrapped founder of a SaaS product, working with an agency run by an ex-colleague of mine for development. The existing infrastructure is a React/Node/GraphQL FE + BE deployed via an ECS container on AWS.
We’re looking to make a pivot into a new product with a new infrastructure, and would like to make use of boilerplate as much as possible to focus on the core of what will be the MVP. That means not building from scratch the following elements: - Auth - Payments - Hosting for FE + BE - Database
We want to continue with our current tech stack on the FE + BE(React/Node). I’ve love to know people’s recommendations and what they’ve found to work in the past.
74 comments
[ 3.3 ms ] story [ 135 ms ] threadGreat advice. Build now and hope that in a few years you need to change parts of the stack because you’ve outgrown them. That’s a great problem to have.
There’s a good chance that the business that succeeds isn’t the one you are starting today. For example, IIRC Slack came out of game development.
There may be a handful (if any) of companies that failed due to tech stack selection. I highly doubt that though.
Backend: Supabase (handles auth out of the box) and some Cloudflare Workers when SQL procedures/functions aren't optimal for a specific use case
Payments: Stripe
Django's database modeling (using just that) gives you migrations and some form of typing that take you quite far. You're doing the API on querying on the Rust side, so the ORM isn't really a big concern. The admin can also take you quite far and is incredibly useful for giving others access to view and/or modify data if you need to.
This is also relatively easy to decouple if you need to scale.
Rule number two, use what can last you for the first three years.
Rule number three, build with considerable haste. Don’t choose anything from 1 & 2 that limits that.
Everyone’s preferences from there are all relative. If I was building something from scratch today I’d use cloud run for containers, stripe for payments, datadog for monitoring and APM, RoR for my app, Postgres, bigQuery for analytics (if needed), Vue for my frontend, postmark for email, cloudflare, and probably a mix of other tools as needed.
If I was screwing around and not trying to use what I know, I’d probably try to build as much as I can on top of vercel and planetscale. Vercel makes killer projects and tools, and I can see planetscale being a market leader in 10 years that everyone uses by default. But, that’s a big bet to make when starting a new company.
[1] https://lucjan.medium.com/choose-exciting-technology-e735bba...
[1]: https://jumpstartrails.com/ [2]: https://bullettrain.co/
For Authentication, I'd say go with Keycloak. Yes, it's a reasonably big java program. But it also covers a lot of authentication stuff transparently for you - your application can just use whatever OIDC client library you have, and you can centralize everything in keycloak server, including integrations with external authentication providers (Google, FB, random OIDC, client's internal systems for B2B SaaS, etc.) and you have low chances of waking up and finding out you're going to rebuild your authentication stack because you coded yourself into a corner.
Authorization is a trickier case, but so long as you make it so that you can get "role" or similar attribute out of keycloak into your applications, you can start with hardcoded role names (possibly with extra attribute describing organization etc.) all the way to something complex like Open Policy Agent or even Zanzibar.
I'd probably stick to reasonable written docker containers and vendor-provided SQL database as backing store + graphql interface (I do not use GraphQL myself, but I recall that at least for postgres there appear to be reasonable options?). Use what you know to reduce rewrites.
With docker container, you can go from crappy VPS with docker compose (not recommended, but it does work, it's just crap - been there done that), through ECS (personally I dislike it, but you're already working with it, maybe AWS tax won't hurt you too much?) to kubernetes deployment (most complex to begin with, but scales developer resources well thanks to good abstractions, might be of interest if you find a need for deployment flexibility or find yourself in need of extreme cost efficiencies in hosting). If your code runs well with such setup you can probably also just run on Heroku if the economics fit.
Standardize on observability stack, whether paying for hosted one like honeycomb, to setting up prometheus+loki+grafana.
You're already reasonably successful under my metrics ;) but remember that while setting up some of it might take more time than just hacking it up, handling it well has compounding interest result on later development.
Check carefully what will be your budgetary effect for "buy vs. build", both in terms of coding from scratch vs. deploying existing OSS product, and in terms of hosted vs. self-deployed. I have no idea about your budgets, but I do not joke about AWS tax lightly :)
We use Stripe and it has also served us well so far.
The development team is mostly FE focussed and we have limited access to a dedicated DevOps engineer which is why I’m keen to keep that aspect of the stack as ‘standard’ as possible
Since AWS is too expensive, I figure Heroku is right out, and it pushes towards cost optimization a lot.
Personally I'd go with some low-cost hosted kubernetes so long as the provider also includes database hosting and integrates logging and such - this means avoiding some of the most complex for starters tasks of handling it - but I also already have k8s experience. Despite what some people say it doesn't have to be complex, but I'd consult with whoever you have available regarding operations - who knows, they might offer some services you didn't know about before.
Keeping to something like "twelve factor app" will help to keep your stack simple to deploy no matter which way you go, IMO.
Meteor has built-in Auth and DB (though it's Mongo but why not?), don't know about the others but there are packages probably.
Edit: forgot to mention it has hosting via Galaxy which I've never used but it's there.
Hear me out.
The #1 problem you have as developers is marketing.
The #2 problem you have is validating demand from customers.
So force yourself to do the uncomfortable steps ASAP, while also making it easy to pivot by launching with the smallest possible stack.
If you can launch with something like Airtable + Webflow + Zapier + Typeform, you can get something out there in weeks instead of months/years. It will be relatively easy since your team is technical.
Then release it to the market and see if it sticks.
The power of a lightweight stack is NOT the ability to find Product-Market fit instantly.
The true power comes from making the 20-30 iterations it will take to actually find Product-Market fit less painful than if you had to rebuild from scratch every time you had a new idea.
I'm interested in what's worked better for you and why you think no-code is a bad choice.
I would equate basing your business on a no code product is taking on ultra high interest tech debt to get something working up front. Sure you get somethint shiny quickly but thats the moment that system peaks and from there its just creating drag.
And the thing is no one ever decides to just throw the working thing away and rewrite so you end up tinkering with these tools with diminishing returns for way longer than is justifiable because youve got other stuff to do and it easy to deprioritize.
The points about fast validation are valid but a competent person van protoype as fast or faster with most modern web frsmeworks and those systems will be viable for 100x the timespan ad what the no code tool gets you through.
- Vercel and Next.js for frontend.
- Clerk.dev for authentication and account management
- Hasura for database
- Heroku + BullMQ for cronjob, background processing.
- AWS S3 for storage
- Search engine (many options to be chosen)
- Cloudinary for images.
Not easy but simple, no need for a Rockstar DevOps engineer.
It’s okay not to write unit tests at the beginning.
It’s okay to run everything on a single ec2 instance.
It’s okay to not have “forgot password” flow when you launch your project v0.1.
It’s okay to ssh into server to deploy code at the beginning.
Many billion-dollar companies were using pretty bad software engineering practices at the beginning of their life (maybe first 5 years). Engineering is just a small part of a tech business.
There's no excuse for not having the ability to reset your password with so many turn key solutions and libraries available nowadays. But I agree with all the rest.
In reality it's whatever you're most productive with.
It's about finding a problem to properly solve, not about the tech stack.
My rule of thumb is buy for generic build for core.
For SaaS/web app aspects? For me, probably a flavor of the PETAL stack i.e. Postgres/MySQL + Phoenix + Liveview + Tailwind. My core is usually some kind of state machine modeled in boring structs and functions. No frameworks - no libraries if I can help it. Pure as possible when possible for core components.
Buy over build (No code / Low code / SaaS / Spreadsheets / CRMS / etc) if its generic and not a core concern. Lead management, a lot of Sales, marketing and case/customer service ticketing concerns in a lot of businesses are often good candidates for buying over building.
Never buy if the software is a core business capability - write that code yourself if you can. You can avoid a lot of maintenance risk over time this way.
The worst case scenario is you ship quickly and don't find a product market fit, so ship quickly for that feedback.
The next worst case scenario is you found a fit but your core business capability is tied to a third party tool you don't control and it starts getting in the way.
No API? Don't buy. No real-time API in 2021? Probably don't buy. There's good low-code tools but there are also predatory SaaS tools out there that can enact suffering and delays to your business, so weigh that decision carefully.
I built it from Node.js and Vue because I knew them very well and found that they made it very easy to do the kind of work I wanted to. Even still, there was still a lot of extra stuff I had to set up each time, like the basic scaffolding, user authentication, subscription payments, teams/permissions, etc. Once I started building myself a re-usable version, I realized I could add a bit more rigour and sell it, as well.
So that would be my choice.
But if you strongly prefer other languages, there are other great boilerplates out there as well:
- SaaS Pegasus, if you like Python (https://www.saaspegasus.com/) - Laravel Spark, if you like PHP (https://spark.laravel.com/) - Bullet Train, if you like Ruby (https://bullettrain.co/)
I think low-code, like a good boilerplate, outperforms no-code if you're building anything that needs to scale beyond simple built-in functionality. Once you need to do something the no-code app doesn't let you do, you're faced with a pretty uncomfortable choice between rebuilding the whole thing from scratch or figuring out some ugly hack to bolt on the functionality you need.
- Supabase: backend as a service
- n8n: workflow automation
- AppAmith: back-office apps
- Sentry: error monitoring
- Openreply: session monitoring
- Posthog: product anaylitics
- Plausible: website anaylitics
- Metabase: data analytics
I don't have any front end recommendations, but I lean towards react and buying a theme/template.
For hosting, skip the k8s and use Render or Heroku.
Btw, here's a tutorial for hooking up Supabase, n8n and Appsmith together: https://www.appsmith.com/blog/the-modern-stack-to-build-inte...
Plausible is pretty awesome too, we use it and are very happy!
Guessing you'll also get a lot of recommendations for Firebase, which suits a lot of use cases.
2. Use whatever stack you know to build what they will pay for.
3. Rinse and repeat and add features as customers pay for them.
As a default: Django, Django Rest Framework, HTML, CS, and either JS or Typescript. (Typescript is nicer, but JS saves a build step and config, and some headache related to DOM types)