A CTO at a mid-sized fintech once told me his team spent three months rebuilding a customer onboarding flow that had been "finished" twice already. Each rebuild happened because the original tool choice locked them into a corner nobody spotted at the start. The third version worked. It also cost roughly triple what the first version should have, if anyone had asked the right question up front.
That question wasn't about budget or timeline. It was about which kind of foundation the team was actually building on, and whether that foundation matched what they'd need six months later.
The decision that gets made too fast
Most engineering teams pick their development approach based on whatever got them results on the last project. If a low-code platform shipped something quickly last quarter, it becomes the default answer this quarter too, regardless of whether the new project has the same shape.
How low-code compares to high-code isn't really a question of which one is better. It's a question of which constraints you're willing to live with. Low-code platforms like Mendix or OutSystems get you a working application fast, with visual builders that let non-specialists contribute meaningfully. The tradeoff shows up later, when you need something the platform wasn't designed to do, and you're stuck either hacking around it or ripping the whole thing out. High-code gives you almost no shortcuts up front but almost no ceiling later. A team that picks low-code for a project that's going to scale into custom integrations and heavy data processing is going to relearn the fintech company's lesson, just on a different calendar.
The teams that get this right ask a blunt question before writing a line of code or configuring a single module: is this project going to stay simple, or is it going to grow teeth? Nobody wants to admit they don't know yet. But guessing wrong here is expensive in a way that's hard to walk back.
Open-world games force the same choice, just earlier
Games like Hogwarts Legacy put players through a version of this same decision within the first hour, and it's worth noticing how deliberately the game does it. Choose your house, and you're not just picking a color scheme. You're choosing which storylines unlock, which characters you'll spend time with, which parts of the castle feel like home. Ravenclaw and Slytherin players are technically playing the same game. They're not having the same experience.
What's interesting is how few players fully understand the weight of that choice on their first playthrough. They pick based on vibes, or nostalgia, or whichever house sounds coolest, the same way a lot of teams pick a dev platform based on whichever one a competitor mentioned in a conference talk. Neither decision is reckless exactly. It's just made with less information than the decision deserves.
The players who research house traits beforehand, who know that Slytherin unlocks a different set of relationships than Gryffindor does, end up with a playthrough that actually matches what they wanted from the game. The others end up enjoying it anyway, mostly, but wondering later what the other path would have looked like. That's a fine outcome in a game. It's a rough one in a six-figure engineering project.
Committing doesn't mean you're stuck forever
Here's where the comparison gets useful instead of just cute. Neither choice, in games or in software, is actually permanent in the way people fear it is. You can respect a character. You can migrate a low-code app's logic into custom code once you understand exactly which parts outgrew the platform. The mistake isn't choosing wrong. The mistake is refusing to notice you chose wrong until the cost of switching has multiplied for a year and a half.
Teams that build in checkpoints, real ones, where someone actually asks "is this still the right tool for what we're building now," catch the mismatch early enough to fix it cheaply. Teams that treat the initial choice as a one-time decision, never revisited, are the ones who end up doing that fintech company's rebuild. Twice.
The house you pick shapes the game. It doesn't have to define it completely, as long as somebody's willing to look up partway through and ask whether the path still fits.
