161–170 of 736 posts
backend: express + prisma + sqlite
frontend: vite + react + react-query + chakra-ui + zustand
infra: cloud run, prerender
> What would be your stack if you are building an MVP today? 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 quickl…
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.
Stakeholders and managers want you to keep adding incremental features. Never had a situation where they were like "okay, cool MVP, see you in a few months after you tear it down and rebuild it 'for real'."
That "build a fast crappy MVP" mentality takes serious buy in from stakeholders from day one. That mentality might be common in SV and other startup communities but boy is it tough to find elsewhere.
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.)
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:
* 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'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...