Live data from Hacker News

The Tech Stack of a One-Man SaaS

panelbear.com

201–210 of 259 posts

Re: The Tech Stack of a One-Man SaaS

#201

Earlier quoted context omitted.

Not sure what 'containerize' means in this context, but adding a Dockerfile, building the image and changing your box to use docker should definitely not reduce velocity or increase deploy time to half an hour...

it's never that simple. With docker you have to worry about how containers talk to each other. Which at a bare minimum means exposing ports and adding a network layer. Suddenly you find yourself in the weeds with docker-compose and debating whether or not it's actually suitable for a production environment, when they recommend using swarm instead. Then you find out swarm is on shaky ground and now you're hearing abou…

There's a smell if containers are forcing you to radically change your ops strategy. Networking between boxes doesn't change, networking between processes on the same boxes is slightly more complicated but you can always fallback to host if really needed. None of that pushes you to use kube / swarm, they solve completely different issues.

Re: The Tech Stack of a One-Man SaaS

#202
I think if I did a saas I’d do django on heroku to get started.

I want the minimal devops/sys admin work possible and have all my effort go towards adding features.

If I’m successful I could cut costs later and switch to something cheaper.

Is that a good strategy?

Re: The Tech Stack of a One-Man SaaS

#203

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…

Something doesn’t make sense here.

Say, you’re a business, and want to set up your own e-commerce site. Whether it makes money immediately or not, is not a concern, as the business will pay for it, and absorb the initial loss. And the development costs to build the site are already in the $50,000+ range.

So with all this upfront expense, why don’t the business just go with EC2?

Unless this is for some silly hobby website of yours, that you have no clue will make any money or not. Then in this case, maybe your suggestion is valid.

Re: The Tech Stack of a One-Man SaaS

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

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, specifically in off-shore markets, so depending on what time you send in a ticket request, you may get someone who doesn't fully read your ticket or comprehend the situation, and just fires back a canned reply.

This usually gets solved if there is enough back-and-forth as they then seem to escalate it properly, but I have noticed that the initial reply to support tickets are not as good as they used to be.

Re: The Tech Stack of a One-Man SaaS

#206

Earlier quoted context omitted.

You didn't seem to get much of a reaction, probably because of your recommendations to go with proven (read: old & boring) tech, but I appreciate it. Front-end churn is real and, coupled with rapidly evolving and ever-abstracting containerization approaches, staying on top of it is a full-time job, best done as an employee.

Thanks! Best done as an employee is spot on.

I use people I employ as my education

I usually assume a role like engineering manager and learn from the teams feedback, challenges and commits

Making money, getting tax deductions and sometimes research credits

Re: The Tech Stack of a One-Man SaaS

#207
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.

Docker means you're maintaining an operating system, watching out for security vulnerabilities, patching software. It's still work, and if you screw it up, you're hosed.

If you're on Heroku or Google App Engine, you deploy your application code. That's it.

Re: The Tech Stack of a One-Man SaaS

#208
post #46

As a one-man team operating a 10+ year old SaaS product, I’ve done two things that have helped keep things sustainable. The frontend continues to be server generated. PJAX style partial page updates is (mostly) dynamic enough. The maintenance burden of operating a JavaScript frontend is too high to justify for a 1-2 person team. The second thing I’ve done is avoid containers. VMs work fine for many types of applicati…

I'm glad you shared this. I've been reading the comments here with much interest but simultaneously also a sense of impostor syndrome, for I've been running my one-man SaaS on generic LAMP since 2005, and aside from adopting jQuery early on, I haven't much touched any other piece of exciting tech that's come out since. My old and boring stack works just fine on the VMs that it runs on, and and continues to support me…

> Of course I'm aware of the cons of programming in PHP versus other languages

PHP has come a long way. With v7 (and soon v8) and with Laravel programming in PHP is not only a delight, but also extremely robust and fast.

For the front-end, jQuery to Vuejs is not a big leap. You can sprinkle it around to test waters and gain confidence. Such a pleasure to work with.

Re: The Tech Stack of a One-Man SaaS

#209

Earlier quoted context omitted.

You didn't seem to get much of a reaction, probably because of your recommendations to go with proven (read: old & boring) tech, but I appreciate it. Front-end churn is real and, coupled with rapidly evolving and ever-abstracting containerization approaches, staying on top of it is a full-time job, best done as an employee.

FWIW, I disagree with GP. I'm more productive in React than in SSR, and I'm much better at code design and architecture with it. React is pretty much old and boring by now. Just build in what you know.

Yeah same here. I did years of generating JS heavy frontends with PHP for Ajax apps. Once I learned to keep all data on the server and functionality on the client I’ve become so much more productive when slapping together an MVP with react (and any backend capable of spinning up a rest, though I prefer python or go at this time.)

Re: The Tech Stack of a One-Man SaaS

#210
post #46

As a one-man team operating a 10+ year old SaaS product, I’ve done two things that have helped keep things sustainable. The frontend continues to be server generated. PJAX style partial page updates is (mostly) dynamic enough. The maintenance burden of operating a JavaScript frontend is too high to justify for a 1-2 person team. The second thing I’ve done is avoid containers. VMs work fine for many types of applicati…

After finally getting a SaaS product off the ground a few months ago, I cannot agree more.

I fell into the shiny object trap so many times before. This time, I stuck to what I know inside and out and jazzed things up where I could. Long live the monolith.

Post reply on HN