Live data from Hacker News

The Tech Stack of a One-Man SaaS

panelbear.com

51–60 of 259 posts

Re: The Tech Stack of a One-Man SaaS

#51

Here's my self-serving advice for every one-man SaaS: Use Heroku. It's super easy to get started. And when you reach $2000+ in monthly bills, hire me to move things over onto dedicated or EC2 so that you'll get 10x that performance for the same price. As for the actual language, I think PostgreSQL + Ruby Backend + JS Frontend is still the easiest way to get started. All those great architectural ideas don't matter mu…

> PostgreSQL + Ruby Backend + JS Frontend is still the easiest way to get started.

With JS, do you mean React or jquery or literally JavaScripting the DOM?

Re: The Tech Stack of a One-Man SaaS

#52
post #39

Earlier quoted context omitted.

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!

I had no issues so far, everything has been fairly smooth. Setup was very easy too (was my first cluster setup), and pricing is very good.

Re: The Tech Stack of a One-Man SaaS

#53

Earlier quoted context omitted.

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.

Agree. The databases we're my biggest costs on GCP, and DO offers more for less.

Cloud Run, as you said, is pretty great. In my other start-up, we're using Cloud Run and Cloud SQL, and again, Cloud SQL is the biggest cost (~95-99% of the bill)

Re: The Tech Stack of a One-Man SaaS

#54
Serial one-man SaaS builder here with a pair of soft-landings and one big hit:

I would agree with others who have opined that this is overkill. You couldn't pay me to use Terraform or Kubernetes for my SaaS unless it was a much larger team.

My stack usually consists of this: A framework I am comfortable with that removes a lot of boilerplate (happens to be the one I know best in the language I know best), the database I know best, the memory store I know best, Turbolinks for load times, a theme from ThemeForest (with the commercial license), self-hosted analytics, Amplitude, and Heroku.

The author mentions "lessons learned" regarding Clickhouse and Kubernetes. I'm not sure what their original goal was when starting their SaaS. Usually mine is financially motivated more than learning things.

What I'm really saying is that just go with what you know best. Having to scale is a good problem to have. Pre-optimization is the root of all evil — asking "is x the right stack for y?" will always be yes when you ask in the x subreddit.

Stop thinking and build.

Re: The Tech Stack of a One-Man SaaS

#55
Seems like there are a couple of tech stack posts on HN lately and I certainly enjoy reading them.

But as a techie, the magic to me no longer lies in the product building, but in the ‘finding the first 10-100’ customers part.

Have there been any posts on that lately?

Re: The Tech Stack of a One-Man SaaS

#57
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…

Setting up Kubernetes is a fixed cost in the beginning with clear payoffs. Things like microk8s, Rancher or GKE/EKS make it a lot easier to set up than it used to be. Deploying your app is then just a simple Helm chart, or another way of getting deployments out. If I was running any kind of business that was making more than zero dollars I would absolutely go with Kubernetes. I don't think it's as complicated as people think at any rate, and it lets you use premade Helm charts which can simplify the deployment of things like Clickhouse.

Re: The Tech Stack of a One-Man SaaS

#58
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…

> 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 deployme…

My take would be that once you need another environment than staging+prod, that's the time to move to at the very least move to containers, and probably think very hard about either a hosted Kubernetes or something like Fargate.

Re: The Tech Stack of a One-Man SaaS

#59
post #54

Serial one-man SaaS builder here with a pair of soft-landings and one big hit: I would agree with others who have opined that this is overkill. You couldn't pay me to use Terraform or Kubernetes for my SaaS unless it was a much larger team. My stack usually consists of this: A framework I am comfortable with that removes a lot of boilerplate (happens to be the one I know best in the language I know best), the databas…

OOC what framework do you use?

More broadly, can you help me with an opinion on my present struggle? Here goes:

I have a lot of ideas, a couple of which solve problems for me and I think are even _good_ ideas. However, none have shipped because I'm spending an inordinate amount of time building out what is essentially my own SaaS template. Is it worth investing the time in doing that, or are some of the commercial SaaS templates out there (sjabloon, bullettrain, etc)

I prefer Python/Flask, but I'm trying to learn Rails now, since a lot of the small saas ecosystem seems to exist there.

Re: The Tech Stack of a One-Man SaaS

#60
post #16

Earlier quoted context omitted.

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 t…

time "spent" in the database depends on the speed of DB drivers too, which depends on the language. Our stuff is Java and average query is ~2ms round trip.

Python, Ruby and friends are bad for page speed metrics. REST response time of ~200ms vs ~10ms for our java backends

Post reply on HN