First of all there's literally a paragraph called Infrastructure. Then one of the arguments is how cheap it is.
I don't find it fair to praise your tech-stack for simplicity and being cheap (awesome features btw) and fail to mention resilience. Unless you run a service that can be down 10% of time for example. Not the case here I guess since we talk about SaaS.
Other than already mentioned backups I see no mention of:
* staging environment for development
* at least another baremetal machine for a copy of production and a loadbalancer in front of them, to prevent from 100% downtime in case your machine is down
1. when you hover over puzzles, they could shuffle/rotate a bit, so that there's no easy option to just click puzzles and rotate them appropriately upfront
2. an option to select a group of puzzles and move them, just as you categorize and group puzzles in real life
Perhaps I am a bit biased because I create analytics software fos SaaS businesses.
This is a nice writeup, could be an intro of tech people to business metrics you mention. I also code Ruby so +1 :-) I would be cautious about rolling your own implementation like this though.
1. This is not your core business. Eventually you want to start segmenting things by verticals, geography etc. You will want to visualise them. It takes time, which you want to spend building your product.
2. There are many important details in how you calculate certain metrics. Either you dive into the topic and again waste time, or you start having metrics which are custom, not really comparable with benchmarks or just plain wrong.
Maybe you just spent 1hr on this and that’s ok. Just make sure you spend your time on your product domain, because that’s what’s probably gonna make you happier (unless you pivot into saas metrics world!)
A bit of self promotion, though not opensource. If you store your data in sheets, Probe Sheets plugin [1] calculates basic metrics based on some basic data: customer id, mrr, start and end time of subscription. We do not store the data you send (there is no way I can prove that to you though, but you can always obfuscate it somehow)
I'm far from being a developer perfectionist, I wouldn't spend 10 years in this company if I was one, trust me (btw we fired a lot of them along the way).
The point of the article is not to convince anyone to slow down as much as possible and work on bugs/etc. It's just that at some point (3, 4 years in?) there comes a time that you just have to put more effort into the things I described, otherwise it gets complicated fast.
Obviously there is a tradeoff, my opinion is that this tradeoff wasn't correctly balanced (especially further down).
It's tough to suggest detailed solutions to a problem which is in general very vague. Btw I hope the article shows my appreciation for what the company achieved.
One small insight from Uzi (CEO + founder) when I discussed this with him (after publishing article): Base should've focused on much less features but with greater detail. It somehow confirms my guess that we didn't work on existing features as much as we should, but we "spread too thin".
It's definitely possible organically, but if I can increase the chances of this happening, why not do it?
"Not focusing on promoting" is not an option if you start a product and nobody knows it even exists. You gotta take some actions to reach out to potential customers.
Obviously artificially doing it isn't the way, I guess we misjudged what "artificially" means for PH - that's the point of the blog post as well.
I don't find it fair to praise your tech-stack for simplicity and being cheap (awesome features btw) and fail to mention resilience. Unless you run a service that can be down 10% of time for example. Not the case here I guess since we talk about SaaS.