cj
Small secret:

The best tech stack when starting a startup is one you don't have to learn.

There's a million things you learn when starting a company. Don't make yourself learn an entirely new tech stack on top of everything else. This advice means you'll be using whatever you've used in the past which might not be the sexiest or newest technology, but your users won't care. Your users want a working product. Choose the stack that will result in a working product the quickest.

Refactor and migrate to a better stack later, if necessary. (It rarely is)

For me, that meant deploying to Elastic Beanstalk (I know, boring, no one talks about it, but it works!) and using Mongo because I was already comfortable with it. It also meant not using React, at first. This was the right answer for me, but might be the wrong answer for you! Build your app on the technology you know.

dmwilcox
Context: I write mostly write Python for a living and run a Django app as a major responsibility

I always wonder if python, auto scaling, and cloud change the kinds of businesses (and margins) required. Running 60+ pods of gunicorn for an app incurs lots of overhead, especially if one is using small VMs.

I can't count the number of war stories I've heard from SRE friends who joined some company and realized they were taking over a Django stack for the core of a business that was blowing gaskets left and right.

This sort of thing just leaves me wondering if margins have to be high to support a slower language, slower framework, and complicated deployment model to work around the Python GIL.

Call me jaded but I just wonder if it's worth the time to market to do Python these days versus say Go and be able to deploy a static binary and use all your CPU cores simply. K8s is way less tempting for a "one-process-architecture " (minus database and maybe nginx) until the system is much larger (instead a couple of systemd units would sort you)

qeternity
I see a lot of comments to the effect that this is a complicated setup, especially for one person. I really think most people need to re-evaluate their stacks without all of the marketing of cloud providers and gigascalers.

This setup is very similar to the startup that I run. We have used k8s from day one, despite plenty of warnings when we did, but it has been rock solid for 3 years. We also decided to run Postgres and Redis on k8s using Patroni + Sentinel and the LVM storage class. This means we get highly performant local storage on each node and we push HA down to the application.

Was there a learning curve? Yes, it took a solid week to figure out what we were doing. And we've had the odd issue here and there, but our uptime has exceeded what we would have had with a cookie cutter AWS setup, and our costs have been a fraction (including human capital costs).

welanes
Things are much easier for one-person startups these days—it's a gift.

I remember building a todo app as my first SaaS project, and choosing something called Stormpath for authentication. It subsequently shut down, forcing me to do a last-minute migration from a hostel in Japan using Nitrous Cloud IDE (which also shut down). Just pain upon pain.[1]

Now, you can just pick a full-stack cloud service and run with it. My latest SaaS[2] is built on Google Cloud, so Authentication, Cloud Functions, Docker containers, logging, etc straight out of the box.

Not to mention, modern JavaScript and CSS are finally good. With so many fewer headaches, it’s a great time to build.

[1] Admittedly, I was new to software dev and made some rather poor tech choices

[2] https://simplescraper.io

mattbillenstein
Guy lost me at k8s and terraform - just put your thing on a single VM and yolo.
mitchbob
(2021). Discussion of this when it was first submitted (320 comments): https://news.ycombinator.com/item?id=26737771
esafak
This is pretty sophisticated for one person.
FlyingSnake
Came here expecting a tangled mess of disparate frameworks but was pleasantly surprised to see sane choices in using Django as a base. Sane choices and it shows why the product got acquired.
wiradikusuma
My backend setup for my one-person startup ("case study" for my book, https://opinionatedlaunch.com) is GitHub (for code repo and CI/CD), Firebase (auth, analytics, push notif) and CloudFlare (static pages, DNS stuff) and Fly.io. Less work but more done.

My only complaint Fly.io doesn't have managed DB (https://fly.io/docs/postgres/getting-started/what-you-should...) and task queue.

At work we use GCP, but try to be as high as possible in the abstraction layer (e.g. use Cloud Run and Cloud SQL).

enahs-sf
I think the nice benefit here is because of OPs infrastructure experience and process, he can now quickly run and test new ideas and projects for a reasonable marginal cost. Seems legit. Very clean setup.
andrewstuart
I closed the page at "Kubernetes", despite the "you may not need this", because that was all I needed to hear to know this setup has little to do with the ordinary one person tech startup.
extr
Would be interested to know which parts have better solutions as of 2024. But still feels pretty relevant.
codeisawesome
I’d love to read a blog post from successful one person startups that are in the highly competitive spaces like DevOps tooling (uptime, analytics…) on how they go-to-market and differentiate.
grandimam
Interesting! I was wondering why the author choose Python + Django on the server-side when they could have just used TS + React + NextJS across the stack? On reason is that the author is relying on Celery for background jobs, but is there any performance reasoning for having a completely different backend stack.
nunez
Honestly, this is a pretty solid stack.

I wonder how they make time to manage it all _and_ iterate on projects _and_ have a life outside of that.

This is the biggest problem I've long struggled with. I don't know of a good solution.

dakiol
I wish they could have explained the deployment/release part via ci/cd more in depth.
ACV001
Stack and the technical part is rarely the important factor in success. The idea and marketing seem to be the important bit. The stack can be the cause of failure, but it can never be the reason for the success of a startup.