How do you balance shipping quickly against writing code that will be maintainable?

The honest answer is that it depends on how reversible the decision is, and saying so directly is stronger than claiming you always do both.

Where speed is fine: anything cheap to change later — internal tooling, a feature behind a flag, a first version of an endpoint whose shape nobody has agreed yet. Here the risk of over-designing for requirements that never arrive is higher than the risk of rework.

Where it is not: decisions that are expensive to reverse. Database schemas, public API contracts, message formats, and anything that touches money or authentication. These deserve the extra day.

How to keep the trade-off visible:

• Write the shortcut down where it will be found — a TODO with a ticket number, not a comment nobody reads.
• Keep tests on the parts that are hard to verify by hand, even when you are moving fast.
• Raise it as a cost, not a complaint: "we can ship Thursday, and it will cost us about two days in January."