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.
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...
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.
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.
There may be a handful (if any) of companies that failed due to tech stack selection. I highly doubt that though.
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.
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.
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.
[1]: https://jumpstartrails.com/ [2]: https://bullettrain.co/
It's about finding a problem to properly solve, not about the tech stack.
- 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!
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.
- 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!
Interesting to see the deployment choices used by these kinds of frameworks as well.
Guessing you'll also get a lot of recommendations for Firebase, which suits a lot of use cases.
In reality it's whatever you're most productive with.
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.
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.
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
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.
> 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.
- 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.
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.
Could anyone post the link? Thanks in advance.
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.
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 growI 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).
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)
- Flask or Falcon for the python backend
- Postgres + Redis for DB stuff
- Stripe for payments
BE: nodejs/TypeScript/prisma
FE: react/TypeScript/blueprintjs/wouter