Live data from Hacker News

The Tech Stack of a One-Man SaaS

panelbear.com

231–240 of 259 posts

Re: The Tech Stack of a One-Man SaaS

#231
post #152

Earlier quoted context omitted.

I guess he means the Kubernetes API which is what most of the controllers, and other components talk to. That was my case too. It was mostly when I installed the prometheus-operator that things would go south, even if the nodes themselves were perfectly healthy and underutilized.

Gotcha, thanks for the info! Do you know if were just doing run of the mill Pod deploys of like wordpress and little MVC apps and stuff with no K8s api calls we should be fine? I like the autoscaling and the infrastructure as code, and price for DOKS is good.

I think that shouldn’t cause much troubles in DO. I had it running for a while without the prometheus operator, and I didn’t have any issue.

In the beginning I was even running everything on a one $10/mo “cluster” (cheapest DO offers). Even Postgres and Redis, all inside the cluster.

As I got more customers, I needed something less risky, so added more nodes, and moved the database out.

But to be honest even the 1 instance $10 cluster was fine.

Re: The Tech Stack of a One-Man SaaS

#232

Earlier quoted context omitted.

Thanks for the info. That doesn't sound good - one major reason for considering moving to Kubernetes was for the high availability.

Availability of your applications, and availability of the kubernetes control plane, are not typically correlated. One of the nice things about how Kubernetes orchestrates is that the master is not in the path of requests. Ie, in many situations the Kubernetes master may be unavailable, but your applications will be unaffected and can still serve traffic.

Thanks for the explanation!

Re: The Tech Stack of a One-Man SaaS

#233
post #166

Earlier quoted context omitted.

Heroku is a god send for getting off the ground, however the biggest issue for us hasn’t been cost (it’s high, but worth every cent) it’s been server location. We’re an Aussie company, and a large percentage of our customers are in Australia. Having servers only in the US and Europe mean that Australian customers speeds are slower than they should be, and private spaces are far too expensive to warrant it.

I have started using google cloud run as a drop in replacement for Heroku. It has almost all the same features and runs at almost any GCP location.

What about databases? One of the appeals of heroku is that you get databases as a service and don’t have to worry about backups, snapshots, etc.

Re: The Tech Stack of a One-Man SaaS

#234

Earlier quoted context omitted.

Agree on Heroku as well - the cognitive overhead they help take care of is well worth the money. There are other commenters saying "but it's expensive!", but your comparison should be Heroku vs. a Devops person (or yourself), not Heroku vs. . My one complaint is that their support seems to have gotten worse over the years - they used to have great support engineers across the board, but have hired poorly recently, sp…

It takes me about 2 hours to setup docker container + Github pipeline. I don't see why this is difficult. I am not saying go all out and manage your kubernetes cluster. I am saying that packaging your application in a docker container and running it in a VM is pretty straight forward.

Heroku also handles databases, backing them up, etc. And scaling up or down.

Re: The Tech Stack of a One-Man SaaS

#235
post #20

Honestly, having gone down this path a year back, just use Heroku for your backend. Maybe Netlify if you want to separate your frontend and backend. The amount of complexity and interdependencies these "here's my stack" posts describe are always a huge cognitive overhead for running a one-person SaaS. Heroku costs more, but there's a reason for it. If you're even remotely making money from your product, and are alone…

I recommend just writing a Docker container instead. That's the ultimately portability and you can run in much more efficient environments (Cloud Run, Fargate, DigitalOcean Apps, Fly.io) and still scale up to large Kubernetes-based clusters if/when you need it. Docker containers avoid the lock-in of a particular platform or CLI, and they can also be used as cheap CI/CD with multi-stage builds within the container.

You can deploy Docker containers to Heroku. I've done this (just requires a simple heroku.yml file and heroku stack:set container). If the project grows to the size where Heroku's costs become prohibitive, I can easily switch over to Digital Ocean with some tweaks to the docker config.

Re: The Tech Stack of a One-Man SaaS

#236

Earlier quoted context omitted.

It takes me about 2 hours to setup docker container + Github pipeline. I don't see why this is difficult. I am not saying go all out and manage your kubernetes cluster. I am saying that packaging your application in a docker container and running it in a VM is pretty straight forward.

Heroku also handles databases, backing them up, etc. And scaling up or down.

DigitalOcean also has managed databases+backups. I'm not sure how it compares on price/reliability though.

Re: The Tech Stack of a One-Man SaaS

#237
post #20

Honestly, having gone down this path a year back, just use Heroku for your backend. Maybe Netlify if you want to separate your frontend and backend. The amount of complexity and interdependencies these "here's my stack" posts describe are always a huge cognitive overhead for running a one-person SaaS. Heroku costs more, but there's a reason for it. If you're even remotely making money from your product, and are alone…

Is there an open-source Heroku alternative? I've used Heroku in the past and the "just deploy application code" nature is great for most applications but you're locked in to one vendor. Cloud Foundry?

https://github.com/dokku/dokku

Re: The Tech Stack of a One-Man SaaS

#238
post #14

It's cool that this stack works for the author, but if anyone is just starting out on their own one-person journey to build a product, I don't think they should follow the stack in this article. There are too many dependencies and too much complexity here. Kubernetes is overkill for 95% of applications, especially single founder SaaS businesses. Clickhouse may make sense for an analytics product but caring and feedin…

I believe 100% that a one-man SaaS needs to leverage their existing knowledge even more than a team. So for me it would be a no-brainer nodejs, dynamo, etc. - the tech I use every day and know in and out. You should have a very good reason to stray from your core if you actually want a business and not just a fun coding challenge.

This. You will want to focus on product design, customer acquisition, financing, investment etc etc. These alone are more than enough for a team, let alone one person. You don't want to be wasting your time and energy fixing server issues or obscure browser bugs at 3 am.

Re: The Tech Stack of a One-Man SaaS

#239

Earlier quoted context omitted.

Docker containers (on Linux) don't have a guest OS. They all share the same kernel and only the userland is different depending on which distro you choose for your base. You can choose to build on a scratch/blank image just as easily, which means nothing except your app itself is in the image.

You still have to update the packages or distro your image is based on. It’s not as maintenance free as heroku or google app engine.

Sure, but you can get the latest image automatically as part of your container build. It's not as hard as it seems.

Or you can build an image from scratch without any distro and then there's nothing to maintain.

Re: The Tech Stack of a One-Man SaaS

#240
post #235

Earlier quoted context omitted.

I recommend just writing a Docker container instead. That's the ultimately portability and you can run in much more efficient environments (Cloud Run, Fargate, DigitalOcean Apps, Fly.io) and still scale up to large Kubernetes-based clusters if/when you need it. Docker containers avoid the lock-in of a particular platform or CLI, and they can also be used as cheap CI/CD with multi-stage builds within the container.

You can deploy Docker containers to Heroku. I've done this (just requires a simple heroku.yml file and heroku stack:set container ). If the project grows to the size where Heroku's costs become prohibitive, I can easily switch over to Digital Ocean with some tweaks to the docker config.

Why not just save the money and start elsewhere?
Post reply on HN