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)
In regards to front end:
- 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
In regards to back end:
- 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
In regards to data storage:
- 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
In regards to web servers:
- 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
In regards to making your services talk to one another:
- 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)
In regards to runtime environments:
- 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
In regards to where to actually run your stuff:
- 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
In regards to OS distributions:
- 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
In regards to architectures:
- 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
Other considerations:
- 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 grow
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:
In regards to front end: In regards to back end: In regards to data storage: In regards to web servers: In regards to making your services talk to one another: In regards to runtime environments: In regards to where to actually run your stuff: In regards to OS distributions: In regards to architectures: Other considerations: