What would be your choice for setting up a new SaaS project for 2022?
74 comments
Rule number one. Use what you know.
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.
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.
Using what you know is not only valid choice and you can build a successful startup while learning at the same time [1]. Using what you know might be a valid choice when you are much more excited with the business itself rather than building the product, but I think it’s rarely the case for developers who want to try enterpreneurship.
[1] https://lucjan.medium.com/choose-exciting-technology-e735bba...
[1] https://lucjan.medium.com/choose-exciting-technology-e735bba...
I disagree slightly. It depends on where you are. If you are literally starting out like OP, forget number 2 and 3. Only focus on #1 because if you don't get a few paying customers soon, you will be dead anyway. Focus on surviving first. Forget about 3 years. If you can make it 12 months, you are doing great. Rule #2 is important but not until you have a few paying customers and some product market fit.
Rule #3 I would say comes way later. way later.
Don't you consider #3 (rapid development) can be crucial in the quest to get paying customers and survive the first 12 months?
#3 is actually crucial because if you only go by #1, and you only know C++, I will not get far in making a full stack app.
the big caveat in planetscale is that you pay per row READ. so make damn sure you use every index afforded to you
1. Use whatever you already know.
2. Start building now.
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.
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.
> It’s okay to not have “forgot password” flow when you launch your project v0.1.
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.
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.
"There's no excuse" and "it's ok" are not mutually exclusive. The point being that if you have no customers, working on a password reset feature instead of marketing, can be a poor choice. I know of several bootstrapped SAAS that didn't add such a feature until reaching 4 or even 5 figures of MRR. They just did it manually for their customers until then. Not ideal, but it worked for them and is indicative of the mindset needed.
Fair enough. I suppose it's highly dependent on the app.
Use no-code
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.
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.
N8n instead of zapier since it’s open source and free
Terrible advice imo
Why is it bad advice? Genuinely interested.
I'm interested in what's worked better for you and why you think no-code is a bad choice.
I'm interested in what's worked better for you and why you think no-code is a bad choice.
Yeah fair, that was a pretty bad answer.
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.
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.
There’s an illusion that no-code is easier than firing up a usual mean/mern stack with a DB behind it. The benefits of not using no-code are you can easily adapt because you’re not baked into these no-code workflows. They end up falling apart pretty quickly.
This question almost comes up daily nowadays. And I always reply the same "Use what you already know because unless you are at google scale, all languagues and stacks can do the job". If you know React/Node, go for it. Don't waste time optimizing tech stack. Build. Now.
That's true - but decisions made on things like deployment/auth/hosting in the early days can give you a good base to build off of. For the first product we built it started off as a Laravel app but building in Javascript made more sense for us given the team we had access to.
Not sure why you would need to switch from Laravel to JS other than the fact that your devs knew JS more ? Honestly, early days decisions are more about finding product market fit, customers and sales. If you cannot do those, you will be dead anyway and tech stack won't matter. If you are changing tech stack, the only reason to be directly helping do more revenue and almost always, tech stack is not the issue in acquiring customers and sustaining a business in the early days.
There may be a handful (if any) of companies that failed due to tech stack selection. I highly doubt that though.
There may be a handful (if any) of companies that failed due to tech stack selection. I highly doubt that though.
> Build. Now.
Great 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.
Great 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.
Hear me out: Django for database modeling and the free admin, then the API fronting your service in Rust (actix-web, or your choice), with whatever frontend you feel fits you best.
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.
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.
Better yet, use Django (or Rails) with a simple distributed frontend until you need anything else.
Totally a valid option as well. I personally prefer Rust's strict environment and find I build better that way, which is why I go this route. I find the trade-off to be acceptable but YMMV, as always. :)
Absolutely. I’d be curious to see what a rust api layer like this looks like in practice.
You can get all of that plus some with Supabase or Hasura without having to write a single model or resolver, all on top of rock solid Postgres. And hook up Appsmith if you need custom admin.
For getting the business off the ground - there's often a build vs buy question.
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.
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.
In the Rails world Jumpstart Pro and Bullet Train are two popular SaaS app frameworks.
[1]: https://jumpstartrails.com/ [2]: https://bullettrain.co/
[1]: https://jumpstartrails.com/ [2]: https://bullettrain.co/
Are there any open source boiler plates for RoR?
Yes, there is open source version of Jumpstart - https://github.com/excid3/jumpstart
Laravel or Rails. Keep as far as you can from SPAs, they're a waste of time and never lead to a better solution unless you're building an offline first web app or something like Google Maps. A dashboard or your usual CRUD app don't need to be an SPA.
Use a full stack framework, don't reinvent the wheel. Look into Livewire, Hotwire and Unpoly. Hire people that are neither JavaScritp fanatics, nor Go fanatics, nor Kubernetes fanatics. Hire people with an open mind and focused on building your product and not obsessed on whatever they think the best tech stack is.
Unless your new project is API only (has no frontend) then don't use Django. Django is great for building backends, but its frontend solution is a joke and that really feels like something from the 90s (that's why I recommend Laravel or Rails).
Regarding infrastructure, a Dockerfile and Google App Engine is all you need. No need to build your own kubernetes cluster for a project you're just starting out.
Use a full stack framework, don't reinvent the wheel. Look into Livewire, Hotwire and Unpoly. Hire people that are neither JavaScritp fanatics, nor Go fanatics, nor Kubernetes fanatics. Hire people with an open mind and focused on building your product and not obsessed on whatever they think the best tech stack is.
Unless your new project is API only (has no frontend) then don't use Django. Django is great for building backends, but its frontend solution is a joke and that really feels like something from the 90s (that's why I recommend Laravel or Rails).
Regarding infrastructure, a Dockerfile and Google App Engine is all you need. No need to build your own kubernetes cluster for a project you're just starting out.
Frontend: React with tailwind hosted on Cloudflare pages
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
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
Okay, well, I'm biased because I literally make a SaaS starter kit/boilerplate based on Node.js and Vue called Nodewood: https://nodewood.com/
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.
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.
The honest answer is: it does not matter. Great products have been built on very diverse tech stacks. Million dollar businesses have been built on a single VPS running PHP, without version control.
It's about finding a problem to properly solve, not about the tech stack.
It's about finding a problem to properly solve, not about the tech stack.
I don't doubt this, but the more time that can be spent on building the 'business logic' the better, and one way of achieving this is to rely on sensible defaults/frameworks for things shared across all SaaS tools like hosting/deployment.
For anyone doubting, I've seen examples of the PHP sites — posted here!
I’d recommend you check out https://redwoodjs.com/ for the flexibility, modern tooling and great docs. Some other features included OOTB:
- Frontend In React
- Scaffolding code generation CLI
- GraphQL
- Prisma
- TypeScript
- Plug n play Auth
- Plug n play Database
- Easy deployments to Netlify, Render, etc
- Good community and long-term outlook.
Only thing that’s really lacking is the payments, but you should be able to easily integrate without issue into any third-party services like Stripe.
Good luck!
- Frontend In React
- Scaffolding code generation CLI
- GraphQL
- Prisma
- TypeScript
- Plug n play Auth
- Plug n play Database
- Easy deployments to Netlify, Render, etc
- Good community and long-term outlook.
Only thing that’s really lacking is the payments, but you should be able to easily integrate without issue into any third-party services like Stripe.
Good luck!
Thanks this is the kind of thing I was looking for, an opinionated framework that complements the development strengths we have and speeds up our 'time to deploy' for a product that we can get into users hands.
Interesting to see the deployment choices used by these kinds of frameworks as well.
Interesting to see the deployment choices used by these kinds of frameworks as well.
These recommendations have an emphasis on being open source but with paid options and low code:
- 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.
- 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.
Thanks a lot Chase for mentioning Appsmith.
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!
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!
I set up Appsmith yesterday to build an admin dashboard for a Postgres app (Hasura). I'm just blown away. Writing a database query for widget feels so natural. I hope y'all expand past admin type of apps to full fledged front end app components.
NextJS and NextAuth would cover a lot of ground.
Guessing you'll also get a lot of recommendations for Firebase, which suits a lot of use cases.
Guessing you'll also get a lot of recommendations for Firebase, which suits a lot of use cases.
What other accelerators do you use with NextJS?
No idea about payments, as that can heavily depend on locality (Stripe might be an option as they expand to more countries, though).
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 :)
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 :)
Well we went with AWS for this current project because they offered good/free ‘first year pricing, and now we are being bitten by them a little, our workload is not huge but when you’re bootstrapped these kinds of costs add up, and they’re especially pernicious because it hasn’t made sense financially for us to pay someone to optimize them lower. Hence my concern to make good decisions early on this new project.
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
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
Well, I'd look into ways to get off the AWS train then. You're already in better starting position given the use of ECS, so you have some preparation for running containers.
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.
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.
Can I coattail on this question? If you were building an iOS only app with no other plans to build a web app ever, would you bother trying to build your own backend or stick to things like CloudKit / apple sanctioned solutions. Thanks!
[deleted]
If you subscribe to the Lean Startup ethos, then testing your hypotheses should be your primary goal.
> As you consider building your own minimum viable product, let this simple rule suffice: remove any feature, process, or effort that does not contribute directly to the learning you seek.
So the answer here is probably... Whatever you're the most comfortable with! Most of the code/infra you are building in the early stages is likely to be nuked at some point anyways :)
Sticking to your existing toolset also has the benefit of allowing you to get faster over time, as you gain familiarity with your toolkit and build reusable abstractions to reuse in your next pivot.
> As you consider building your own minimum viable product, let this simple rule suffice: remove any feature, process, or effort that does not contribute directly to the learning you seek.
So the answer here is probably... Whatever you're the most comfortable with! Most of the code/infra you are building in the early stages is likely to be nuked at some point anyways :)
Sticking to your existing toolset also has the benefit of allowing you to get faster over time, as you gain familiarity with your toolkit and build reusable abstractions to reuse in your next pivot.
For fast win, i recommend:
- 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.
- 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.
I don't see it mentioned nowadays but who is still building with Meteor? Is there anything that beats the convenience Meteor provides, especially for MVPs? Also MVP shouldn't be a ton of code, so you're always free to port it to another architecture when you have confirmation for whatever you're testing.
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.
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.
I built a React & Node SaaS boilerplate (https://usegravity.app) so I'm firmly in the camp of 'it's better to buy rather than build' for most use cases. The question then is choosing the right boilerplate stack, which I guess comes down to personal preference. There's a lot of different options to choose from now with different stack choices :)
1. Get a customer based on a mock-up/landing page.
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.
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.
For the backend and auth I'd prolly use Supabase. For the frontend Next and Vercel, which also offers serverless functions when you need them.
I remember someone showcasing (or even just posting a comment in reply to a thread depicting aggresive policies from mailchimp, cannot recall) their own PaaS for email delivery alternative to mailchimp / postmark. It did offer a very nice starter with free emails. Maybe it was mailjet, but I am not sure.
Could anyone post the link? Thanks in advance.
Could anyone post the link? Thanks in advance.
My 2cents:
Rule #1, use what you know only if you already have paying customers. You can rewrite it afterwards if required.
Rule #2, if you don't have paying customers and want to build the software anyway, then use the software stack for which you will be able to very easily get developers so that you can then concentrate on marketing/sales/fundraising.
Rule #1, use what you know only if you already have paying customers. You can rewrite it afterwards if required.
Rule #2, if you don't have paying customers and want to build the software anyway, then use the software stack for which you will be able to very easily get developers so that you can then concentrate on marketing/sales/fundraising.
In addition to the nice arguments about using what you know, i'd also like to offer the following link: http://boringtechnology.club/ (or in video form: https://www.oreilly.com/library/view/oscon-2015-video/978149...)
So essentially, my additional suggestion would be to choose battle tested software, that has few unknown unknowns and the limitations and quirks of which are familiar to both you and the industry.
I'll also share a few subjective recommendations below, some of which don't explicitly answer the OP's question, but might be helpful nonetheless.
In regards to boilerplate and turnkey solutions:
So essentially, my additional suggestion would be to choose battle tested software, that has few unknown unknowns and the limitations and quirks of which are familiar to both you and the industry.
I'll also share a few subjective recommendations below, some of which don't explicitly answer the OP's question, but might be helpful nonetheless.
In regards to boilerplate and turnkey solutions:
- they may or may not exist in the form that you wish and when they do, they'll possibly be SaaS or will need to be adapted anyways
- for example, Firebase is pretty popular, but also SaaS, so there's vendor lock in
- something like Parse might be useful and can be self hosted: https://parseplatform.org/
- have a look here for more options: https://gist.github.com/PARC6502/ee4db400a05e6eb6d0981bb8cd4e4c1c
- that said, for any complicated bits, especially those that will make you legally liable, use external services: typical use cases could be e-mails (SendGrid or something else) and payments (Stripe or PayPal, though some dislike PayPal)
- React is popular, yet changes comparatively fast and can therefore make you deal with lots of external tech debt (e.g. hooks)
- Angular is a good "batteries included" option, yet kind of heavy and TS may or may not be good for you
- Vue is reasonably stable, apart from the v2/3 migration, it should slow down in a year or two making it even more stable, good middle of the road option
- Svelte is still too new
- as far as CSS frameworks go, i'd just commit the sin of using Bootstrap, since it's exceedingly boring and pretty simple
- PHP (Larvel), Ruby (Rails), Node (Express.js over Koa/Deno for now) or Python (Django over Flask for now) are all good options for simple CRUD apps, yet may struggle a bit with scheduled processes and the like, performance probably isn't too much of a concern initially
- Java (Spring Boot) or .NET (ASP.NET Core or whatever) are also really dependable choices when you need something with a more sophisticated lifecycle (e.g. Quartz for scheduled processes), however can also come with lots of technical complexity and the frameworks in particular can slow you down a bit
- other languages like Go/Rust/Kotlin are promising yet more niche, as would using another paradigm than OOP - if you feel comfortable with that and aware of what you're signing up for, go ahead
- MariaDB/PostgreSQL for when you need a relational DB, the former is okay for simple CRUD (and has good tooling), whereas the latter is more advanced and possibly a better choice if you enjoy in database processing or have to work with GIS data (PostGIS is great), though the tooling feels off (pgAdmin pales in comparison to MySQL Workbench, though some don't care about ER models and generating scripts from those, so DataGrip etc. are also good)
- MongoDB for non-relational data or simply cases where not having a schema is permissible, personally wouldn't recommend it that often, but it's one of the most established options out there
- S3 or a compatible implementation (MinIO or Zenko) for storing files and blobs of whatever sorts that you need
- Redis for a key-value storage, it just works
- round robin DNS can take you far and specialized load balancers aren't always a necessity, though you might want to look into Cloudflare for some protection anyways (debatable, some dislike one corpo having that much control)
- Caddy is probably one of the better choices, gives you Let's Encrypt out of the box, is performant enough for most cases and has a nice configuration format (even though IMO v2 is worse than v1)
- Nginx is also really common and decent for most use cases, though a bit more problematic for proxying in comparison to Caddy
- Apache has also recently gotten support for Let's Encrypt baked in (mod_md in 2.5 https://httpd.apache.org/docs/trunk/mod/mod_md.html), though apart from that it's sometimes unpleasant to use and the new functionality might need a while until stable
- Traefik is also liked by some people, like a bit more advanced Caddy, but personally haven't used it, maybe look into it
- REST is a pretty good option for most cases (consider OpenAPI too)
- avoid SOAP for the most part (WSDL was an awesome idea, but is a pain in practice)
- gRPC seems like a pretty established option too, but REST should be enough
- GraphQL also seems to have a lot of hype around it, but REST should be enough (unless working with highly dynamic content)
- target something common across all of your application components, such as OCI containers (typically with Docker or Podman)
- if using containers (which can get rid of a lot of ops pain points, if used correctly), consider simple orchestration, like Docker Swarm (with Portainer) or Nomad
- that's also really good because of overlay networks, so you don't end up misconfiguring something and exposing your DB to the world, instead every exposed port should be explicitly defined and under normal circumstances just be your web servers (and maybe a container that acts as a proxy for you to access other containers' ports through SSH tunneling, though only with key auth etc.)
- if you are someone who likes dabbling in more advanced tools, cautiously consider K3s, don't always pick a "full" Kubernetes distro
- generally, i'd just go for a VPS to avoid any sort of a vendor lock and to migrate between providers more easily, should the need ever arise
- Hetzner: one of the better platforms out there for getting your stuff to run https://www.hetzner.com/cloud
- Scaleway: another relatively affordable platform (though prices changed a while back) https://www.scaleway.com/en/
- Time4VPS: an affordable option, though the UI is a bit antiquated https://www.time4vps.com/?affid=5294 (what i use, affiliate link)
- Contabo: rather good deals, especially for storage https://contabo.com/en/
- DigitalOcean: many also enjoy their offerings and especially the project grouping functionality https://www.digitalocean.com/
- Vultr: a good alternative to DigitalOcean https://www.vultr.com/
- colocation: some also do this with their own hardware, but that can be somewhat expensive
- large platforms: unless necessary, avoid AWS, Azure, GCP, Oracle Cloud etc., since they can be really expensive
- generally prioritize EOL dates over most other things, as long as you use the most popular distros out there
- in practice, the choice would have been between CentOS and Ubuntu LTS, but the former is now dead
- so, just go with Ubuntu, or if you dislike canonical, go with Debian
- you can go pretty far with a single database and a monolith, don't introduce accidental complexity, since that will make dealing with domain complexity harder
- consider writing a modular monolith and ideally make the monolith horizontally scalable with feature flags: https://blog.kronis.dev/articles/modulith-because-we-need-to-scale-but-we-also-cannot-afford-micro-services
- cut corners, but have backups
- test those backups
- have unit tests for your core business functionality and validations
- have integrations for most of the stuff that you can write them for
- please have separate test environments for anything that you deploy
- please have clear onboarding instructions ready for when you need to growThis is my personal best that worked for me the previous years:
Frontend: angular hosted on any static page hosting like GitHub pages or cloudflare.
Backend: nestjs with typeORM and MySQL or postgres
This is all typescript so even a small team can do a fullstack job.
Who will your customers be and how will they interface with the SaaS?
I do a lot of enterprise SaaS integrations and the number of platforms that aren’t enterprise grade slows us down. Almost like there’s a market opportunity there… (ahem).
I do a lot of enterprise SaaS integrations and the number of platforms that aren’t enterprise grade slows us down. Almost like there’s a market opportunity there… (ahem).
The details depend on your project requirements.
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)
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)
Stay with Node and React, add TypeScript. New tools like SWC and bundler like Parcel or Next.js make it truly good experience. Check out Turborepo too.
SaaS + robotics for preparing the world best cookies by scanning your face and preparing it based on your current facial expression.
[deleted]
- Vue w/ Quasar Framework for the frontend, mobile, etc
- Flask or Falcon for the python backend
- Postgres + Redis for DB stuff
- Stripe for payments
- Flask or Falcon for the python backend
- Postgres + Redis for DB stuff
- Stripe for payments
My maximum productivity stack:
BE: nodejs/TypeScript/prisma
FE: react/TypeScript/blueprintjs/wouter
BE: nodejs/TypeScript/prisma
FE: react/TypeScript/blueprintjs/wouter
Have others considered using firebase, supabase of aws amplify?
Use your boring stack.
Provide a VPC endpoint
For payments you can look at solutions like Stripe and for auth solutions like acmelogin and keycloak. For hosting there are even credits available for startups from IBM, Azure, AWS and Google Cloud. AWS and Google are most popular with startups. Azure most popular with old companies.
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.