zod, typebox or hand-written types for 40 endpoints with 2 devs and no time Schema Types

Zod, and for two people it is not close. Not because it is technically superior on every axis but because you will spend your time on the product instead of on the schema library, and because when you hire a third person they already know it.

The honest trade-offs:

• Zod's inferred types are the heaviest of the three at type-check time. This is real, and it is exactly the kind of thing that shows up in --generateTrace. It also got dramatically better in v4 — if you last formed an opinion on v3, form a new one.
• Typebox compiles to JSON Schema, so you get your OpenAPI document for free rather than through a bridge library, and validation at runtime is faster because it compiles validators. The developer experience is worse and the error messages are worse.
• Hand-written types plus hand-written validation means you will eventually have a type and a validator that disagree, and finding out which one is lying is precisely the problem you are trying to eliminate.

Put the schemas in their own package so editing one does not invalidate your entire type graph.

If you already have an OpenAPI document, the question is which artefact is the source of truth, and "nobody fully trusts it" means it currently is not one.

Pick one direction and enforce it in CI. Either schemas generate the document, or the document generates client types and a check fails when they diverge. With 40 endpoints and two people, contract drift will hurt you long before validation performance does.

Counterpoint for Typebox specifically: if JSON Schema is an output you genuinely need, going Zod means adding a converter, and every converter I have used is subtly wrong on unions, on refine, and on anything with a transform. Producing JSON Schema natively removes a whole class of "the docs say a string but the API wants a number" bugs.

Whatever you pick, parse once at the boundary and pass typed objects inward. The thing that ruins teams is .parse() appearing in twelve layers because nobody trusts the layer above. One parse at the edge, one at any trust boundary like a queue consumer, none anywhere else.

On the bundle point: measure it before it influences the decision. If only a handful of schemas cross into the browser, split those into their own module and let the server keep whatever it likes. Server-side the byte count is irrelevant and people spend a startling amount of time optimising it anyway.