IMO, this is a terrible idea.
So I've got my architecture, now what? Skype the lead Ukranian dev and ask if they can use [shiny new hotness] instead of Rails? The answer will of course be, yes. And they will build it, for maybe 30% more. In addition to all the corners they usually cut because I'm uber cost conscious, they'll cut a bunch more because they're just learning the idioms and magical parts of this newer "future proof" stack.
Technical debt and scaling headaches are wonderful problems that most startups never ever come close to having. The fact that Twitter dumped Rails after it's jillionth user is utterly meaningless to a seed stage startup. Indeed studies have shown that worrying about future problems like robust architecture early on can positively prevent you from ever climbing out of the the crib.
If I'm a non-technical founder one assumption I must make is that my product idea is mostly wrong. That means our product must change frequently, drastically and quickly. It means I need a full time technical leader who knows something about how product-market fit is found. I need someone who loves me enough (has a big stake in the upside of the company and not so much resume building or fees) deciding which corners to cut and which to never cut. A less smart or less aligned implementer will yield you a bigger pile of technical debt even if they start with a "prefect" architecture. IMO, architecture emerges from a long series of smart decisions by smart people with the right incentives. It's a mistake to see it as a discreet task.
Another point is that, the "future proof" technology isn't. Our craft always goes down blind allies and follows cargo cults. For example, it turns out many problems thought to be no-SQL-shaped turn out to be more relational-shaped. How many single-page apps today are horribly over-engineered? It's devilishly hard to know which path to start down on day one, so you're best to expect to switch paths probably more than once.