How would you handle a requirement that is technically feasible but would create significant long-term maintenance burden?

1. Make the cost visible and specific rather than describing it as “technical debt,” which means nothing to most business stakeholders.
2. Translate it into business language: the additional effort for every future change in that area, the increased regression testing scope, the reduced flexibility for later requirements, and the risk if the person who built it leaves.
3. Work with the architect to prepare at least one alternative that meets the same business need with lower ongoing cost, so the conversation is a comparison rather than a refusal.
4. Present the choice to the accountable decision-maker with both options costed over a realistic horizon, not just the initial build.
5. If the business chooses the higher-maintenance option for a valid reason — often time pressure — I document the decision, the accepted risk, and any agreed remediation, and add the remediation to the backlog so it is not silently forgotten.