1. Old schoolish (VPS - Maybe DO, Django/Flask/Rails/Remix/Next with postgres)
2. Supabase etc with JS/TS on either side of the network
3. Lambda/Cloud functions with Firebase/Dyanamo DB/Cosmos DB etc
4..n. What else and why?
Early on I would still have to lean on Alpine heavily for various JS interactions but with all the features Liveview has been adding and improving on (Hello JS module!) I find myself needing it less and less. Liveview really has been a game changer for me. Tailwind has more or less fixed most of my frustrations with CSS and has worked itself nicely into the company design system resulting in nice re-usable components that can be easily customized for those one-offs. Elixir is a nice language to use and I find myself missing features of it when working with other languages. Phoenix is well structured for projects and the newer generators solve a lot of common issues/features in projects like user auth in a reasonable way.
Depending on the needs of the app I'd look into deploying to Fly.io otherwise I've been using Kubernetes with little issue. I've toyed with Nomad for orchestration but haven't used it enough to give an opinion. I do wander if it's a nice middle ground for those who don't need the full suite of what K8s offers.
Reasons:
- I've been using Rails as an API only, so having to grok views felt like a waste. My React skills made me feel that learning how to make complex views in my backend was a waste of time.
- One type of bug I hate is ensuring my API calls have the right schema. With Supabase and TS in the frontend, this is a non-issue: export types from db schema and all frontend requests are typed.
- Supabase is something for sure: I had been eyeing it for a while now, and it did not disappoint. Getting endpoints - even with realtime updates/subs in the frontend - after just defining a schema is magical.
- Auth is super simple with RLS - all this uses my SQL knowledge and makes me double down on it, which seems like a sane choice given it's been around for decades.
- Mantine gives me a large list of prebuilt components. This isn't exclusive to this stack but would highly recommend using something like this instead of just Bootstrap or Tailwind on its own.
Overall I'm happy with the results, feels way faster than my React/Rails workflow. Way less time in the backend (models, migrations, presenters, etc), more focus on tweaking the product.
Con: does not move me in the direction of using Python more. Feel like this is going to be a must-have for AI-powered components.
I personally don’t think that if you’re building an MVP you should be worrying that much about how to store users in the database and add RBAC and building a way to add middleware and a storage layer and all of that crap. It’s not worth it, your application is not a special snowflake.
Edit: Should say that with that I mean serving HTML via Django. Usually I would use Bootstrap for layout. Very occasionally I’d add an API for some interactivity but I think for most MVPs interactivity is likely to be a secondary concern until later.
Semi-related side note: I do use TS/react in my 9-5, but the more I use it professionally, the more I'm convinced there is no need for it outside of trying to get a job, IMO.
Regarding backend choices:
curl "https://news.ycombinator.com/item?id=34530052" | grep -i Django | wc -l
36
curl "https://news.ycombinator.com/item?id=34530052" | grep -i supabase | wc -l
17
curl "https://news.ycombinator.com/item?id=34530052" | grep -i rails | wc -l
28
curl "https://news.ycombinator.com/item?id=34530052" | grep -i node | wc -l
15
curl "https://news.ycombinator.com/item?id=34530052" | grep -i elixir| wc -l
14
curl "https://news.ycombinator.com/item?id=34530052" | grep -i phoenix | wc -l
7
curl "https://news.ycombinator.com/item?id=34530052" | grep -i fastapi | wc -l
7
curl "https://news.ycombinator.com/item?id=34530052" | grep -i svelte | wc -l
9
curl "https://news.ycombinator.com/item?id=34530052" | grep -i React | wc -l
34
curl "https://news.ycombinator.com/item?id=34530052" | grep -i htmx | wc -l
15Anything web related I'm probably going the Elixir/Phoenix route. I'm no web dev, but this combination makes me actually kind of like doing web-things with how batteries included it is, and the tools it provides to really jump start a project. Then I'd host it "old schoolish" in a VPS or similar since that's what I know best. Might consider being fancy and investigating if Fly is a good fit. If a DB is required I'd use SQLite unless some constraint pushes me into Postgres.
If we're talking command line tool, the correct answer for me would be C# since that's what I know best. The answer I'd want to give though is Go since I want to get deeper into it, but that's not a good business decision.
Desktop application, best I've got in my kit is WinForms with C# and prayers that it never need run on anything but Windows. Maybe Linux with some Wine trickery, but that's not something I've done before either.
Rust for the core application, Elixir for the backend, frontend, API, data layer. Javascript is pretty much non-existent, all client-side interactivity is done by LiveView.
Packaged into a podman container and deployed to a Hetzner dedicated server. Storage on PostgreSQL, probably the only thing I would rather not have to manage, but honestly single node is perfectly fine for an MVP. Provisioning is done with Terraform and Ansible.
Future expansion (pretty far away, post launch and post paying customers) is add more geo-distributed worker VPSes, talking to the central coordinator via Wireguard link.
Setup is pretty cheap, fast, scales really well, and it's easy to understand. With additional services (mail, monitoring, etc.) should be less than $100/mo all inclusive, and that should be enough for up to ~100 paying customers.
I have no plans of changing any part of this setup for the next decade. I'm too old to want to get golden handcuffed to turn key solutions and cloud products that just introduce complexity and become VERY expensive, and badly documented, past the demo stage.
Started in November, closed alpha release with users next month, launching Q2 2023.
1. Laravel
2. An Ubuntu VPS in either Digital Ocean or Linode
3. A managed database in one of those services, likely Postgres
That would get me to market the quickest. I have no issues with the application being in Laravel/PHP and after getting to market, I'd work on making the infrastructure scalable. I wouldn't expect overnight success, so a single VPS and managed database would let me keep costs low while I pick up a few customers and then work to handle the scalability in the background (likely AWS with a combination of EC2/ECS/Fargate, RDS, SQS, SES, CodeDeploy, ElastiCache, etc.)
The thing that bugs me the most with Next.JS and the whole JAMStack movement is that, yeah, you get from "git clone" to deployed on Vercel in two minutes, but if you need to create real app features like a sturdy admin, accounts, authorization, proper asset management, CI/CD, it takes a whole lotta time. I'm not even touching the most common app features. I'm speaking from experience, from building a Next.JS app for about a year.
Most Next apps out there are incomplete with the worst freaking user experience. Insert any other JS framework or hosting provider in the place of Next.JS and Vercel.
Of course, this is a generalisation, not all Next apps are that bad.
Using Rails is like a cheat-code in dev term.
I know JS very well, so writing HTTP handlers is quite fast.
Node runs on V8, which is probably the fastest runtime for dynamic code.
SQLite makes development easier as it’s just a file, gives you ACID.
- Frontend: React/Mobx/Tailwind SPA hosted on firebase hosting.
I think the concept of JSX (write your HTML with JS) is good as it gives you a real language instead of a restricted templating DSL.
Tailwind for the fast iteration speed.
Firebase hosting for the simple CLI and fast CDN.
- OS and hosting: Docker running on Google Container Linux
Docker so that the OS level dependencies of my server are defined somewhere.
Container Linux as it auto updates and has all the GCP logging and monitoring built in.
GCP for the incremental disk snapshots for simple backup of the SQLite state.
If I had to scale the service I would add more CPU cores and faster disk. I would also move the parts that need scaling to Go/Rust, and design the code to make use of the cores.
A few principles I use when choosing tech:
- Avoid distributed state (network boundaries) when possible (SQLite instead of SQL server, function calls instead of micro services).
- Use tools for their primary purpose. No shoehorning. Issues arise when you try to use something for what it was not designed exactly for. If you have >3 tools in your stack that you are shoehorning, things are more likely to break in the future.
- Things should still work in 10 years with minimal updates. Lindy effect. Bet on older tools if possible as they are more likely to be around and maintained.
- Good enough vs optimal: stop trying to find the perfect tech. Web tech is sometimes messy and imperfect. Opinion over what is right changes.
Many years ago a CIO told me he didn't really care what technologies I picked for an upcoming MVP backend, as long as I was already comfortable with them and would therefore be productive quickly.
He also told me we would almost certainly need to rewrite everything at least once, so not to dwell too long on the initial stuff.
Build the MVP, build it quickly, get it in front of users. It just needs to work, you're not going to get marks, or customers, for backend coding style.
A Laravel app hosted with Laravel Vapor (AWS Lambda) with a MariaDB database. Would allow me to get up and running quickly, at low cost and without having to worry about scaling for a long time.
Using Tailwind and VueJS or AlpineJS for the frontend.
Let's assume we're talking about a web-based business app.
If the MVP already requires some complex business logic, then I'd probably choose an old-school stack. I personally prefer Rails. But I'd probably pick .NET. Above all, my metro area is full of .NET people. It'd be much easier to find/hire collaborators in .NET. I'm comfortable and productive enough with .NET on the technical level.
However! If I could get away with just putting up a couple Lambda functions, then that's absolutely the path I'd choose. It's an MVP. Let's get this boat rowing ASAP!
In short, product and market influence the best technical approach.
Main reasons are:
- Can build entire app (with SPA-type experience on the FE) in a single codebase
- No need to build any HTTP APIs
- Periodic tasks and managing in-memory state is super easy in Elixir. Eventually you might want to stick state somewhere which survives restarts (eg redis) but for the sake of moving quickly Elixir makes this really easy
- Newer versions of Phoenix/LiveView support html components so building out UIs now feels as nice as some of the tools in the FE ecosystem
We have four kids, host an exchange student, a new puppy. Our schedules are full.
Nothing compares to the productivity of Ruby on Rails. Especially when coupled with a high-end template like Jumpstart Pro ( https://jumpstartrails.com/ ).
1. Purchase the domain name using AWS Route53 (perhaps you’d need to setup an IAM role for the website to access your pre existing AWS acct)
2. Setup frontend, API, and CDK infra repos. All in TypeScript.
3. Frontend react, backend Api gateway backed by lambda functions. Have a graphql endpoint that talks to an Amazon auroradb. CI for backend and frontend is defined by a CDK package that is also deployed to the AWS account that also sets up the networking and database for you.
4. Have a basic layer of application code for setting up user authentication and storing user data in the aurora db.
Basically my idea is it kinda sucks that everyone has to do all of this setup yourself if you want to start a new project. Or you have to rely on no-code tools like Squarespace etc which may not be what most engineers are looking for. Having something that can go from simply entering the domain name you want to scaffolding out a fully functional full stack web app with CI and serverless infra defined by code that can scale from day 1 seems both incredibly useful and doable.
Curious to hear other people’s thoughts on this!
Edit: post-mvp, I'd stick with Rails still unless there are specific difficulties with it. But I've yet to have major issues building a large Rails team/project, including present day.
Why:
- has almost everything that I need usually in mature gems - battle tested in production
- speed of development
Because I wouldn't need anything else.
Also, it could potentially be my final stack depending on the size of my business & market. The current Kestrel web server implementation is extraordinarily fast (i.e. millions of requests per second fast). Vertical scaling isn't exactly a problem now that we have 2S servers with 256 cores (and beyond).
I'll use a VPS or host it on the Raspberry Pi in my bedroom[1]. I use these primarily because I'm worried about price complexity at cloud providers.
I use a mix of languages for personal stuff and I'm finding Go quite addictive at the moment. I rarely use a framework and base most of my MVP's on the simple Neat CSS framework[2] I created for that purpose. I like to keep stuff light.
I've started to create some live coding style video's[3] of myself doing these projects with a goal of setting a schedule for myself and an ultimate goal of creating a micro business.
1. https://joeldare.com/private-analtyics-and-my-raspberry-pi-4...
Ruby just... wants you to be happy while you're using it. And in the long run of life, that matters.
Python wants to be correct, Java wants you to not make mistakes, JS is still figuring itself out, Scala wants to do hard things...
Ruby wants you to be happy.
IMO - There's a lot of very worthwhile follow-on effects of that - everything from libraries (generally) being just that much easier to get going with, to lower-stress teams having better communication, to debates instead of fights (I'm looking at you, PEP572). Ruby is nice so we are nice :)
Rails 7.1 w/ Tailwind (esbuild, not import maps) Postgres DaisyUI for Tailwind UI components View Components for Ruby Nothing particularly "hot" but there are some newer tools
Post MVP, the only thing I'm looking to change is potentially replace a very heavy data analytic background job with a Crystal version of it. Will be super easy to port, and since I'm using Sidekiq, I'll drop in Sidekiq.cr and thus won't need to make any other system changes.
I'm thrilled about it, it's taken a month to go from zero to everything working and I'm just tidying up the marketing site
All the new fangled frontend technologies make me dizzy :). On top of that this is my fist project in django.
There is a nice django starter oss project called djangox which takes care most of the integration out of the box.
For a new project the complexity should be on the marketing stack. Choosing a good tech stack is a distraction. Choose something that will allow you to create MVP fast and then start marketing.
1. you get a lot of out of the box rails like glue jsut like rails or django but the runtime perf is way faster. you can get away without even using caching in prod for awhile
2. supabase is written in elixir
3. lambda could functiosn have their place but loc you in to a cloud provider. I can move my elixir mvps accross providers with no issue and I won't get any surprise bills.
2. Supabase for Postgres and Authentication.
3. Astro as a framework for front-end, deployed on Vercel, running in Hybrid mode.
With all of these in-place, I can extend my existing components to accommodate any needs. It scales very well in the beginning as I move very fast, and anecdotally scales very well regardless of size.
The only missing parts here is support for timed jobs, but that can probably be done with Fly.io machines in the future.
Clojure's not the easiest thing to get into, the stability and documentation and libraries are great.
Because this is actually capable of handling a decent workload for really cheap compared to cloud.
There's a few tricky bits to do with logs and reporting, but the benefits outweigh the pain.
Vue on the frontend.
Last time I used BootstrapVue and it worked well. I'd want to re-evaluate that decision next time, have a look at some of the newcomers. I'm aware Bootstrap is now considered to be passe.
I really like the Vue philosophy and it pairs with Go nicely. Last time I ended up using ESBuild to actually build the Vue bundles from inside the Go server, which was interesting but I'm not sure I'd do that again.
C# REST APIs on Linux with PostgreSQL and the front-end framework of your choice. I generally stick with Angular.
Over those years I've come to greatly appreciate the wisdom of Gall's Law. I always start with an absurdly simple system, make damned sure it works, and only then complicate it.
- nothing beats the simplicity and power of svelte for UI
- netflix falcor for state and request management, because it has the 90% of features of graphQL i need but is much simpler to reason about and i can auto generate nearly all my requests from svelte without writing queries (because falcors model matches 1:1 to POJOs and has optional schemas so prototype at lighting speed and then add schemas later as needed for reliability)
- pouchdb/couchdb because nothing beats this combination for sync and offline and low latency features
Because:
- Battle proven
- Secure
- Well maintained
- Well documented
- Fully featured (a lot more than others such as Django or Rails. Jobs, auth, asset manager, etc out of the box)
- Doesn't hate JavaScript, embraces it (hello Rails!).
- The templating system, Blade, is pretty great...you can even do components.
- Opinionated and not that many different ways to do the same thing, makes things more consistent
- Performance is good enough for 99.9% of use cases. For the other 0.01% add Octane.
- Great, friendly and professional community. Top high quality packages with lots of users and well maintained.
- Excellent frontend integration packages in case blade is not your thing: Inertia, Livewire, Hotwire, etc.
- Lots of people know it and like it, so easy to hire for too.
- Code organization makes a lot of sense to me (hello Django!)
Until you actually have reason to scale (eg you are building WhatsApp), building to optimize the productivity of your iteration cycle usually gives the best payoff for pre-PMF projects.
Having said that, the answer is Python+SQLite.
I was tempted about upgrading by default stack, but after lot of wise advise here, I think it's better to stay in a stack where velocity will be high rather than wasting time in learning new things (unless that is the goal)
For personal projects, reactjs or vuejs or solidjs, tailwindcss, nodejs. Depends though, sometimes there are projects that demand the strengths of golang or rust.
I’m wrapping up a Python project right now and my next personal project or two are going to be .Net apps of certain ambition (users, scheduled tasks, a few tables, maybe a sprinkle of real-time) so that I have some good foundations come gametime.
For the front-end I’d pick some React flavor.
Data in PostgreSQL.
Cloud provider probably AWS because it’s the devil I know but I don’t care too much.
I'm less solid on the deployment. Could go with one of the commercial docker-y hosting systems, or a commercial K8s setup, or a hand-rolled Docker host via Ansible. I've done all 3, and I'm not sold on any of them being the best for everything.
Front-end side is more flexible depending on the type of site/business. Normal ERB-style SSR is probably fine for a lot of things with a few sprinkles of basic JS. Would re-explore if I thought it needed a proper front-end app. React is neat, but darned if every single time I try to do a version bump on a small React app, I end up needing to rewrite half of it.
On top it's probably Tailwind, and if it's just me I'd use Svelte, but if it's more than just me I'd use React.
[0]: https://hasura.io
Edit: Thanks for the advice!
Why? Mainly because I'm familiar with them, and would be most productive with these.
I'd almost like to reach for Blazor, but if it's at all public-facing, I don't think I can justify using Blazor at this time.
If front needed then pure js or vue
Database probably sqlite or postgres if that fits the needs
Stack:
- React Native + Expo - Typescript - Supabase - Vercel - Some Vercel/nextJS-ish lamda functions so I could avoid AWS (Supabase didn't have that kind of offering yet)
For me, it was _very_ pleasant to work in. I was able to ship features via OTA updates from idea to live in literally minutes.. sometimes even under a minute.
Loved working with Supabase.
However, there are lots of use cases that would call for additional SPA (Vue/Nuxt), or other tech. So in that case I'd add it or replace the tech stack entirely. I'd probably avoid specialized cloud services, might consider something like https://supabase.com tho if the app doesn't need a complex backend.
For the backend, probably default to JS or maybe TS lambdas/function apps. Quick to write, quick to deploy, slap an API gateway over the top and you're ready to go.
For the front end, for a true POC I have a lifetime/full Creative Tim membership. So I'd just grab a dashboard and landing page template and start plugging in calls to the API gateway.
We see no reason to use extensive front-end as it has only downsides now - it loads longer, it exponentially balloons stack, it requires to hire front-end guys, it is not needed anymore for DOM manipulation.
Firebase is too expensive. Only use case if you have only front end devs.
Dynomo/Mongo/Cosmos all do the same niche thing - you don't need a no-SQL db for most apps.
4. Apparently a lot of YCombinator companies still use Rails. I don't really understand why.
edit: I didn't know about Supabase - thanks.
It's boring but it works. It also scales as far as your wallet can handle.
With this setup you can permanently host for next to nothing until you get users, do zero devops or ops, and have something that will scale up (wont be the fastest thing but it will be OK and will scale)
You could switch out NextJS for a static site generator too, but NextJS is pretty convenient and is a superset of a static site generator with everything wired up nicely using React.
https://github.com/learn-anything/learn-anything
Reasoning behind the stack is that I feel productive in Solid and it's plenty fast on first load and as SPA when fully loaded. I love the component model and JSX.
ChiselStrike is new to me but I was looking for something that lets me declaratively manage my schema. I checked https://entgo.io (it produced too many Go files to my liking), also Prisma (https://www.prisma.io), found it bit complex to get started with.
I also checked https://www.edgedb.com and it's nice but with ChiselStrike I can deploy it with LibSQL (fork of SQLite) and replicate it so responses should be plenty fast and I can build on top more easily.
For native apps will use SwiftUI composable architecture when it comes to it. React Native code sharing seems nice but Solid doesn't have a React Native alternative yet sadly.
But since you asked about backends specifically, this is what I would use. I would use clerk.dev for authentication, Hasura for the CRUD API, neon.tech for the database, S3 for static files (images), and AWS Lambda for any extra functionality you can’t accomplish with Hasura natively (but call them through Hasura).
Personally, I like using GraphQL because I can just focus on my data model and not think about what endpoints I need to make. But there’s definitely a learning curve, so sticking with a REST API is probably better for most people.
As an alternative, I would also consider Supabase like you mentioned. It sounds cool, but I’m already comfortable with Hasura so that’s what I go to first.
Update: For a website, I would actually use Remix with Clerk for auth and Prisma/SQLite for data stuff. That’s one of their premade starter stacks. I made one prototype with Remix and had a lot of fun using it. It’s easy to learn and will give you a high performance full stack app. My original answer is what I would use if you’re making a mobile app.
Elixir for the backend. Reasons for it:
- Elixir is designed for reliability, so since I want to keep the app alive as much as I can by myself, it seems like a great fit.
- It also has excellent integrations with Postgres (my choice of DB) with Ecto.
- I generally skipped Phoenix, as I'm just using Elixir to create my API.
- Absinthe provides amazing support to create GraphQL API from scratch.
Frontend will be React probably with Relay.
- I've been using React at my job for years with GraphQL and I'm pretty fond of it.
- I've been planning on investingating Mobx, as I've never used it but heard good things about performance there. I'm not sure if it's going to be worth using it with GraphQL
- Relay has quite a lot of boilerplate, but I found it good enough for what I'm doing, and I liked the performance. Also it's fairly easy to integrate with Absinthe.
- Generally since this project is not made to be a start up or a business first, I want to experiment on the front-end on how I could reach the best performance with these tools at hand.
- I plan on using TS with the GraphQL queries mostly generated from the schema.
For deployment I plan on using a VPS probably, though I'm way far from having to choose that.
Here's why I'd pick it:
1. One language for the whole stack. It's an MVP so the front and back are both changing fast, with changes made by the same person, and you don't want to context switch all the time.
1a. Javascript as that language because it's the most flexible. And with TypeScript you can gradually opt into type constraints where they help you.
2. An opinionated full stack like Ruby on Rails that integrates all the pieces I need to ship. When you assemble yourself, even small version bumps or outdated tutorials can send you down a rabbit hole, stealing time from testing PMF. You want someone to validate a combination in which all the pieces work together smoothly.
2a. Redwood.js closest to be being the Ruby on Rails of JavaScript. I've toyed with it before and got up and running quickly. Its opinions took a lot of unimportant decisions out of my hands and let me focus on what I was trying to produce. I didn't get so far as to confirm this but it also seems to make it easy to gradually drop the scaffolding if the opinions and simplifications ever get in your way.
Backend - Haskell, Postgres
Infra - My most recent experience is with AWS and ECS but I'd likely try out Nomad and HAProxy.
Pretty much any other moving parts would depend on the MVP itself.
I'd stand it up on a VPS initially, using ansible scripts to make switching deployment targets to AWS easy.
Building an MVP should be done with the tools you’re most comfortable with!
Back End: AWS Lambda behind API Gateway
Database: AWS DynamoDB
This stack will reduce down to zero usage costs when there is no traffic and will scale up to much more than I will possibly need for anything resembling an MVP with no interference required by me.
If you haven't played around with Rails for a bit, things have gotten simpler in the past few years. Doing a quick demo/todo app on Rails 7 is delightful. With hotwire/stimulus, you get frontend performance that feels like React, but you're writing simple HTML/ERB templates and partials and some light JS controllers. It's quite nice.
Scaling those apps to lots of complexity is still an interesting challenge, and we're leaning towards React frontends on top of Rails APIs when the frontend is complex, but if you're building a standard CRUD app, Hotwire/Stimulus just lets you motor through the build and spend your time/money on user-facing value.
But also if I was slightly less old I think I would be heavily into Python at this point especially as far as the ability to easily leverage data and AI tools and libraries.
But again, my suggestion is go with what you are familiar with. And if you are less old and are excited about a new language or framework, that seems perfectly valid to me. The hard part about programming is staying motivated. So if new stuff helps with that then great. I
One more take is that you should start by defining the problem in detail before you make up your mind on the architecture and technologies that you will employ. If there is a particular technology that is well suited or has a ready-made solution, you should consider that.
Agreeing with what has already been said about static HTML/CSS/JS on GitHub Pages with AWS buckets, but if Django or Rails works best for you, go with it.
Unless this stack is works-best-for-you, beware launching on React, Typescript, Next.js, or Vercel. That's what you're going to use for the Real Version, when you have money to hire some Real Engineers who are okay with the level of complexity. Don't incur that tech debt before you absolutely must.
Hire a PHP/LAMP dev for $10/hour or less (or whatever is cheap and good enough) + something like digital ocean. Communicate effectively the features and milestones and project manage but mainly Spend my time on growth
I’m at a point where I can’t fathom writing a ton of code myself when I am trying to start a business. Programming is a hobby that I enjoy, but my time as an entrepreneur is more valuable elsewhere. Most likely I’ll find the business’s largest hurdle earlier and, it’s probably not a technical one. Then I can decide if it’s something I want to pursue or pivot to something else.
Ecto is the best ORM-ok-fine-it's-not-an-ORM I've ever used and Phoenix is a lovely framework that borrowed a ton from the success of Rails. Deployment used to be a bit of an achilles heal (in that it was uncharacteristically difficult compared to everything else about using it), but that's gotten _so_ much better in recent years. Even more simple if you just use something like Fly.io, which has incredible first-class support for Elixir/Phoenix.
It helps to use the best language that your entire team knows. It severely limits your startup if the team is learning a new language together. Align tech decisions with the capabilities of the team, unless the common denominator is Perl. If the team each has at least 5 years of development/engineer experience and you're going to need to invest in a common language, give Elixir and Phoenix Liveview a try.
When we were building the MVP for Transistor.fm, we chose Rails because it's what my co-founder knew the best.
These old-school web frameworks are mature, and still have a big ecosystem (community, resources, etc). Beyond Rails, we used AWS with Postgres, Redis, nginx/puma, and sidekiq for background jobs.
With any business (especially early stage), you only make progress when stuff gets built, deployed, and into the hands of customers. Remove anything that slows you down (like learning a new stack).
When we were in the MVP stage we recorded this podcast and went into more depth: https://saas.transistor.fm/episodes/nerd-stuff-our-web-app-t...
I suck at UI/UX design and don't want to write a bunch of JS for async webapp stuff, so retool is a force multiplier there and would highly recommend. I Don't want to manage any infra, so appengine handles that for me. After getting everything setup with terraform in a day or so, I spend all of my time developing core functionality and 0 time managing servers or getting a UI to do what I want it to do.
Total cost to host is < $100
My main reason is speed; you can move very fast, and lots of the "boilerplate" stuff is handled out of the box.
I do keep post MVP in mind, it should be pretty easy to move parts to different systems if necessary. The most radical exit would be moving the Postgres DB elsewhere, or even self hosting Supabase.
It's good that it's possible, but I plan to use this stack as long as possible as it's great, and I have zero interest in managing and maintaining infrastructure.
As with everything; it depends. On your product and on your skills/expertise.
* Flutter, with FlutterFlow for UI * Pocketbase for quick, extendable back end code and basic BaaS * Heavier emphasis on market validation and strategy than technology
We set a goal that the MVP is barely a mock-up. The other understanding we have is that the backend would have to be 100% rebuilt if / when there is traction, but we were able to get to work in one web meeting.
Developing in python for me is just much faster to get to a working prototype. Flask is super simple to use, and I find it great to implement HTTP REST APIs for the back-end of my MVP.
With Firebase you can deploy containers in the cloud and you don't pay until you reach a certain threshold of monthly requests.
In terms of my development environment I'd definitely use docker to containerize my environment and make it easier to collaborate with others. If I was making a bigger scale MVP with multiple collaborators and sensitive source code, I'd opt for a cloud based CDE (containerized development environment) with monitoring and security features, such as the one proposed by strong network.
With clean conventions to start with.
From the get go, performance would be great, and it would be fairly easy to scale with azure container apps.
Than another week or so to polish things up. Most time from than would be U.I based.....
Just point of reference, a couple of weeks ago created .NET 7 Auth service creating JWT auth from AD B2C, along with custom X509 Cert in 2 days complete with docker image build using Azure KeyVault, another day to get build/deploy pipelines setup, plugging in Azure APIM.
It's really incredibly simple and fast to do now.
That said, anybody who gives an answer without knowing what they're building first and knowing the tradeoffs involved IMO isn't doing things right.
- React Vite Typescript (React Query and Hooks*)
- Python Flask Backend
- SQLite or just fsyncing a JSON file to disk on each write (it's an MVP!)
Don't need anything more fancy than this.
* Tried Redux / Redux Toolkit enough to realize for a MVP it's sufficient to just hack stat with hooks and contexts, reducers are too much b
Given my background that means .NET Maui Blazor (aka Maui Hybrid). You need two skills: C# and HTML (Razor). One language on the front end and back end. Compiles to native code on iOS, Android, Mac, and PC; WebAssembly in the browser. On the native apps the HTML UI is interpreted, but the rest of the code is in-process and native.
Since I want to use .NET, that means the best cloud support is Azure. Azure Functions for the API - serverless for frugal startup costs. For data store, Cosmos DB in NoSQL mode as a JSON documentDB - again, serverless for frugal startup costs.
I'm also very intrigued with using Go and Flutter instead of MAUI, but given my background that means a learning curve instead of being productive with a language I know well. I think C# and HTML are easier (more abundant) skills to hire, but I suspect Go and Flutter would attract more open-source-aware developers.
I'm not sure about a front-end HTML framework to go with Blazor. It ships with Bootstrap, which is probably file. I'm curious about Bulma which looks simpler and Material 3.0 for Web which is in alpha and marching toward 1.0 release soon.
I would use Laravel with Livewire.
(disclaimer: I'm the guy in the Video :):):):):)
It automatically provides API docs, architecture diagrams, and infrastructure provisioning, based on static analysis of your code base.
Disclaimer: I'm one of the founders.
Using Rust, Diesel(Orm), Postgres, compiled jinja2 templates (Askama), and a smattering of JavaScript with AlpineJS, and Tailwind. I have 100 loc JavaScript that makes it easy to replace only parts of the page via Ajax calls.
Really simple stack, really lightweight, a joy to debug, and runs instantly. The delay on my dev laptop is below 10ms, it’s undetectable.
So much better than React and Python that I use at work in nearly any dimension. I hope the mvp works out and I can quit that job one day.
- Supabase on the backend (REST APIs are a solved problem, no need to spend a single hour on it)
- Auth0 for authentication (too risky to manage authentication manually)
- react + react-admin SPA on the frontend (does 80% of the job for B2B apps)
- lambda functions (for business logic that can't be exposed on the frontend)
API-centric SPAs are such a time saver... when you don't have to build the API, and Supabase covers it.
For a B2C app, you must render server-side. I'd go with:
- Postgres - Next.js or Remix - Prisma
After my extensive framework shopping of PHP/Laravel, Phoenix, Supabase, Directus, Kotlin+SpringBoot, I settled for Django+HTMX+AlpineJS for my side project. I could create a working MVP in a week and within 1 month I had most features up and running.
I plan to host it on Oracle cloud (free tier) and have not seen any issues with it so far in the test runs.
Phoenix support for websockets is really good right out of the box and for small/medium complexity UI's Liveview is light years faster in dev time than a spa. Liveview can take you far, but heavy UI work I still default to Vue.
Elixir can take some time to wrap your head around since it's a major shift from more mainstream programming languages, but I think there's a ton of fun in that.
I'm going to deploy it on aws fargate sometime in the next 6 months or so, that should get me to scale.
The database I'm going to migrate to a single tiny ec2 instance until I need more resources, then it'll probably go to RDS or PlanetScale.
Building an MVP to me means you are building a Proof of Concept (POC) for investors to see the value in your product. Using something that has a proven and lengthy track record and plethora of industry resources in the market feels like the right approach.
Depends on resources too... If you have separate resources for FE and BE. Probably still go Rails for BE. The upsides to Rails is productivity and job market. I'd track metrics that would help you keep an eye on application performance where it matters and iterate on those areas post-MVP.
For the FE I'd go NextJS... You can use it as just React or actually use all of the pieces to it where necessary. You can host it on a server or toss it on Vercel or Netlify to have less worries until you outgrow those (if ever).
For the database I'd probably use something that works well with Prisma JS for productivity, PostgreSQL or MySQL.
I'd stick to TypeScript for that productivity too. The iteration speed is a brain dead reason to use it.
If you can make the BE and FE with the same team and use all TypeScript... I'd use NextJS + Prisma JS + tRPC. tRPC would give a huge productivity boost because of its TS integration into your project. You just need someone senior enough to establish guard rails like the boilerplate, linter, and other guard rails to keep more junior developers on track and productive.
I feel that the combination of these frameworks will give you the right mix of quality and iteration speed without sacrificing one or the other. Also, great hire-ability. Though, all of this depends on if you actually need a DB and a backend, or even a frontend for what could suffice as an MVP.
Just some thoughts...
https://github.com/Hyprtxt/fresh-strapi.deno.dev
This site uses the framework, but not Strapi: https://videopoker.academy
My own servers for the entire cloud, maybe with CloudFlare as a CDN.
Avoid anything else as much as possible. If you need AI/ML, you're going to have to pull in some difficult extra stuff, so make sure the value is there.
Owing both to the unreasonableness of the modern javascript stack (node/eslint/jest/react/typescript/webpack) and also to the considerable improvement of vanilla js over the past 10 years, I really don't feel like all the extra frameworks are worth the overhead and dependency risk on the frontend. Vanilla js is really good these days! And when you need a boost, rust wasm is also really good.
I've found that it's a lot faster - and also a lot safer! - to build in vanilla js than I ever would have expected. Typescript still adds value, but imo not nearly enough value to earn a place in the stack.
1. Python.
2. Flask. Pure server-rendered HTML, no fancy frontend. Avoid JS as long as I can, just use jinja templates. If my app is not going to work with good old HTML and CSS chances are it's not going to work at all.
3. Classless CSS framework. I like this: https://watercss.kognise.dev/.
4. Sqlite3 or Postgres. Prefer postgres because with docker it's 5 minutes to set up. I use SQLAlchemy from the start because it makes life easier. If you ever deploy and worry about real data you add alembic for migrations.
5. One docker compose for everything.
6. Cheap VPS for like $3 per month.
That's it. I would like to upgrade my MVP stack, but it's battle-tested and it works well. After the 9 to 5 I only have like 3 brain cells alive so I need to get stuff done as fast as possible, which means using what I know.
One thing I often reinvent and reimplement is OAuth. Definitely "Sign in with google" is the best way to add auth to your app, but it's such a pain to set up.
refine is React based for building CRUD app rapidly. Repo: https://github.com/refinedev/refine With refine You can build admin panel, dashboard, internal tolls, and any CRUD app rapidly
It eliminates the repetitive tasks demanded by CRUD operations and provides solutions for critical parts like authentication, access control, routing, networking, state management, and i18n.
It also has connectors for 15+ backend services including REST API, GraphQL, NestJs CRUD, Airtable, Strapi, Strapi v4, Strapi GraphQL, Supabase, Hasura, Nhost, Appwrite, Firebase.. So you can save a lot of time from development time.
I've done backend separated from frontend and while its nice it can be a pain to manage on your own, which is usually what your doing at MVP time.
Now I'm more focused on using stuff like Strapi or rolling my own Hapijs server when needed and having a JAMstack frontend to interact with it.
Next.js has been a breath of fresh air to bridge the conceptual gap between what I was doing in Laravel (PHP) and now im doing in Next.
JAMStack and serverless functions are awesome because you don't need to maintain servers anymore. Most sites can be primarily static especially when you are prototyping... the data that comes from an API can be mocked for demos.
SQLite for DB development without the internet. Being able to run tests or do other stuff thats DB destructive without connecting to anything. No local server, no nothing. Just you and your flat file. Bliss.
Comes with a built-in low-config UI/API for CRUD on the database, and easily extendable with Vue.js and Express endpoints.
Additionally, should the need arise for something more custom later on, all your data is in Postgres rather than a backend as a service
*Explanation:* >> I need to really push myself to finish my last YouTube MERN-stack tutorial. >> I will then be able to competently contribute to the planning and implementation of a real (full-stack-web, and mobile-native) app. —->>> Purpose of app: Higher-education advisory services for N.-American colleges, as well as international students and their sponsors.
And Bootstrap, if I'm feeling generous.
When you're trying to validate a product, the last thing you should be spending your time on is fiddling with anything more complicated than this.
1. Is this stack popular among recent similar successful products?
2. What technology will make it easier to find relevant talent?
3. Does your stack allow for rapidly changing code along with a rapidly changing team? This is important, especially in the early stages of development.
4. Are you trying to do things the Google way? Facebook might never exist had they started with C++ instead of PHP.
5. Do you want to be on the cutting edge for the sake of being on the cutting edge?
I elaborated on this a bit in my blog here if interested - https://sleeksky.com/blog/technology-stack
So you end up with a bunch of tech debt or just inefficient stack that poisons your codebase from day 1. I think the initial gain is just not worth it in the grand scheme of things.
So we always are trying to use the best possible production stack. Not overengineer - just use the best solution for the long run. Long term gains beat marginal short term benefits.
Currently our stack for a pretty small eng team is Go, React, GQL and Flutter for mobile. Works pretty well for us.
But as I said, I could be an outlier here :)
Host: VPS on OVH
Database: Postgresql
Web layer (server-side): Grails
Web layer (client-side): Javascript - probably vanilla, maybe React. Bootstrap.
Auth / SSO: Apereo CAS
Deployment automation: Ansible
CI/CD - Jenkins
Issue tracking: Bugzilla
IDE: Eclipse
DNS: Route 53
If I felt the need for dedicated micro-services for the backend, I'd use Java and Spring Boot.
If needed, possibly Apache HTTPD as a reverse proxy.
For a lot of stuff that might fall under "other", like sending email, or text messaging, yadda yadda, I'd use Amazon services: SES, SNS, etc.
For an MVP I'm not sure if I'd even bother building Docker images or not. But if/when I had to scale up, then I'd definitely package as images and deploy using Docker or K8S. At some point if the thing got traction and needed to scale Big Time™ then I'd probably go to Amazon EKS or Azure AKS.
If I needed a mobile app... well, I'm not really a mobile developer, but I've been picking at learning Flutter. So probably would continue with that.
If you are not scared of diving a bit into Rust, I'd a 100% recommend it.
[0] https://github.com/shuttle-hq/shuttle [1] https://docs.shuttle.rs/resources/shuttle-shared-db [2] https://docs.shuttle.rs/resources/shuttle-static-folder
Both languages are simple to read, easy to maintain, and very fast/efficient.
https://docs.simpleiot.org/docs/ref/vision.html#technology-c... http://bec-systems.com/site/2048/go-for-iiot-systems http://bec-systems.com/site/1625/why-are-go-applications-so-...
And for the flavor, I'd just go with DaisyUI[2] again, since it's based on tailwindcss and it's what I've been using lately.
In my experience, I can build MVPs real fast with the stack described above.
If I have more time, I use go - chi and redis as a primary database.
Node.js, express.js, Typescript for the "central command" server that acts as any client's first port-of-call.
Central command fans out to whatever tech is required for the job. Very typical for me is fanning out to various python Flask servers to do ML/image proc/etc. work or connect to GBQ.
PostgreSQL for persistence because it's pretty much the undisputed pereto-optimal solution: solves 80% of problems with 20% of the effort. Does almost everything you need until you get to the big scales, which by then you can afford to just pay the wizards to do the Cassandra, Dynamo, Redis, haskell, etc. magic
This has done my team very well for years.
For me that's Laravel mixed with raw PHP (a fantastic and high performance language that has proven itself for a long time with some of the most popular sites on the internet), running on a cloud platform that requires literally the lowest amount of devops possible, so maybe Heroku but more likely Google Cloud's AppEngine or CloudRun. Frontend I personally would use raw JS with JQuery for convenience and compatibility. Probably Twitter Bootstrap for styling etc.
Result of all that is a quick well functioning and reliable site or service.
1.Flask with Postgres for API. 2. C++ with Pybind11 for core performance engine. 3.Whole stack running on a single cloud instance with docker compose. 4.Next.js, Typescript, Tailwind for frontend. 5.Github Actions for CI/CD and deployment to cloud.
On the back-end, NestJS with Typescript plus some query builder such as Knex (TypeORM is pretty buggy). Or maybe even try Prisma.
For front-end it depends. I would try using just Vanilla JS with Tailwind if possible or fallback to React + Tailwind if there are too many screens, or they need a lot of updates based on state.
Those are mostly technologies I'm comfortable with because I use them every day. However, if I have the option to waste time researching and/or learning, I would research the state of server-side Kotlin and learn Elixir/Phoenix before making a decision. NestJS can ge too verbose sometimes.
But in general:
* Old School VPS or Cloudflare Workers (if the problem lends itself well to Workers)
* Usually leaning towards sqlite instead of a hosted postgres (as that's often overkill)
* Language: whatever fits the problem best. These days likely TypeScript as it's so versatile.
Old school, but it works.
I keep that side of the stack simple because the front-end is ESP32/MicroPython/3D-printed-parts/aluminum-extrusions/lots-of-motors.
I'd probably run it on a managed K8s platform though instead of a VPS. At the very least use a managed (postgres) database instead of running my own.
I went with:
Terraformed AWS/EKS
Docker
Postgres
Node/Express
React
I'm pretty language agnostic, but for webstack I like to use Node, because it means I don't have to context switch too hard. I'm using the same language on the frontend and backend with the same APIs. I only have to keep one standard library in my head and a lot of packages are compatible with either front or backend.
Whenever I'm working on the web, that's going to be my go to.
I would consider Typescript, but I don't think the cost/benefit of Typescript really balances out until you have a team. The need to create types and type harnesses for libraries slows you down at first, and speed is the name of the game with an MVP.
I'd say either CGI scripts, PHP, or Ruby and sqlite as a DB, all hosted on a single VPS. That'll get you plenty far and be easy to grow out of.
I'm constantly tempted by Phoenix but desuaded by the lack of a type system. Does elixir somehow make up for the lack of types as a functional language? Also, I can reuse a good deal from my current stack in a react-native app for mobile, which I'd miss out on in another framework.
Wish I could say Flutter, but have not been impressed by the web experience.
I've mainly used sinatra and rails for Web apps and always found it difficult to define a clear api on which the frontend was based on (I.e in order later to build ios or android apps off).
Using Node-Red forced me to build an api for the frontend, the frontend has no direct contact with postgres.
Plus I found it to be more flexible than directly coding when I wasn't even sure what the database schema would look like.
Database modelling was done with pgModeler, I.e. No migrations and more pgsql functions and triggers.
Elm because then you can mostly ignore JS et. al. You can hire a normal person (anyone who can solve Sudoku puzzles) and train them up to make working web UI in a week or two. Elm makes that possible. It's like what if you could start a professional bakery with just an Easy-Bake Oven.
Elixir because it's more approachable than Erlang. Erlang (the BEAM & OTP) because it's much closer to the domain (if you're making a complex interactive multi-user kind of a thing, eh? If not then it doesn't really matter what backend stack you use.)
2. Hosted Postgresql
3. Hosted Graphql API layer microservice (like hasura)
4. Hosted hhtps server
5. Some kind of cloud storage solution
5. Load-balancer ingress
6. Some kind of CDN
Spinnable in less than day with SSL on, works perfectly for any app to scale and covers most production problems
Some off the shelf PHP8/Nginx Docker container, Laravel for the API (always pull in php/larastan for enforcing best practices), Maria for the DB, Laravel's Blade/Vue for the front, probably slap it on AWS as that's what I'm most familiar with. I like structured data, I like that modern PHP has (90%) of the safety of Java while being less verbose.
Postgres and maybe Redis if I need a message queue or cache.
React for the front.
Nginx and certbot for the reverse proxy.
Everything hosted on a cheap OVH VPs.
Mostly because it's what I am familiar with. Plus it's cheap specially since I already have the VPs anyway.
Reducing touchpoint definitely helps at MVP stage. You've to trade performance with features (depending on the tool dev tools vs CRUD business)
.NET Core on Linux - Works really well, C# is a great language and quite performant too.
EKS/ECS on AWS with spot instances - works out pretty cheap
Cloud DBs like Aurora or DynamoDB
React for frontend, because of how many libraries are easy to get for it.
- NodeJS, Typescript, Docker
- Fastify for the API
- Sequelize for ORM (Prisma seems like a good choice too but comes with too many features imo)
- Postgres (locally rn)
- AtlasDB for migration (I like the declaration style)
- Hosting didn't choose yet but would go with vercel or free tier GCP
Im proefficient with JS so that explains the why, however in 10 years the ecosystem still didn't catch with Rails in term of having one solution to all problems.
You still have to carefully choose your dependencies, all tutorials are quickly outdated and it's missing some crucial pieces that you have to glue manualy or code entirely.
For an application I'll use rails with postgresql (reliable and flexible can also store documents). Redis and sidekiq for background processing. Turbo, hotwire, stimulus and tailwindcss on the front-end. Vanilla rails is the best for me. Easier upgrades in the long run.
I have worked with it in the past, and having familiarity for the MVP trumps all, for me. As I can rely on it to provide me with a solid backend without having to worry about unexpected..
- Frontend: SvelteKit (Dockerized)
- Backend: F# / .NET running Giraffe (Dockerized)
- Data: Postgres (Managed - currently GCloudSQL)
- Hosting: Serverless Containers (currently GCloudRun)
I built a boilerplate for this to make it easier to improve / spin up: https://cloudseed.xyz
Phoenix is wonderful for web apps, LiveView makes UIs about 2x easier and faster.
For more interesting electronics MVPs I still use Elixir + Nerves for prototyping.
JAMstack for the frontend served via cdn
Terse STATELESS apis on the backend likely in Go on a managed k8s cluster
DB choice depends on requirements for the app IMO if its data that needs to consistently persist put it in a relational DB like maria or postgres. If the data is short lived let it hit mongo or otherwise.
To be completely honest though with current tooling you could do an e2ee local sqlite database and store it in an S3 bucket using a guid per user.
When I compared the existing frontend backend stacks like Svelt, Next, or a Go, Rust, whatever backend + React frontend, the amount that’s in Rails out of the box is just not even close to the rest. From ActiveRecord to secret management, a dynamic ecosystem of gems for almost anything and much more, choosing another stack just didn’t make sense.
Believe me when I say I really wanted to choose React for frontend because of its community and ecosystem but for an app with a backend that there is so much Rail does for you that you’d be spending weeks rebuilding with anything else.
A caveat is that this is Rails + Hotwire and Turbo + ViewComponents that makes it a no brainier. The old school Rails MVC would have been a harder sell
I have a moderately complex project, which is built using Next.js but it uses Yarn workspaces (for code sharing) and Docker (for deployment) but I waste a lot of time putting out fires w.r.t this setup than actually building features. I am thinking about doing away with Docker and Yarn 2 to keep the setup simple.
HTMX has been very promising, I have bumped into one or two bugs with it but there are always simple workarounds due to the sheer surface area of HTTP+HTML.
Postgres for great JSON support, keeping some stuff out of rigid schemas is critical for developing MVPs.
Frontend: If webapp needed, Typescript + React. If just html templating, probably Yew
Database: PostgreSQL. Move to Yugabyte or Scylla if scale becomes needed.
Streaming/event driven architecture: Fluvio
Cloud: AWS
Servers: ECS/Fargate to start. Move to Kubernetes as needed
IaaC: CDK
Repository: Github Monorepo
CI/CD: Unsure.
Style: Monolith API server. Separations will be made through Rust modules and interfaces. For anything that requires dedicated CPU/threads, those will be moved to separate services to be called by the monolith via gRPC.
Very simple, very easy to deploy and scale, and in-tune with all the best practices of fast frontend (auto caching, SSG, ISR, prefetching, client side nav, etc)
Didn’t like Django. Deployment more annoying, templates are weak and DSL-specific, React integration is poor and then DRF is a strange verbose monstrosity.
Now I'm rewriting my front end entirely in Svelte(Kit) and Tailwind, and keeping the Laravel backend for now. I will experiment with more lightweight PHP backends and Rust in this rewrite just to see how good (or bad) things can get.
I actually just built one. I tried a few other things first -- started off in BlazeJS / NextJS, didn't like it, tried some other react & backend combinations and there were always obstacles. The kicker was that I wanted geodjango for geospatial support.
I guess I’m old school, but I built SimplifyRecipe.com in a few hours using Laravel. That’s not to say that Laravel is better than anything else, but I’m extremely fluent with that ecosystem.
I will say, I believe that Laravel or Ruby on Rails would be my favorite starting point for a solo development effort. I spent 1000+ hours working on JavaScript framework development and found it to be really cumbersome.
Reasoning is pretty straight forward: I know it quite well and it's easy to grok and hire for them. Good tooling and ecosystem around it. Are there better languages out there? Sure, but Python has the advantage of being wired into so many different business and scientific domains its impossible to paint yourself into a corner.
Or, if you want to be more classical:
- kotlin backend using dropwizard, jdbi ORM connecting to postgresql. No kubernetes.
Or, if you want "plug and play" as backend:
- next.js, supported by postgREST. No kubernetes.
Or, if you want something exotic:
- elixir/erlang/phoenix as frontend and backend, no kubernetes.
I think the future is probably
- some frontend, edgedb, no kubernetes
My app started 7 years ago with Rails + AngularJS on the front end. Wish I had just used Rails for 90% of what I had used AngularJS for.
For frontend, a picocss-like minimal framework.
Django for the next stage. It's good for blogs, feedback management, back-office. Django beats rails. Rails is generating (scaffold) code while Django abstracting the CRUD operations. Clever abstraction beats generated code.
*bearSSL powered because I can't into curves myself :/ as the only external dep
if state is needed I lean on DuckDb but eventually a more optimized in-memory columnar data structure will be devised.
Mostly because I found all the other options in this space to be lacking for performance-oriented low latency services.
The one thing I can't recommend enough is the value of organizing persistence around a nosql distributed db and blobs of zipped files (also distributed)
In my experience, db is expensive. But this setup is dirt cheap.
Sqlite is good but it makes you worry about scaling (so it's great for an MVP)
1. Hosting, full on AWS. Because I'm super comfortable with it and I get end to end; from domain registry to data store and everything in between.
2. (mostly old school) Web app stack: React, Java/NodeJS, Postgres. S3 for doc store fronted with Cloudfront. Reason: Battle tested, huge and thriving ecosystem, most of the problems are solved.
3. Lambda for async tasks.
Recently really started to like Python so would probably try DJango.
But more importantly, it depends on what I'm doing.
Just to give you an example: if am I making a simple site with some dynamic content? Why would I use React for that or a giant framework for that?
We scaled up to hundreds of thousands of viewers + telemetry worldwide with no issues. Should be breaking into millions real soon now with our next few onboarding's.
We also have an express backend for the UI that's running on some puny EC2 instance.
- Userfront for auth
- Not sure yet about DB/persistence... Supabase? FaunaDB? MongoDB Atlas? Simperium?
I do really like the Firebase/Superbase options, but they impose restrictions and I don't like having restrictions like that unless I know for a fact that I'm building something very simple.
The reason is simple: I'm most comfortable and proficient with this stack and it's scalable enough to run a mid-sized app. Moreover it's very easy to share the code base between web app and mobile app based on expo (React native) if needed.
TypeScript on both sides with fp-ts[1], effect-ts[2], Postgres or any random document database with low friction, a random view library that has the best support for jsx and both client/server side rendering (not react).
Any other stack would require me to learn new stuff and eventually slow me down.
The strong typing of purely functional languages makes refactoring a breeze and let’s you quickly iterate and move from prototype to production.
All free, scalability won’t be a problem since it’s a niche app and db r/w work is minimal. I estimate I can support 10k userbase all for free.
I tried rails in conjunction with roda in the first 2 weeks, but I felt far more productive with roda for my use case and stuck with it.
2. VueJS for frontend
3. Hosted on Laravel Forge (using AWS)
4. Amazon RDS - MySQL (or similar) -- relational databases still solve most of the things I need, unless there were specific reasons to switch to a nosql
5. Tailwind CSS
2. Postgres 15
3. Python 3.10/Django 4.x served with gunicorn
4. Jquery and or alpine js
5. Bootstrap 5
6. Caddy to serve everything
7. S3 if a lot of file uploads are needed
--
I'd definitely keep using the same stack post mvp by vertically scaling the db, horizontally scaling the app servers.
- HTMX + Thymeleaf (replacing need for any SPA framework)
- Bootstrap
- Vanilla JS when needed
- Postgres
- Deploy on Ubuntu server with a deploy.sh that just does cd => git pull => gradlew build => systemctl restart X.service :)
Why? I have been convinced that most web application can and should be created without JS frameworks :P
Disclaimer: I maintain an init tool for this stack so I'm somewhat biased
Why? Very simple, fully featured, ready to scale.
Databases - Firestore for front-end related data - BigQuery for Analytics
Front-end - ReactJS with Hooks - MUI Material
...So - anything. Simple WordPress page with some content builder would work.
No need to invent functionality before testing out the need.
If the code is planned to be a separate React + API app, for example because React Native will be used, the I'd use Go
Backend:
* Java Spring if it looks like monolith.
* Golang if it looks like microservice architecture.
Postgres for data.
S3 for blobs.
RabbitMQ for queues.
Kubernetes for infrastructure. Managed or self-hosted, doesn't matter. One 16GB VPS is good enough for start and can be scaled later.
That's my approach to any architecture today.
I am in fact building MVP right now with Nextjs and Nestjs, i've never felt more productive than this
For hosting I'll use Hetzner.
backend: express + prisma + sqlite
frontend: vite + react + react-query + chakra-ui + zustand
infra: cloud run, prerender
I've found that combination to give me amazing DX and appropriate speed of development.
I actually prefer Flask and SQLAlchemy, but I haven't found anything to beat Django for sheer "ten minute POC lets-do-the-show-right-here" pulling something out my arse.
Lambda, DynamoDB, API G/W, SNS/SQS, EventBridge, S3, Cloudfront.
Reasons: no servers, no VPCs, no k8s yaml, great tooling, easy to deploy (serverless framework, terraform, etc), easy to secure.
* javascript / js: 95
* rails: 89
* django: 86
* postgres / postgresql: 77
* react: 75
* python: 52
* supabase: 52
* elixir: 44
* ts / typescript: 41
* nextjs: 31
* sqlite: 29
* laravel: 28
* vue: 27
* phoenix: 27
* net: 26
* htmx: 23
* node: 23
* html: 20
* github: 20
* tailwind: 18
* rust: 18
* ruby: 18
* aws: 17
* vercel: 16
* prisma: 16
* docker: 16
* graphql: 15
* firebase: 15
* php: 14
* flask: 13
* svelte: 13
* hotwire: 13
* liveview: 12
* curl: 12
* grep: 12
* bootstrap: 11
* fastapi: 11
* spa: 11
* java: 11
* linux: 10
* express: 10
* sveltekit: 10
* go: 10
Smalltalk, Squeak, Pharo, Seaside, PierCMS, Lively Kernel
Used by several succesful startups.
I don't have any experience with Svelte yet, but I hear good things about it compared to other front-end frameworks. I'd definitely want to separate front and backend.
Backend: Go and its ecosystem
Frontend: jQuery & Bootstrap
Database: Depends on the idea
I can make fairly complicated UI interaction with these, I am crazy fast with these, and I have confidence that I can scale it as well.
but recently i would use cloudflare pages, r2, d1, zero trust… in many cases, we don’t want to put eggs in the same basket. but in some cases (eg, building mvp, toy projects…), it’s convenient to be on an all-in-one platform .
for example, i recently launched a cms entirely on cloudflare: https://www.microfeed.org/
The advantages of writing everything in the one language is massive.
I'm currently making something with these for the first time. I picked sqlite because it's convenient and seems to be supported on free hosting.
Alternatively, NextJS with Firebase (or any other cloud DB) and deployed at Vercel.
To scale: 1. N number of VPSes distributed around the world with LiteFS (most likely Hetzner)
2. SvelteKit and SQLite (with Prisma)
3. Anycast Service to direct traffic
I have a lot of opinions on frontend stack too but they vary based on product.
Java 17 Quarkus backends with GraphQL, PostgreSQL as DB
Hasura to stitch the APIs if needed
logto.io for AuthX
Svelte with Sveltekit, Tailwind, DaisyUI as a frontend
If I needed a long running server for whatever reason I’d supplement Supabase with a NestJS app.
Back end: Python, mypy, Django, Django REST Framework, Celery, Redis, PostgreSQL
Frontend: TypeScript, React, apollo client, graphql-code-generator, tailwind
Backend Logic: Lambda functions written in TS, packaged with serverless.com, but deployed with Terraform
CI: GH Actions
Deployment: AWS via Terraform. One account per environment under an umbrella org.
Because I've used this stack so many times I can get a "shovel ready" foundation going in minutes with a skeleton that I've been iterating on.
Not sure about where I would store relational data, I typically design systems to not need it, its just a system design problem
Postgres
React - createreactapp
Theres a few react frameworks I might sub out for now but otherwise this combo is a way to get things done right and quickly.
99% of your projects do not need hyper scale and you are just engineering problems for yourself.
If it had to go on the web, then I'd try to output to WebAssembly.
- Backend: GoLang + Kubernetes
- Database: PostgreSQL
- Cloud: GCP + Firebase
- Computing: GKE Autopilot (or cloud run)
- Repository: GitHub (monorepo)
- CI/CD: GitHub Actions
If it's an MVP it doesn't need to be optimized with fancy frameworks until it has active users.
Of course it heavily depends on what your actually building.
I prefer to do most of my logic in the frontend and Flutter is great for this.
Solo dev vs 50 devs might need different tools just to get out of each others way.
Likely Adalo or Bubble, and Xano (stand alone DB with API)
Fast, easy to work with and adjust - it's a MVP.
I used to use Django as a first choice but nodejs/sql is much simpler.
React in front end.
Linux server running Caddy.
Could deploy to a VPS or AppEngine. Can run it locally.
Node/Express/React (can use next/nest)
NGINX Let's Encrypt
To OP - It will be great to turn this in to a poll :-)
* And has good IDE support for opinionated formatting
* And doesn't require a ton of setup-to-build effort (ie, no debugging your build tools)
* And has a quick pipeline from local development to production
That's it. Language, database, framework, it doesn't matter as long as you meet those four criteria.
htmx & hyperscript because I made them
- Server-side rendered app with Golang
- If interactivity is required: maybe Vue.js or jQuery
That's it.
Why? Because i know these technologies fairly well.
KISS.
typesafe next react trpc and prisma
It’s the opposite of what a lot of people recommend. It’s not battle tested. Both of these technologies are still maturing BUT:
I can write everything in JS/TS, I don’t have to get good at Ruby PHP or Python
Postgres is a great skill to learn.
Supabase is portable and can be self hosted, and its JS client is easy to use for DB manipulation and stuff like object storage.
For me, building a true full stack web app (not a todo list tutorial but something with real custom features) was going to be a learning process because I’ve been so heavily front end focused. So I decided to try to learn with the most modern tools available. It’s mostly worked out. I’ve had to ask for help on Discord a lot, especially with Supabase.
I have this idea for a blog post called “it’s just a CRUD app” that kind of challenges this idea that CRUD apps are brain dead simple. When you look at the myriad of options for building and deploying one. We’re talking like 50+ frameworks. Methodologies like dependency injection, micro service and monolith patterns. Yeah maybe it’s simple if you have been doing it for 15+ years and are comfortable with your stack but if you’re newer to the game, there’s a lot of complexity at play and the best choices for your situation are not obvious. Before moving to Supabase I was using NestJS because I was convinced I needed this framework with guard rails, but I hated it. So moving off that caused a lot of churn.
Edit: I also wanted to mention that the biggest split amongst all these recommendations IMO is how the backend and frontend interact with each other. Some of these frameworks will render frontend views for you. Then you're dealing with a very classic web app. Then you hear other people in this thread talking about HTTP handlers, and it's clear they're talking about the backend existing as a REST API, which IMO is a bad pattern to use for your own app. REST APIs should be used for exposing your service to third parties.
But there's a third way, that's becoming popular amongst the "bleeding edge" with things like Next.js and SvelteKit that have a "backend for frontend" where they have to run a node/deno based server anyways to do on demand SSR and hydrate. Having a separate backend, especially a separate backend that is just a REST API leads to a ton of redundant code and confusion.
So instead with ORMs like Prisma, people setting a persistent DB connection on this backend server and accessing/manipulating the DB directly with some kind of client. I think this approach came to prominence alongside the rise of GraphQL. That's basically the way Supabase works - they have a JS client and you interact with it in a similar way you would Prisma or TypeORM. They even have an article about how their client can be used in a similar enough way to GraphQL that it's not worth using GraphQL instead.
Instead of traditional controllers where you would stash a lot of business logic (including authorization), the idea is you leverage PostgreSQL's advanced features to help with that. I'm not a huge fan of this for multiple reasons. So you kind of have to make your own decisions on how much abstraction you're going to put on top of their client.
My backend is a custom/hybrid pattern I've been developing over the last few years which is primarily focused around CQRS + Event Sourcing + DDD.
I have a single backend "command interface" (really just a single http endpoint that receives the name of a command + a data payload. think POST the_beam_is_god.com/commands { command: "request_login_link_via_email", data: { email: "snake_case_rulez@aol.com" } }
The command names are arbitrarily named based on the needs of my business. I make no concern for the internal code structure of my app with naming commands. This allows business people, frontend people and backend devs to all communicate in english and focussed on the business domain only. It's up to my handler function for this specific command to do any business logic validation, etc. If all good, an event is written to a stream (or linked to multiple streams) and the command handler function is done. Its concern ends at the point of publishing an event into a stream (or responding back with a rejection). (note: the events go into postgres, but any store would work as long as you can index on the stream names)
The above command example might publish an event called "UserRequestedLoginEmailViaTheApp" into a stream called "LoginActivity:snake_case_rulez@aol.com". I do lots of small streams of related activity. (related in context of the business logic of my domain).
The other half of my system is a series of handler functions that do arbitrary business logic things when events are published. To continue with the example: UserRequestedLoginEmailViaTheApp is mapped to one or more handlers. One obvious handler for this type could queue up the email delivery. I can do anything in these handlers in response to the fact that X activity HAS occurred. Another frequent thing I do in an event handler (I call them Reactors) is play back a domain model stream to get its current state (via a "projection") and update my (R)ead store. Think "UserUpdatedName" event in a stream called "User:id123". Command "update_user_name" -> Event gets published -> Reactor reacts and pushes a new version (current state) of this user into the [mongo] users collection -> then a subscriber process (elixir genserver) to the mongo oplog reacts and pushes the new version of this user down a websocket to provide live data updates to any apps/frontends.
Maybe this sounds complex and bloated at first read, but my codebase boilerplate is ridiculously small, a few dozen lines. What's cool too is that this can be done in any language/runtime environment.
I started doing this in ruby in 2019, but as I was getting up to speed on elixir I realized that the beam mapped perfectly to this strategy. CQRS itself is merely a higher level execution of the actor model (the beam) itself. Upon realizing this, I actually attempted to shoe-horn my pattern here into the GenStage architecture. I did get it to work, but I did not continue down that road.
I could talk about this for days because I love it so much.
bonus: no inheritance, no dependency injection, no interfaces, no wanting to quit and become a farmer because of the insanity of complex OOP
- Tailwind
- Hasura / postgres
- DigitalOcean - docker droplet
- Caddy
- Cloudflare
Backend: Go
Frontend: React
App: Flutter
create-universal-app : https://github.com/chen-rn/CUA
Which would give me: - Tamagui - React Native Web Lite - Expo - Next - Solito - Prisma – Clerk - tRPC
But I'd likely throw out Clerk for a cheaper option:
- Supertokens, since it's also easy (lots of enthusiastic reports about it), has a managed solution (which is cheaper than the alternatives), is secure and scalable (rotating refresh tokens with JWTs), open source, offers passwordless / magic links, and the architecture of Supertokens would allow me to simply and quickly eject to self-hosting it if/when I'd eventually need to (if the app ever reaches mass-market scale).
And I might throw out tRPC for the equivalent GraphQL and TypeScript inference experience (esp. if business strategy dictates I need a 3rd party API):
- GQty.dev on the client, for inferred queries/mutations. For rapid dev speed. Simple code example: https://gqty.dev/docs/intro Then move to URQL or Relay at scale, or just skip GQty and go with URQL from the start (if scalability trumps dev speed).
- Pothos http://pothos-graphql.dev on the server, for auto building the schema from your TS code (aka. code-first). Better than Nexus (e.g. Max Stoiber moved from Nexus to Pothos on his Bedrock starter template because Pothos is best in class: https://bedrock.mxstbr.com/tools/pothos/ ).
And I might throw out NextJS (Webpack) for the equivalent experience in Vite:
- vite-plugin-ssr, since both architectural control (libraries > frameworks) and Vite rocks. I'd likely then have to make solito-vite https://github.com/nandorojo/solito/discussions/157 to have a unified navigation between React Native and Web, but Solito is allegely tiny, so recreating it should be doable.
(If doing all of these replacements, maybe starting from scratch would be easier than modifying create-universal-app ... That said, I think if someone made a starter repo with the above choices it would be a real killer!)
Then I'd also likely use:
- Vercel (and try their Edge Functions, for a serverless sweet v8 isolates experience without slow cold starts), or maybe Cloudflare Workers (cheaper, slightly more hassle?) for hosting.
- Planetscale or Supabase for the DB. (Not brave enough to try EdgeDB or SurrealDB just yet, though EdgeDB is close..) Unless I had a specific use case where a more specialized/optimized DB would make sense.
This stack should stick even post-MVP, as it's not only optimized for a solo developer but for scalability.
Runtimes: OCI containers with Docker, there are other options out there as well, but this one is stable and boring, plus makes deployments easy. Probably at least something like Docker Compose or maybe Docker Swarm (more or less uses the same format) to orchestrate stuff across multiple nodes and take care of networking, if needed. Maybe Portainer for easier management. Can later move to Nomad or Kubernetes if needed, but the previous options are good enough.
Databases: probably MariaDB/PostgreSQL for relational data, if needed then MongoDB as a document store, MinIO (S3 compatible) for any larger binary blobs, Redis for key-value storage and RabbitMQ for queues. Admittedly, in most cases you won't need that much more than just a single relational DB instance, unless you have particular workloads to deal with. Honestly, even SQLite can be a good starting point for a single node deployment.
Back end: honestly, any of the most popular languages out there. Java (either Dropwizard or Spring Boot) or .NET (ASP.NET) for good performance and rich ecosystems, Go for small statically linked executables, Python for packages to do basically anything (most likely Flask/Django in webdev), Ruby for particular CRUD setups (with Rails), Node (most likely with Express.js) for getting up and running relatively quickly. Personally, I'd opt for static type systems when not in too much of a hurry, but also recognize the benefits of any of the options listen. Frankly, they're all good enough, so just pick whatever feels suitable for the problems you want to solve. Even PHP with Laravel is viable nowadays.
API design: probably something RESTful, though some like GraphQL (personally, I think that it brings a certain amount of complexity with it), in rare cases would also go for something like gRPC or also WebSocket stuff, though again it depends on what you're building.
Front end, server side rendering: if you decide not to make a RESTful API but are okay with server side rendering (certain Django, Rails, Laravel setups, for example), then you won't have to think about this too much. In those cases, I'd just throw in something like Bootstrap and maybe something to make dealing with JS easier.
Front end, SPA: However if you're building a SPA (which is great because you can swap out front ends or use it for other stuff, not just the current UI) then I'd recommend you look in the direction of Vue 3 + a component framework/library like PrimeVue. Angular does TypeScript really well but is cumbersome to work with, React seems to get more and more complex with every release, whereas Vue does everything from hooks to recommended state management solutions (like Pinia) well and without too much accidental complexity. I'd pick the component framework/library because making your own is sometimes a waste of time. I'd consider TailwindCSS, but not always.
Web servers: personally I'd go with Apache for my own reasons (modules for most stuff), but Caddy is also excellent. Nginx is also good, but doesn't do ACME certs out of the box, although setting up certbot isn't too hard. I've written on my blog about using Apache, actually: https://blog.kronis.dev/tutorials/how-and-why-to-use-apache-... and about Nginx as a reverse proxy.
Day 2 concerns: I'd also look into Matomo analytics if the MVP gets popular, as well as Zabbix for server monitoring, Uptime Kuma for uptime monitoring, maybe way later something like Graylog for log shipping and Apache Skywalking for APM/tracing. For managing nodes, Ansible can be a good bet later.
So it might look like: Ubuntu + Docker + MariaDB + Ruby + Rails.
It might also look like: Ubuntu + Docker + PostgreSQL + Node + Express.js + REST + Vue + PrimeVue.
Or any other number of combinations. It's hard to go completely wrong nowadays. Cloud options are also nice, but personally I like being able to run basically the same thing both locally and on a server somewhere. Actually, I had a somewhat related blog post about this, "How boring or novel should your technology choices be", too: https://blog.kronis.dev/articles/how-boring-or-novel-should-...
For something really minimal, an internal tool, I'd probably use grist. Grist is a "no code" spreadsheet program that is open source and works on a relational database. I just threw together an inventory management system for my weekly dnd group in a few minutes, and I've shared it with the group. I find the relational mindset grist uses a lot easier to reason about than traditional spreadsheets.
The next level up would be django with htmx. Very minimal javascript, I might embed a javascript "applet" like a map into it if needed. This covers 99% of data driven apps.
If I wanted to build something like say discord I'd probably use a pretty similar stack for the MVP, but with server-sent-events (htmx with server sent events is nice) and web components for more complicated interactions. That's probably why I'm not in charge for building complicated single page webapps with a lot of interdependent state though. I maintain this approach should work but haven't had a real chance to test it in the wild.
If I'm writing CAD software I'm probably going with QT/python/(numpy/jax/compute-shaders/sympy/etc). Python might not be the fastest, but when you're accelerating it with one of those machine learning libraries it can be really powerful. I've actually been working on something CAD-ish using that stack here: https://github.com/traverseda/PySdfScad
That's probably roughly the same stack I'd use for things like computer vision, machine learning, etc. Ironically anything where performance is important I'd probably choose python over a compiled language.
Mind you the QT python documentation is really not great, for a really minimal MVP I might swap qt out for pyimgui which is amazing for rapid prototyping but is going to be a real pain to do things like syntax highlight a text editor or embed HTML content.
Embedded electronics? Probably micropython on an ESP32 for an MVP. A REPL on your microcontroller is really nice. Robotics I'd probably use buildroot to build a custom linux distro. ROS is pretty heavy and I find it gets in the way a lot, but if you need ROS stuff obviously use ROS.
I don't have much experience with mobile development, so I'd probably end up using QT with python and pyqtdeploy, but that's not an approach I'd recommend anyone else follow. I'm keeping an eye on Tauri in that space, although I really wish they made it easier to bundle in things that aren't single page javascript web apps (like a python application).
So yeah, mostly I'd use python. Master of some trades, jack of a bunch of others, it's flexible and powerful enough that I feel happy to have specialized in it, even if deploying apps to end users can be finicky and annoying. I'd avoid the javascript ecosystem as much as possible, and where I'd have to use javascript I'd prefer to make self-contained web components.