The gap in most "type-safe" APIs: the types are shared, but nothing
validates the wire. A malformed response still type-checks and then
crashes at runtime. Close both.

tRPC — inference across the boundary, no codegen
  server/router.ts
    export const appRouter = router({
      getUser: publicProcedure
        .input(z.object({ id: z.string().uuid() }))
        .query(({ input }) => db.user.findUnique({ where: input })),
    })
    export type AppRouter = typeof appRouter   // the only export the client needs

  client.ts
    const user = await trpc.getUser.query({ id })
    //    ^? fully inferred. Rename a server field → client fails to compile.

WHY ZOD ON THE INPUT MATTERS
The .input(z...) isn't decoration — it validates at the boundary AND
infers the type from the same declaration. One source, both guarantees.
Without it you have compile-time safety over runtime lies.

BRANDED TYPES — stop mixing up your ids
  type UserId = string & { readonly __brand: 'UserId' }
  const asUserId = (s: string): UserId => userIdSchema.parse(s) as UserId

  Now getPost(userId) won't compile — a plain string, or a PostId, is
  rejected. This catches the class of bug that end-to-end inference
  alone doesn't: correctly-typed values used in the wrong slot.

DISCRIMINATED UNION for results, not thrown errors
  type Result<T> =
    | { ok: true; data: T }
    | { ok: false; error: 'not_found' | 'forbidden' }
  The client must narrow on .ok before touching .data — the compiler
  makes the error case unignorable instead of a runtime surprise.

THE TSCONFIG LINE PEOPLE FORGET
  "noUncheckedIndexedAccess": true
  Without it, arr[0] is typed as T, not T | undefined, and every
  "type-safe" codebase has this latent hole.

Which layer do you want built out — the router, or the branded-id
boundary?