Input validation is product design

Input validation is where the product says what it believes.

It is easy to treat validation as defensive plumbing. Check the type, trim the string, reject nonsense, move on. That is only half the story.

Validation decides what counts as a real name, a valid slug, a finished date, an allowed file, or an intermediate state that is still okay while the user is typing. A form can accept 0 as a number but reject 0 as a title. A filename can allow spaces but reject path traversal. A date can be valid in the browser and invalid for the business rule because the booking window is closed.

That means the product should be able to explain the rule in plain language. If the rule is hard to explain, the product probably does not believe it clearly enough yet.

A concrete example helps. Suppose a workspace only allows project slugs that are lowercase, hyphenated, and unique within the org. The validation layer should reject New Project, new_project, and new-project if that slug already exists. The UI should show the rule before submission, and the server should enforce the same rule after submission. If those two layers disagree, the product is telling two different stories.

I care most about the server boundary because that is where the system stops pretending input is only a UI concern. The validation rule is the product’s opinion about reality. The code should say it out loud.

That means validation should return something a client can work with. Not just 400 bad request, but “slug already taken” or “file type must be PDF” or “date must be in the next 30 days.” The user should be able to fix the input without reading the source code.