Hmmm, is it really that crappy? It’s supporting 20 million USD of revenue with just 3 developers. Yes, ok, I buy that the code is terrible and makes you feel ill whenever you have to look at it.
The comments are heartening to read. In general people recommend against a major re-write. They recommend writing tests to confirm how certain behaviour works and then refactoring piece by piece. It’s along the lines of https://martinfowler.com/bliki/StranglerFigApplication.html
If you read the HN thread and still think that the best approach is to start again from scratch, I refer you to https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/
And if you still think a clean slate is the way to go, I give you this story: In 1972 the UK changed from using pounds, shillings and pence to using decimal currency. In 1995 I was training as a programmer. The teacher told us that 2 of the main 4 banks in the UK still calculated interest payments in pounds, shillings and pence. They had just put a wrapper that converted to/from decimal currency around this legacy code.
If you are dealing with poorly-understood code that you can’t really touch without risking everything falling to pieces, you are definitely not alone. It is fixable, given enough time and money. But it’s very unlikely that it can be fixed in one fresh re-write. Most realistic is to address it piece by piece.
In this vein I did find this comment particularly interesting because it represented a concrete small step that could help start solving the problem:
You need to develop an small app that will handle authentication/authorization. Next time a feature comes you will implement that page in the new stack, the rest of production pages will still run in the old code base .
That’s it.
A concurrent small migration to the new system without changing all the system at once.
Why it works? New systems often fail to encapsulate all the complexity. also two systems, duplicate your workload until you decide to drop new system because of the first statement.
Finally, get stats from nginx and figure out which routes aren’t used in a month, try disabled some and see how much dead routes you can find and clean
https://news.ycombinator.com/item?id=32887439
Will it work? Maybe, maybe not, but this sort of mindset – of looking for specific problems that can be fixed and not getting overwhelmed by the extent of the all the problems in the codebase – is the best way to be addressing this kind of challenge.
Be good, work hard, get lucky 