Live data from Hacker News

The Tech Stack of a One-Man SaaS

panelbear.com

61–70 of 259 posts

Re: The Tech Stack of a One-Man SaaS

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

>Most people would be better off with a single beefy machine running Linux, Postgres and whatever web app framework they know

The problem is back ups. You've got to figure them out yourself. And there's a decent chance that you do it wrong leading to potentially catastrophic data loss.

IMHO, managed DB + S3 equivalent and then doing your own server is the sweet spot. You don't have to worry about data loss and it's still pretty cheap and flexible.

Re: The Tech Stack of a One-Man SaaS

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

I think it entirely depends on the path you're taking. For example, I'd disagree with the quoted section you made for a different reason. I'd almost always suggest early stage startups to use something like Heroku (if it works for them), which gives them the ability to pay a small premium in order to never have to spend too much time dealing w/ devops stuff. Pre product-market-fit, that's wasted time/effort unless specific devops needs are essential to getting there.

Re: The Tech Stack of a One-Man SaaS

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

Thanks for sharing your thoughts!

To clarify, this has already helped me to ship features to my customers quickly. I actually spend little time working on the stack. Last time I touched the infrastructure components was probably a few weeks ago.

Panelbear was originally built and launched in a weekend ($5/mo DO instance with SQLite), and I've been working on it for the past 3 months. I have been releasing a new feature every week. That is, in addition to my full-time job, so most of the time we're talking about 2 hours per day tops.

I'd also like to clarify that I am not suggesting this stack should be used by other solo founder SaaS. I actually advice against it in my post :)

I just wanted to share my stack, as it has worked really well in my case, and I thought it'd be interesting material for discussion.

Re: The Tech Stack of a One-Man SaaS

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

You definitely want "one click" deployments from the git go. Then it's just a small tiny step from that to your servers being cattle.

Re: The Tech Stack of a One-Man SaaS

#65
post #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?

I meant some sort of JavaScript framework. I'd say that part mostly depends on personal preference. I'm quite happy with Angular, but I've also had lots of smaller one-off pages where I used jQuery.

Re: The Tech Stack of a One-Man SaaS

#66

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…

I'd actually suggest PostgreSQL + Hasura + React with Ant Design or Material UI

Re: The Tech Stack of a One-Man SaaS

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

When you say "we" it sort of implies this was not a one-man operation.

Re: The Tech Stack of a One-Man SaaS

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

Personally, I run a Kubernetes cluster that all my projects go on by default. DigitalOcean hosts mine and my bill is pretty low. I set it up for this exact reason, so I could continue to use my knowledge of containers and container scheduling systems to get easy wins early on.

Re: The Tech Stack of a One-Man SaaS

#69
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 second this. If what you are familiar with is but know it would work, go with it. You don't have to struggle with a new tool if something similar is already in your toolbox, and you already have a lot of experience using it. Of course, do this unless you are building to learn (and maybe ship), rather than to just ship. And if the new tool proves to be a better one, you can upgrade then.

Re: The Tech Stack of a One-Man SaaS

#70
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 Sa…

I'm a Rails guy. I've been working with it for the last 10 years and it (now) allows me to be hyper-productive. I've put other languages and frameworks into production but nothing allows me to focus like Rails does.

There is a meaningful amount of boilerplate that remains for any stack if you're using it for a SaaS. It may not hurt to invest in a commercially-available solution that takes care of billing.

For some products (super-hyper-MVP), I've gotten away with having a `companies` table with a `state` column which was either `active`, `inactive`, or `past_due`. I would update this manually from Stripe every day. When it became a chore (aka "I am spending an hour on this every day and my time is better spent elsewhere") I only then wrote code to handle it.

There are solutions like Recurly or Chargebee that take a way a lot of pain on a platform basis. Those may be helpful in managing some of the complexities, but they come at a cost: financial, vendor-based, flexibility.

It's important to keep in mind that your ultimate goal is to get customers validating your idea. While it's important that you conduct a meaningful transaction in exchange for solving their problem, that does not mean you need to handle every single last billing case.

Accept their money, let your solution solve their problem, and repeat.

If you want to talk more my email is in my profile.

Post reply on HN