Considering a typical HCoL junior dev costs about ~100k/yr, if you can have one junior dev rewrite your entire codebase in a year, you'll breakeven in cost after 2 years. Considering a senior dev costs 2-3x that amount per year, as soon as you have one of those involved for an entire year (odds are, if it's business critical software you will), your breakeven point comes out to just under a decade worst case.

I think that just illustrates how risky rewrites are. Very few companies at that scale can just rewrite everything in that timeframe using that little resources. Many companies don't even have codebases that will survive a decade.

We considered a few options before rewriting it. I've got a draft blog post about the process laying around, but haven't gotten around to getting it over the finish line.

We definitely knew the risk going into it. Fortunately, it only took us 2 months to rewrite it. I think our strategy for the rewrite is directly responsible for the speed at which we rewrote it.

If you have one junior dev rewrite your entire codebase they'll never finish and the quality of the rewrite will be terrible. It's right in the definition of 'junior'.

The fully loaded cost of even the most junior dev in a high cost of living area is going to be well above $100k/year. Gross wages are generally only 1/3 to 1/2 the all-in cost.

Yeah, but junor from HCoL is not the only option, so why would you consider the most expensive one?

Thats all true of course assuming it'll take (<>?) a full year to do.

(Not disagreeing and is somewhat off the article topic to the article but wanted to counter point as engineers love to find reasons to rebuild in new stuff)

So you could also argue for that savings it may not be worth it. 100k is less then 1 engineer in most places (especially including TOTAL hire costs like equipment, office space, benefits, ect).

You can also argue it is much harder to hire golang engineers (or invest time/money into training engineers in go) so that that savings may not be worth it depending on the time it takes to rewrite plus the gamble of failure.

Also you need to ask could those engineers doing the rewrite have been working on up-sell features or other products that could make more money?

Would the investors (especial new growth oriented investors) care more about a increase in margins or a even larger multiple in ARR?