Writing
Notes from production work: scoping and pricing MVPs, Cloudflare Workers, queues, databases, and the backend decisions that are expensive to undo.
- How much does it cost to build an MVP in 2026? A line-item breakdownAn MVP's price is hours multiplied by a rate, and the hours come almost entirely from scope. A single-workflow web MVP is a few weeks of senior work; every extra user role, integration or platform adds to it. Fix the scope and the price stops being a guess.
- How to scope an MVP you can launch in two weeksAn MVP ships on time when its scope is one workflow, written down, with a cut list and acceptance criteria agreed before any code. The method below is the one I use before every 14-day build, including the one-page template.
- Stripe webhooks on Cloudflare Workers: signature verification, queues and idempotencyA production Stripe webhook on Cloudflare Workers does four things: verifies the signature against the raw body, acknowledges in milliseconds, hands the work to a queue, and processes each event idempotently. Full TypeScript code below.
- Choosing a database for Cloudflare Workers: D1, Hyperdrive with Postgres, or PlanetScaleUse D1 when your data fits comfortably in SQLite and you want zero connection management. Use Postgres or MySQL behind Hyperdrive when you need a full relational database, existing tooling or data that lives in a region. PlanetScale is a strong managed option for either engine. Here is how I decide.
- Deploying Next.js on Cloudflare Workers with OpenNext: setup, bindings and cachingThe OpenNext Cloudflare adapter runs a standard Next.js app, App Router and Node.js runtime included, on Cloudflare Workers. You add a Wrangler config, an OpenNext config and two scripts, then reach D1, R2 and KV through getCloudflareContext. Here is the setup I use for MVPs.
- Cloudflare Queues in production: retries, dead-letter queues and idempotencyCloudflare Queues delivers at least once, so a production consumer acks each message individually, retries with backoff, sends repeat failures to a dead-letter queue and makes every job idempotent. Here is the setup I use, with code.
- 12 Cloudflare Workers Use Cases That Ship in ProductionThe best Cloudflare Workers use cases are narrow, high-leverage request paths: protect an API, receive a webhook, serve a cacheable read, issue a signed upload, or move slow work to a queue. The mistake is treating Workers as a place to put every backend decision.
- Cloudflare Workers Architecture Checklist (SaaS APIs)A Cloudflare Workers backend ranks in production when every edge responsibility is explicit: routing, validation, auth, caching, queues, storage, database access, observability, and rollback.
- Backend Engineering for Startups: How to Hire WellThe best backend engineering hire is not always the biggest agency or marketplace. For startups, the right choice depends on ownership, architecture judgment, production proof, and how clearly the engineer can reduce backend risk.
- Workers vs Lambda Cost: When the Bill FlipsCloudflare Workers often wins for latency-sensitive edge APIs; AWS Lambda still fits heavy regional compute and deep AWS integrations.
- Elasticsearch to Typesense on Cloudflare WorkersA search migration works when index shape, query paths, sync jobs, and rollback plans are designed before any production cutover.
- Workers, Queues, R2, PlanetScale, Typesense: One BackendA Cloudflare-first backend works when each piece has a narrow job: Workers handle request logic, Queues protect slow work, R2 stores objects, PlanetScale owns transactions, and Typesense serves search.
- RAG pipeline production checklist: what breaks at scaleProduction RAG breaks at ingestion, permissions, evaluation, and observability more often than at prompt writing.
- Building Wakamiapp backend end-to-end: architecture decisions that matteredA complete product backend needs stable domain boundaries, predictable APIs, secure access, and deployment habits that support fast product iteration.