Learn and Be Curious: Building a Process

Situation

As a backend engineer on a product team, I noticed that every sprint, we were manually validating API payloads against our expected schema. This resulted in small inconsistencies, duplicated logic, and production bugs that were completely avoidable.

No one was officially tasked with fixing it — but I was curious if we could automate the whole thing.

Task

My goal was to explore schema validation tools, build a reusable and scalable pipeline for request validation, and integrate it into our CI/CD process — without slowing down the dev workflow.

Action

I spent a weekend researching options like JSON Schema, Yup, and Zod. I tested each in isolation, benchmarked performance, and ultimately chose Zod for its Typescript-native support and dev-friendly syntax.

I created a validation middleware wrapper for our Express routes and wrote a CLI to auto-generate API contracts from the Zod definitions. This ensured:

• ✅ Runtime validation of all incoming payloads
• 📦 Shared types between backend and frontend
• 🚦 Tests could simulate invalid inputs easily

// zod-schema.ts
  import { z } from "zod";
  
  export const UserCreateSchema = z.object({
    name: z.string().min(1),
    email: z.string().email(),
    role: z.enum(["admin", "user"]),
  });
      

Result

We reduced bug reports related to API mismatches by over 70% in two quarters. Onboarding new developers became easier, since they could rely on the schema to understand expected inputs and outputs.

My CLI tool was adopted by 3 other teams. I later gave a tech talk on “Schema-Driven API Design” that became one of the most-watched internal dev sessions that year.

Reflection

• 📚 I didn’t wait to be asked — curiosity drove the innovation.
• 💻 Technical research + small proof-of-concepts helped me make fast decisions.
• 🌱 Learning something deeply → teaching others → multiplying value.
• 💬 Curiosity is contagious — a side project turned into an org-wide improvement.

FAQ