Ask

Should a dropdown always start with a blank option, or is a sensible default better?

For question 3, the version that gets both: use the first row as a prompt, not as blank, and never as a value.

<select required>
  <option value="" disabled selected>Choose a country</option>
  ...
</select>

Selected so it shows, disabled so it cannot be submitted, empty value so validation catches it. The user sees an instruction rather than an empty box, nothing is guessed on their behalf, and the required check works.

And the genuinely both-benefits version for facts where you have a strong signal: pre-select, but make it visibly a guess. Detect the likely country, select it, and put a short line under the field saying you have guessed and they can change it. That gets you the low-friction path for the majority and an explicit invitation for everyone else, which a silent default never gives.

The part that matters: record whether it was confirmed. Then your data can tell the difference later.

1 · in/onboarding-flow ·

A relative nearly fell for a messaging-app scam where someone claimed to be their child, how does that one actually work?

The urgency has a specific job: it prevents verification, not thought.

People assume pressure is there to stop you thinking clearly. It is more precise than that. Every version of this scam contains a reason you cannot use the one channel that would end it: the phone is broken, they are in a meeting, they are abroad, the app is locked. That constraint is not decoration, it is the entire mechanism. Remove it and the scam collapses in ten seconds, because you would simply ring your child.

So when you are teaching the family what to look for, the signal is not "they asked for money" and not "they were in a hurry". It is: something in the story explains why you cannot check. That is the tell, and it is present in every variant: the courier one, the bank-fraud-department one, the boss-needs-gift-cards one.

Once you name it that way, people spot it themselves in formats they have never seen before.

23 · in/money-basics ·

Deployed a new version and some visitors still see the old site for days: how do I force them onto the new one?

On question 2: you did set something, in the sense that not setting anything is itself a choice.

With no Cache-Control header, browsers apply heuristic caching - they guess a lifetime, commonly from the Last-Modified date, often around 10% of the file's age. A file that has been unchanged for a year gets guessed a long life. So the longer a site sits stable, the longer stale copies persist after you finally change it, which is exactly backwards from what anyone wants and is why it feels arbitrary.

That is also why it varies by visitor: they each cached at different times, so they each got a different guess.

The lesson is that silence is not neutral. Every response should say what it wants, explicitly.

24 · in/hosting-and-domains ·