Live data from Hacker News

The Tech Stack of a One-Man SaaS

panelbear.com

131–140 of 259 posts

Re: The Tech Stack of a One-Man SaaS

#131
post #74

Earlier quoted context omitted.

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…

In this app, mostly lots and lots of thumbnails. It may be some unoptimized code.

But rather than get into the details of my app, and parts that need optimization (whether in my local code or in Rails or in ruby), I'm more curious about the overall concept.

Are you sure that most of your web app's time is spent waiting on the DB? My suspicion has become that this is conventional wisdom that is not actually true of most apps anymore. But I could be wrong. Or I could be right only for Rails and not python because Rails is slower than typical python, or something. I am curious to find out.

Re: The Tech Stack of a One-Man SaaS

#132
If I were to attempt a one liner for the key takeaway from this, it'd be "use frameworks as much as possible, use managed services as much as possible".

It's a position I couldn't agree with more. It might be one of those mistakes you can only truly learn from by making it yourself, but honestly, while DIY is awesome for learning its only place in a business is at the core of what your business value is.

One way I think about it is anything DIY is surface area for either innovation, or mistakes. To mitigate the risk of making mistakes doing things DIY you'd better do it only in areas where innovation could actually benefit your core business value and give you magnified upside. If you innovate outside these areas, I guess it's nice, but you've taken the risk of mistakes for no significant upside. Not to mention a whole load of work invested.

Re: The Tech Stack of a One-Man SaaS

#133
A lot of people here are recommending stacks that have worked for them, or cautioning against over-engineered stacks that didn't. All of that is useful, but I'd boil a lot of this down to one simple axiom:

If you're a professional engineer and you're starting a tech side project with the goal of shipping - use what you know.

I do a lot of work with node, cloudfront, s3, and React for my day job. All of my side projects are built on node, cloudfront, s3, and React. This works well for me because my goal with side projects right now is to be productive, not to learn new tech.

An important clarification is that I use the tech that I use in my day-to-day, not what my company uses. Just because I have coworkers who know kubernetes back-to-front doesn't mean I do!

Also, there's nothing wrong with doing side projects with totally crazy/new tech stacks as a way to explore and learn new tech. I just think it's good to be really intentional with whether the goals of a project are educational/process-oriented or results-oriented.

Re: The Tech Stack of a One-Man SaaS

#134

Earlier quoted context omitted.

> 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. That is an issue a disciplined one-man operation won't have since (generally) they have a Dev and a Prod environment, the changes would be made in Dev first then duplicated in Prod. If you have 2+ developers, you have environment drift like you…

What happens to the disciplined single dev when their EC2 instance falls over in either environment? How do you get things back in sync without code to automatically stand things up in the right state? And if you're going through the work of writing/maintaining that code, are you saving anything over using Kubernetes (consider out of the box, Kubernetes gives you logging, ssh, process management, service discovery, e…

Not everyone uses EC2 which is prone to fall over.

And the disciplined single dev documents their changes. That is why it works in a 1 man shop but not at scale, there is always someone who is unreliable once the group gets large enough.

Re: The Tech Stack of a One-Man SaaS

#135
post #28

Earlier quoted context omitted.

I agree with you. I wouldn't blindly recommend my stack to everyone, one could argue it's probably even overkill for my SaaS project right now. At this scale I could get away with a couple of $20/mo instances, and call it a day. However, it just made sense for me due to the simplified operations, and re-using most of the learnings from my full-time job. It has enabled me to move faster in shipping customer-facing fea…

> However, it just made sense for me due to the simplified operations, and re-using most of the learnings from my full-time job. It has enabled me to move faster in shipping customer-facing features. As someone who is mostly in the same boat as you, you have got a strong point in terms of favouring tricks you know best. The amount of code I have had to throwaway made me not want to invest in things that require lots…

Hey that's great! I think everyone should do what works for them.

Using a tool "just because" it worked for others, seems to be what often drives many decisions in this industry. For example, would you go for the 2,200+ microservice architecture from Uber[1] just because they say it solved all their problems? They probably have their reasons, and they are unlikely to be the same as everyone else.

I know my stack as a solo founder is unconventional, but it's what has worked best for me. And I'm happy with my choice.

If serverless does the trick for you, then focus on that, and keep building the features that your customers actually care about.

[1] https://eng.uber.com/microservice-architecture

Re: The Tech Stack of a One-Man SaaS

#136
How did you land on another analytics SaaS product? I think like every dev I have always dreamed of starting my own thing, but never had the time/energy to compete with existing spaces, and couldn't think of any new markets create. It just seems crazy to me when someone is like: 'oh I am gonna make a tool for people to manage their finances' when 1000 exist, but then they build it and achieve some level of success.

Re: The Tech Stack of a One-Man SaaS

#138
post #28
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 agree with you. I wouldn't blindly recommend my stack to everyone, one could argue it's probably even overkill for my SaaS project right now. At this scale I could get away with a couple of $20/mo instances, and call it a day. However, it just made sense for me due to the simplified operations, and re-using most of the learnings from my full-time job. It has enabled me to move faster in shipping customer-facing fea…

It is more complex than what I'm looking at right now, but I still appreciate the read as it helps me think about some things I can do now to be better prepared for a more scalable environment later. Thanks. Oh, and I had one (serious, but off topic) question... what are you using to brew your fresh cup of coffee?

Re: The Tech Stack of a One-Man SaaS

#139
First of all, thank you all!

Just the discussion on this post alone, is a goldmine for anyone trying to figure out what worked, and what not for others. This is why I love HN.

To clarify a point about my article, I think everyone should do what works for them. Just because my unconventional stack for a solo founder works great for me, doesn't mean it will do the same for you.

Your mileage may vary, and it all comes down to tradeoffs.

Also, I'm sorry if I haven't been able to reply to each question, this post got way more attention than what I expected.

But I'm happy to answer specific questions, feel free to ping me on Twitter: https://twitter.com/anthonynsimon

Cheers!

Post reply on HN