> but the time savings now are worth the technical debt that I might face in the future
Oh, man that statement makes me cringe. Have you ever replaced a piece of proprietary technology with a different one before? I promise you, you will consider this decision up front much more closely next time.
Yes. I'm replacing a legacy PHP app with Meteor right now. However, instead of building a huge, monolithic app, I'm replacing sections of it piecemeal with small Meteor apps that use npm modules (or meteor packages) for shared functionality. So if one app doesn't work out, then yes, it'll be more work to replace it with some new fancy future thing, but hopefully it'll have paid for itself by then.
It's easier to rewrite something than it is to produce an MVP that consumers and investors want to buy into. I'm 150% into the anti-monolith approach for serious scale, but meteor is like Rails in the respect that small teams can accomplish rapid prototyping and fast iterations early on.
Most apps that become successful have to be rewritten multiple times as they grow. One of Jeff Dean's rules of thumb [1, p. 11] is that a system will generally need to be completely rewritten every 1-2 orders of magnitude growth.
Yes, this sucks, as anyone who's gone through a rewrite can tell you. But the broader perspective is that this is what software engineers are paid for. If you could just build a system and let it grow with minimal tweaks, the only people the software industry would employ would be technical founders.
Your rewrite doesn't need to be on a completely new platform or language, and depending on the use case you'd still benefit greatly from using some of the original functionality of the current code base to do things until you're in a position to replace them.
In my experience, you often iterate towards a replacement instead of pulling the rug out from the current platform and replacing it with another. This isn't always true, but in the case of CRUD based web apps, it's a lot smoother in my experience.
Agreed, but the first step in a major rewrite that's necessary because the product has outgrown its original purpose is to draw up appropriate system boundaries. These could be in-process libraries, webservices, RPCs, data protocols, database schemas, or whatever, but if they're out-of-process, there's nothing preventing you from using a different language or platform to rewrite that subsystem. You can decide to continue using the original proprietary platform based on whether it's still appropriate for your needs, and you're not locked into it just because all the existing code is in it.
Oh, man that statement makes me cringe. Have you ever replaced a piece of proprietary technology with a different one before? I promise you, you will consider this decision up front much more closely next time.