It's tempting to begin an engagement with the stack — the language, the framework, the cloud. These are real decisions, but making them first quietly narrows every decision that follows to whatever the chosen tools do well.
A better order is to understand the problem in enough depth that the technology choices become obvious, or at least constrained by something other than preference.
The right tool for the job, not the trend
Every capable toolset can build almost anything. That's exactly why the choice should be governed by the problem's actual constraints — data, integrations, scale, the team who will maintain it — rather than by what's currently fashionable.
Restraint here is a feature. The most maintainable systems are usually the ones that used the fewest moving parts they could get away with.
Design for the second version
The first version is never the last. Engineering with that in mind — clear boundaries, honest interfaces, room to change — is what keeps today's solution from becoming next year's legacy problem.
