There is nothing wrong with a shortcut. There is a great deal wrong with a shortcut nobody wrote down, because the person who has to pay it back is rarely the person who took it.
Two kinds of shortcut
Some shortcuts are contained. Hard-coding a list you will make configurable later touches one file, and the cost of undoing it is the cost of editing that file. Others spread: skipping authentication “for now”, or storing dates as strings, or letting one service reach directly into another's database. Those get built on. By the time anyone wants to fix them, the fix is not a change — it is a migration.
The distinction is not how fast the shortcut was. It is how many future decisions depend on it.
Write the loan down
The cheapest thing you can do at the moment of the shortcut is record it: what you did, what you would have done instead, and what makes it worth revisiting. Six months later that note is the difference between an afternoon and a fortnight, because the expensive part of paying down a shortcut is almost never the code. It is reconstructing why the code is like that.
The MVP that is actually a product
The most expensive version of this is the prototype that ships. It was built to answer a question, so it has no tests, no error handling and no thought about the tenth user — and then it works, so it stays. Nobody decides to run it in production; it simply never gets replaced.
If a prototype might survive contact with real users, say so before you write it. That one sentence changes what you build, and it is much cheaper than the rewrite you would otherwise be having this conversation about in two years.