Contract-driven development clicked for me when I started building an API client tool — once you define the contract first, testing becomes so much cleaner because you know exactly what shape the response should be.
On your question about whether it gets complicated in real projects — the honest answer is the contract discipline pays off most when you have multiple consumers of the same API (frontend, mobile, third parties). For solo projects it can feel like overhead at first. But the auto-generated docs alone are worth it — I've spent way too long reading outdated documentation for APIs that didn't match what was actually being returned.
tRPC + Zod is a solid combo. The type safety flowing end-to-end is the part that actually changes how you debug.
Contract-driven development clicked for me when I started building an API client tool — once you define the contract first, testing becomes so much cleaner because you know exactly what shape the response should be.
On your question about whether it gets complicated in real projects — the honest answer is the contract discipline pays off most when you have multiple consumers of the same API (frontend, mobile, third parties). For solo projects it can feel like overhead at first. But the auto-generated docs alone are worth it — I've spent way too long reading outdated documentation for APIs that didn't match what was actually being returned.
tRPC + Zod is a solid combo. The type safety flowing end-to-end is the part that actually changes how you debug.
yeah this actually makes sense now 😅
i was thinking it might be too much for small projects
but what you said about multiple consumers is true
like if same api is used by frontend + mobile
then having a clear contract from start sounds really helpful
also +1 on outdated docs 😂
faced this many times… docs say something else, api returns something else
tRPC + zod combo looks interesting mainly because of type safety
feels like it can reduce silly bugs
Using it in my current project 👍