I expected a lot less for "one man." Kudos to you OP.
The Tech Stack of a One-Man SaaS
31–40 of 259 posts
Re: The Tech Stack of a One-Man SaaS
#32It'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…
SaaS business single founder here, moved from a mix of GCP's Cloud Run, Cloud SQL, and Compute Engine to DO's managed Postgres and Kubernetes, and it has had the follow effects:
- Much cheaper, reducing bill from >100$/month to ~40$. Important for early stage startups - More performance, easier scaling. Found that my application was much better suited to run in K8S, but this is definitely specific to my use-case - Consolidation of resources. Except Postgres/Redis, everything is in my cluster, simplifying management and maintenance
For my business, this was a great move, but as others have said, I wouldn't recommend it to everyone. K8S is a great and powerful tool, but also is very complex.
Re: The Tech Stack of a One-Man SaaS
#33The secret behind this stack is not its simplicity, but rather it's simply the stack they know the best.
Re: The Tech Stack of a One-Man SaaS
#34But does Python scale for back end applications?
A single core running Python will easily handle more load than most successful SaaS companies ever reach, especially in web dev where most of the real work happens in a database of some flavor. There absolutely are performance pitfalls, and Python is less power efficient than other alternatives running some kinds of workloads at scale, but in a ton of environments the perf difference doesn't matter.
I do ruby/Rails and not Python, so it may differ.
But while I too had in my head "for web dev most of the real work happens in a database of some flavor", I recently realized that was not true for my app, probably hadn't been true for some time, and probably isn't true of most Rails apps (possibly not the same for non-Rails web apps?). If you've properly eliminated n+1 queries and other inefficient querying, I find that my apps are spending only 20 or 30ms waiting on DB results, and a couple hundred on CPU tasks to render HTML.
I know people are going to reply with "That's because Rails is slow," but I'm not sure that's true for what we're talking about compared to similar Python platforms, I'd be interested in seeing numbers for other real apps. In the Rails community too, people still repeat the assumption "most of your response time is spent waiting on the DB" -- but I dont' think it's actually true anymore (it may have been once).
Re: The Tech Stack of a One-Man SaaS
#35Have you considered Amazon’s SES for transactional email?
Re: The Tech Stack of a One-Man SaaS
#36It'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…
> The whole "cattle not pets" thing is fine once you obtain product market fit and your product needs to scale up. At that point you'll have time and money to do it - before then you're just wasting cycles.
Is this true? At my last company we wasted a bunch of time every week dealing with the accumulation of ad-hoc changes in different environments creating different behavior. When we pivoted to a continuous deployment model (we also moved from EC2 to ECS/Fargate), all of this time went away as did all of the guess-work and fear of deploying to production (because production very rarely deviated from lower environments with respect to behavior, because all environments were reproducible). It also enabled us to stand up whole environments with the press of a button, which made it a lot easier for developers who were interating on infrastructure (we had a lot of async ECS/Lambda workloads). I'm sure if we were smarter or had the right kind of discipline we could have made pet EC2 instances work, but we benefited a lot from moving to cattle/containers.
NOTE: I also suspect that cattle/EC2 is a lot harder than cattle/containers, but that may also just my inexperience with the former. I would really like to know how to do reproducible EC2 instances properly, but from the research I've done, it seems like one has to reinvent a good chunk of Kubernetes.
Re: The Tech Stack of a One-Man SaaS
#37Honestly, 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 support this sentiment so much. I've been building something in my spare time. You are one person, the value provided with Heroku and the time saved is worth the cost versus AWS, at least for a project of this size and scope. It would take a lot more customers and capacity on the server to justify the ROI.
Re: The Tech Stack of a One-Man SaaS
#38Honestly, 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…
Heroku is a great product if you want development speed right from the start. I have used them in the past, and it was a very nice experience overall.
For many projects this is more than enough. However, in my case I would be paying 2-3x more if I was using Heroku.
With Kubernetes, in case I wanted to deploy new projects or even spin up a "testing" env, I can use the same stack/cluster, and not have my costs increase.
I do realize that this is not for everyone. But for me it just made sense, and enabled me to work on new features faster than before.
Re: The Tech Stack of a One-Man SaaS
#39It'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…
SaaS business single founder here, moved from a mix of GCP's Cloud Run, Cloud SQL, and Compute Engine to DO's managed Postgres and Kubernetes, and it has had the follow effects: - Much cheaper, reducing bill from >100$/month to ~40$. Important for early stage startups - More performance, easier scaling. Found that my application was much better suited to run in K8S, but this is definitely specific to my use-case - Co…
Did you experience the downtime issues with DigitalOcean managed Kubernetes that the author also experienced? I'm also considering DOKS so would be great to know!
Re: The Tech Stack of a One-Man SaaS
#40It'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…
SaaS business single founder here, moved from a mix of GCP's Cloud Run, Cloud SQL, and Compute Engine to DO's managed Postgres and Kubernetes, and it has had the follow effects: - Much cheaper, reducing bill from >100$/month to ~40$. Important for early stage startups - More performance, easier scaling. Found that my application was much better suited to run in K8S, but this is definitely specific to my use-case - Co…
I’m running something similar and have to admit that the ~70$/month for CloudSQL grinds my gears a little. The pricing for Cloud Run on the other hand is pretty sweet.