Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Tech Stack of a One-Man SaaS

panelbear.com

Post reply on HN
Print view View original

71–80 of 259 posts

Re: The Tech Stack of a One-Man SaaS

#71

Post by armatav »

tensor wrote: post #66
fxtentacle wrote: post #43

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

This man knows the way.

I use this stack and I'm pretty sure I could pump out any SaaS business in about two weeks with it. Host on Heroku, use whatever analytics system you want.

Re: The Tech Stack of a One-Man SaaS

#72

Post by joshmn »

amzans wrote: post #63
joshmn wrote: 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 featu…

That's really great, happy to hear.

I didn't mean to refute what you shared. In fact I was reinforcing some of your points. Doing things the cheap way is arguably the best way. Learning new tech while building is good, but I wouldn't recommend new tech to build a SaaS.

My concern was copycats. Some starters reading your post may have this feeling that "because Panelbear did it with Clickhouse and Kubernetes and Django, that's the only way to do it." What it really should read is "because Panelbear used what he knew best, he was able to focus on getting customers; that's the only way to do it."

Re: The Tech Stack of a One-Man SaaS

#74

Post by hansvm »

jrochkind1 wrote: post #34
hansvm wrote: 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…

The "most of your response time is spent waiting on the DB" assumption might not hold for your app. Even if you actively push work to the DB to reduce network bandwidth or something, your workload might fundamentally be comprised of small, easy-to-optimize units of work that the DB handles without any issues.

That said, hundreds of milliseconds sounds slow by an order of magnitude or more for html rendering, even if all the work is done in a batteries-included framework for a dynamic language, and it doesn't jive with my Python experience at all. Do you mind me asking what kinds of tasks are taking that much time?

Re: The Tech Stack of a One-Man SaaS

#75

Post by Axsuul »

eric_b wrote: 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…

That's not to say you shouldn't use Kubernetes as a solo founder eventually. Kubernetes does a lot of the devops heavy lifting for you making your job as a solo founder much easier.

Re: The Tech Stack of a One-Man SaaS

#76

Post by lambda_obrien »

dyeje wrote: post #42
jrochkind1 wrote: post #25

Earlier quoted context omitted.

I've been spending some time looking at moving to heroku, but having trouble figuring out how to use it for a real production for deploy for "only" a couple hundred dollars a month. Is that what you're doing? "Standard" dynos and just a few of them are working for you, I assume, for that budget? In my tests, with a Rails app, "standard" dynos are looking surprisingly slow, possibly unacceptably so. Very curious to he…

Checkout Hatchbox.io, just started using it myself. You basically pay a flat monthly rate for their Heroku-esque management service and then pay for the servers on your provider of choice separately (e.g. DO, AWS, etc).

I've been looking for something between Heroku (too expensive, too many features) and Dokkku (too much hassle, I have to maintain my own security and patches) and this looks like exactly the thing I wanted, except it looks like it's only for Ruby? I use a combination of Python, Elixir, and Haskell, so I'd love it if they did support other langs.

Re: The Tech Stack of a One-Man SaaS

#77

Post by ramraj07 »

jturpin wrote: post #57
eric_b wrote: 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 peop…

No it's not, assuming your database sits outside k8s there's absolutely nothing that needs to be fit inside k8s, a simple machine running docker if needed is more than sufficient.

K8s is such a huge mental overhead that if it's not already naturally in your head because you've had extensive experience (or apparently born geniuses) no one with limited tech budget should ever do this.

Re: The Tech Stack of a One-Man SaaS

#78

Post by BobbyJo »

eric_b wrote: 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…

Kubernetes honestly isn't that complicated. It's complexity really only scales with the complexity of the system you're running on it. If you're just bringing up a database and a backend on top of it, it's honestly very simple to get running on a single linux box using something like microk8s. And, as a benefit, you can move everything over to EKS or GKE in like a few hours max, if you ever need to scale.

Re: The Tech Stack of a One-Man SaaS

#80

Post by akiselev »

throwaway894345 wrote: post #36
eric_b wrote: 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…

There may be a rare exception here or there where network effects or some other unique market need require a startup to treat their infrastructure as cattle, but otherwise it's absolutely true. Running `git init --bare` on a server, setting up some remote origins, slapping some bash scripts into the git hooks folder, some .service files for systemd, and then running `git push origin dbhost && git push origin apihost && git push origin ...` is a hell of a lot simpler than even getting a toy version of kubernetes up and running. For the developer with average linux skills, it's probably even easier than figuring out which cloud orchestration monstrosity to choose. Throw in Github actions and baby, you've got a stew going!

Maybe I'm misunderstanding the whole "pets vs cattle" thing but you don't need to lose repeatability or give on process altogether; it's a false dichotomy. Just don't dive headfirst into the massive complexity that is "scalable" devops - you can still use terraform or docker compose or whatever to deploy your application and provide repeatable development/staging/test infrastructure.

Post reply on HN