base62 slugs longer than one digit don't decode back to the same id

Every auto-generated short link's slug is base62.encode(row.id). Redirects still "work" today because GET /<slug> looks up ShortURL.query.filter_by(slug=slug) using the string slug directly, never decoding it back to an id. The real damage shows up anywhere the id needs to be recovered from the slug (a future admin tool, a migration script, a support engineer manually computing "what id does /3d7 correspond to?"), and in the fact that two different ids can currently encode to visually-confusable strings. This is the kind of bug that looks fine in a demo (single-digit ids: 0-61) and quietly produces garbage the moment the id counter crosses 62 -- exactly when a project has enough traffic to matter.

base62.encode() builds the base-62 digits of n one at a time using divmod, appending each digit to a list as it goes -- a loop that naturally produces digits least-significant first. The final line joins that list directly, without reversing it first.

1. python3 -c "from app.utils import base62; print(base62.encode(62))" # prints '01', should be '10'
2. python3 -c "from app.utils import base62; print(base62.decode(base62.encode(1000)))" # not 1000

divmod(n, BASE) on each loop iteration yields the digit representing the current least-significant place of what is left of n. Converting an integer to a positional-notation string always requires reversing that sequence before joining, because "most significant digit first" is the opposite order from "the order in which division peels digits off." This is the single most common way to get base-N conversion wrong.

Look at the loop in encode() and compare the order digits are appended in against the order they need to appear in the final string. You do not need to change the loop itself -- only how the collected digits are assembled into the return value.