Zod is usually introduced as a validation library. That is true, but the more useful idea is boundary definition.
A TypeScript type only helps after data is already inside the program. Zod helps at the edge, where data arrives from a form, API request, environment variable, import file, or AI tool call.
const ImportRowSchema = z.object({
name: z.string().trim().min(1),
quantity: z.coerce.number().int().positive(),
});This schema validates, but it also documents what the boundary expects. The trim and coercion are small normalization decisions. They should be intentional because they change what the product accepts.
I like schemas most when they are close to the boundary they protect. A form schema should describe the form input. An API schema should describe the public request. A database model should not automatically become the external contract.
That separation matters. The database may have fields the user should not send. The API may accept a simpler shape than the internal model. A form may represent numbers as strings before parsing. Reusing one schema everywhere can look efficient while hiding different responsibilities.
Zod also helps with consistent error handling. If several routes parse input in the same way, the app can return field errors in a predictable shape.
{
"fields": {
"quantity": "Quantity must be a positive number."
}
}The exact format is less important than consistency. Users and API clients should not have to learn a new error shape for every endpoint.
The trade-off is that schemas can become too clever. Large transforms, hidden defaults, and complex refinements can make it hard to see what is accepted. When a schema starts to contain real product decisions, I usually move that decision into a service and keep the schema focused on the boundary.
I would use Zod for:
- form input
- API request bodies
- query parameters
- imported rows
- environment variables
- AI tool arguments
I would avoid treating Zod as the whole domain model. It is excellent at the edge. The rest of the app still needs clear services, permissions, and persistence rules.
The practical test is whether the schema makes the boundary easier to review. If it does, it is helping. If it hides the workflow behind a pile of transformations, it is doing too much.