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

The article wasn't about infrastructure or resilience, it was about technology stacks.

Maybe those other things were there, maybe they weren't but it wasn't about what you should do, just what he did.

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.

Cool concept! Few ideas:

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

Also in “Russian guns” category: https://en.m.wikipedia.org/wiki/Alekhine%27s_gun

We made this Google Sheets plugin to calculate your basic SaaS metrics: New MRR, Expansion, Contraction, Churn, MRR, LTV, ARPU.

Maybe it will be useful to someone who uses Sheets to track their company financials but still would like to calculate the metrics.

Disclaimer: it does send data to our API (we don't store it but still...)

Reach out to us (https://getprobe.io) and we will work with you very hands-on to get to a state where you trust your data :)

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)

[1] https://workspace.google.com/marketplace/app/probe/108508041...

I have a plan to write a short article about specifically this topic at Base. I personally fucked up a ton of things with microservices there :)

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).

I think the article starts out sounding that way --- but reading all the way through, it's about how to DO BETTER if you want to ship more often (the key take aways from the article being: document, iterate/revisit, and be intentional)

Firing perfectionists is a strange signal. If the customers are sufficiently large, you should do everything possible to please them; beyond revenue, they are themselves an asset (sometimes a company is acquired for this only). In many industries it can take years to establish yourself as an approved vendor for a large org, and especially to a large enterprise company, this can be worth more than the underlying business. Not suggesting that’s the case for Base, but if you’re not gunning for an IPO, your exit strategy isn’t going to be one that necessarily resonates with a product or eng team.

Author here. Sorry you didn't like it :)

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".