A developer platform, built end to end.

For nine years I helped run a developer platform at Square. From the outside a platform looks like the API. From the inside, it's everything around the API — the parts developers only notice when they break: how you authenticate, how you deliver events, how you rate-limit and log, how the SDKs feel, how good the docs are, and whether the dashboard makes any of it legible.

I wanted to prove I could still build that entire surface myself, end to end — not a toy endpoint, but the full platform machine. So I picked a credible, demanding example domain (a DeFi-yield API wrapping protocols like Morpho and Aave) and built the platform around it. It's explicitly a prototype: not a company, and no real funds move.

The in-product audience is the third-party developer integrating a yield API: sign up, create an application, generate an API key, call the API, subscribe to webhooks, watch the logs, reach for an SDK or the docs when stuck.

The real audience is anyone evaluating whether I understand developer platforms at the level of craft — the same public APIs, SDKs, OAuth, webhooks, dashboard, and docs I helped ship at Square, this time rebuilt solo so the judgment shows up in the details.

The developer journey

• Sign up & sign in — account creation and an OAuth 2.0-style password grant that issues a short-lived JWT (15 min) plus a rotating refresh token (30 days).
• Create an application & API key — long-lived application-scoped tokens managed from a Square-style dashboard.
• Call the API — a live curl example on the homepage and a "run this request" button in the quickstart, hitting the real API.
• Subscribe to webhooks — register endpoints, send a test event, and debug through an embedded delivery portal.
• Observe — a request-logs view with stats, filters, and pagination.
• Integrate — embeddable SDK components and developer docs modeled on the best in the category.

A Cloudflare Workers frontend serves the marketing site, docs, and dashboard; a Kotlin/Ktor API on Railway handles auth, rate limiting, logging, the yield endpoints, and webhook registration; PostgreSQL stores users, applications, tokens, and request logs. Event delivery is handled by Svix, and the yield data is abstracted over Morpho and Aave.

The platform primitives, done properly

• OAuth-style token lifecycle — JWT access tokens, HMAC-hashed refresh tokens with rotation on use, silent refresh in the browser ~2 min before expiry, and dual auth (JWT for the dashboard, API keys for the API).
• Signed webhooks with retries — Svix-managed delivery with event types like deposit.completed and rate.changed, exponential-backoff retries, signature verification, and a debug portal.
• Rate limiting — a per-endpoint sliding window keyed by IP or API client, strict limits on auth routes, and standard X-RateLimit-* / Retry-After headers.
• Observability — async request logging with a 7-day retention job and a dashboard with stats and filters.
• Docs at platform quality — Stripe/Square-inspired static docs with a sidebar, per-endpoint reference pages, a sandbox/production environment switcher, and a live "try it" button.

Honest scope: the SDK story is two layers — three real TypeScript embeddable components with iframe playgrounds, plus illustrative client samples (Node, Python, Ruby implemented today of six advertised). These are hand-built samples and components, not auto-generated client libraries — and the case study says so, because overstating the platform would defeat the point of building it.