API development

## what this is

backend APIs built to be consumed by real clients — a web app, a mobile app, a third-party integration, or all three. the contract is explicit from day one, not discovered by the client developer by poking at network tab responses.

## why it matters

an API is the thing you can't easily change once people are building against it. rename a field, remove an endpoint, change how pagination works — now you're coordinating deploys across every consumer. most of that pain is avoidable if the design decisions happen before the schema does, not after.

## how I work

• spec before code. I write out the resource structure, request shapes, and response formats before a single handler gets built. the hard calls — naming, nesting, pagination, error codes — surface as cheap text edits instead of breaking changes.
• zod all the way through. request validation at the boundary, typed responses out the other end. if something unexpected comes in, it fails loudly at the edge, not silently in the middle of a handler.
• thin route handlers. logic lives in a service layer, not in 150-line route files. when a route needs to do something new, it calls a function rather than growing.
• auth isn't the last sprint. JWT or session auth and role-based access go in before the first protected endpoint, not after the feature is "done."

## stack

next.js API routes or hono for standalone services, drizzle for the database layer, zod for validation, postgresql, deployed on vercel or railway.

## what you get

• an openapi spec or equivalent your team can reference without reading the source
• typed client utilities if the consumer shares the codebase
• auth and rate limiting in place before anything ships
• a migration path if there's an existing API that's gotten messy over time

## get in touch

tell me what the API needs to serve and what's consuming it. if there's already one that's growing in the wrong direction, bring that too — I'll tell you what's actually worth keeping.