My signup form validates as you type, is that helpful or is it nagging?

You have identified the exact failure, and it has a well-established answer: do not validate before the input could reasonably be complete.

The email field is the clearest case. Every valid address passes through a long sequence of invalid states on the way to being typed. Showing an error during that sequence is not information, the user knows they have not finished, it is just noise, and worse, it trains people to ignore the error area entirely. By the time you have a real error to show, the red text has become furniture.

The standard pattern that avoids this:

• Validate on blur, when focus leaves the field. That is the earliest moment at which "incomplete" and "wrong" are distinguishable.
• Once a field has shown an error, re-validate on every keystroke. Now live feedback is genuinely helpful, because the user is trying to fix a specific thing and wants to know the instant they have.

That asymmetry is the whole trick. Late on the first error, immediate on every correction.

There is a category of live feedback that is fine while typing, and separating it from validation is what unsticks most of these debates.

Progressive requirement lists - a password field showing which rules are met, ticking them off as you go: work well during typing, because they are framed as progress rather than as failure. Nothing is red, nothing says you are wrong; a list is filling in.

Availability checks - username taken or free, are also fine live, because that information genuinely cannot be known until the user types and it does not correspond to a mistake.

The distinction is whether the message says "you have made an error" or "here is the current state". Live state is helpful, live blame is not. Rewriting your email message from an error into a state indicator would fix most of what you saw without changing the timing at all.

Implementation note that saves a lot of grief: do not clear the error the instant the value becomes technically valid if the field is still focused and the user is mid-edit.

A field can pass through valid states while being edited, deleting the end of an address, for instance - and flickering between error and no-error under the cursor is more distracting than either state alone.

Debounce it, or simply hold the last decision until blur once an error exists. Cheap to implement, and it removes the twitchiness people describe but rarely name.

One thing that gets missed in this debate and matters a lot: live validation is far more disruptive for screen reader users than it looks on screen.

If the error message is in a live region, every keystroke that changes validity announces something. The user is trying to hear what they are typing and instead hears repeated interruptions. What reads as a small red hint visually is a constant interruption aurally.

So the on-blur pattern is not only better UX in the general case, it is substantially better for assistive technology. And when you do show the error, associate it with the field programmatically rather than only placing it nearby: otherwise a user who tabs back into the field is told the field is invalid with no indication of why.