4 ms·

As a solo founder of a SaaS, I think it is doable solo. But hard. Regardless, I totally get what you’re saying -- I look up to Mike/Sidekiq too, always wanted t

by ezekg 4y ago

As a solo founder of a SaaS, I think it is doable solo. But hard. Regardless, I totally get what you’re saying -- I look up to Mike/Sidekiq too, always wanted to do a product like that -- and I’m actually in the process of making my SaaS self-hosted/on-prem as well for the same reasons (among others). Scaling a SaaS does seem harder than scaling on-prem (currently doing the former so biased, ofc). So I guess what I’m getting at here is: have you thought about both? SaaS with on-prem options?

moomoo11 4y ago
I don’t know enough so just asking. Wouldn’t on prem actually be more difficult and need more support and consultants because every customer could be on a previous version, not following migration / update guides, and complaining when things don’t work? Whereas with a SaaS you could ship code and in minutes or seconds it’s live and things are good.
- ezekg 4y ago
  Granted, I have little experience with on-prem at this point in time. But I imagine it’s a trade-off -- with SaaS, you have to constantly scale technically to support more and more customers, while on-prem would be more focused on scaling support. And I don’t necessarily think you need to support all versions. You can have a defined support policy and EOL versions just like any open source project. I.e. they’re out of luck if they’re running an EOL version, in terms of support. It would also depend on how you handle upgrades themselves, from the distribution DX to how you design the software itself. For example, my SaaS is an API, so I’m very much used to having a versioning strategy that never introduces breaking changes (I’ve written more on that here [0]). So I guess it depends. I don’t necessarily see it being more difficult. Challenging, absolutely, but in a different yet same kind of way. But I guess time will tell once I cross that chasm. [0]: https://keygen.sh/blog/breaking-things-without-breaking-things/ https://keygen.sh/blog/breaking-things-without-breaking-thin...
  - moomoo11 4y ago
    Good luck ! Nice blog and company

by ezekg 4y ago

moomoo11 4y ago

I don’t know enough so just asking. Wouldn’t on prem actually be more difficult and need more support and consultants because every customer could be on a previous version, not following migration / update guides, and complaining when things don’t work? Whereas with a SaaS you could ship code and in minutes or seconds it’s live and things are good.

ezekg 4y ago
Granted, I have little experience with on-prem at this point in time. But I imagine it’s a trade-off -- with SaaS, you have to constantly scale technically to support more and more customers, while on-prem would be more focused on scaling support. And I don’t necessarily think you need to support all versions. You can have a defined support policy and EOL versions just like any open source project. I.e. they’re out of luck if they’re running an EOL version, in terms of support. It would also depend on how you handle upgrades themselves, from the distribution DX to how you design the software itself. For example, my SaaS is an API, so I’m very much used to having a versioning strategy that never introduces breaking changes (I’ve written more on that here [0]). So I guess it depends. I don’t necessarily see it being more difficult. Challenging, absolutely, but in a different yet same kind of way. But I guess time will tell once I cross that chasm. [0]: https://keygen.sh/blog/breaking-things-without-breaking-things/ https://keygen.sh/blog/breaking-things-without-breaking-thin...
- moomoo11 4y ago
  Good luck ! Nice blog and company