01 Edge compute, AI, databases, and storage on the Cloudflare network

Cloudflare Workers and platform

Cloudflare Workers is our default platform for new application work where edge latency, global distribution, and operational simplicity matter. Workers run on V8 isolates with sub-millisecond cold starts, expose Web Standards APIs (Fetch, Streams, Web Crypto, WebSockets), and deploy through Wrangler with versioned environments and near-instant rollbacks. The same TypeScript code that handles HTTP requests also runs queues, scheduled cron triggers, Durable Objects for stateful coordination, and long-lived WebSocket connections.

The platform extends well beyond the compute layer. Workers AI is a managed inference layer with open-weight models (Llama, Mistral, embedding models, image generation, speech-to-text, vision) running on Cloudflare's GPU fleet, billed per request with no provisioning. D1 is Cloudflare's serverless SQLite database with read replication, migrations as code, and a binding API that calls into the database with no connection pool to manage; it fits the small-to-mid-size relational workloads where Postgres would be overkill. R2 is S3-compatible object storage with zero egress fees, which makes it the right home for static-site hosting, large file uploads, generated artifacts, and any payload that needs to leave the network for downstream consumption. Cloudflare Containers is the newer addition: standard OCI container images run in a managed runtime co-located with Workers, opening up workloads (long-running processes, language runtimes Workers can't host, headless browsers, build agents) that previously needed a separate VPS or Kubernetes cluster.

How we use the platform together: a Worker handles the API surface (routing, auth, business logic), D1 stores the relational data, R2 holds the static and binary assets, Queues smooth out async work, Durable Objects coordinate state across requests, Workers AI serves the inference where a managed open-weight model is the right choice, and Containers run the heavier workloads when a Worker isn't the right shape. The result is a single deployable platform with a single billing surface, sub-millisecond region-to-region failover, and operational ergonomics that beat traditional VPS or Kubernetes setups for the workloads that fit.

Recent work: webforcheap.com, our AI-assisted static-site platform for small businesses, runs entirely on Cloudflare's stack. Workers handle the API, dashboard, and per-site request routing; D1 stores accounts, sites, billing, and affiliate data; R2 hosts every customer site and serves traffic globally; Queues coordinate async build jobs; Durable Objects orchestrate Claude-driven build containers; Workers AI provides managed inference inside the build pipeline; and Cloudflare Containers run the heavier workloads that need a full container runtime. One platform, one bill, one deploy command per worker.

02 Server-rendered React for headless CMS frontends

Next.js

Next.js is our default choice for content-driven applications, modern marketing sites, and headless deployments where Drupal or another CMS provides the content backbone. The framework gives us server-side rendering, static-site generation, and React Server Components in one package, with file-system routing, built-in image optimization, and API routes for the lightweight backend pieces. We typically deploy Next.js applications on Cloudflare or Vercel, with edge caching tuned to the content type.

Common patterns we ship: Drupal-as-headless-CMS with Next.js rendering the front end, commerce frontends backed by a custom catalog API, and content sites where the editorial workflow lives in a CMS but the user-facing experience needs framework-level interactivity.

Recent work: biblicaltraining.org, our 12-year client, runs on a headless Next.js front end with Drupal as the editorial backbone for thousands of hours of theological course content.

03 Custom dashboards, embedded widgets, and SPA modernization

React

We use React directly, without a framework, when a Next.js setup isn't the right shape for the project: embedded widgets that need to integrate into larger host applications, single-page applications with custom build and routing requirements, and component libraries that have to work across multiple deployment targets. The defaults are hooks-era patterns, strict TypeScript, modern testing (Vitest plus Testing Library), and Vite for build tooling.

Plain React is also where most of our refactor and modernization work lands: applications that started as Create React App, jQuery-plus-React hybrids, or class-component codebases that need to come up to current patterns without a full rewrite.

Recent work: a sales dashboard reporting system for rhinonetworks.com, built in React inside their existing application stack to surface live sales data and reporting to their team.

04 Vue 3 migrations and decoupled application UIs

Vue.js

Vue is a progressive JavaScript framework with a different design philosophy from React. The Composition API and single-file components keep template, script, and styles in one file with reactivity managed through composables. We work with Vue on existing Vue codebases and on projects where the engineering team is already invested in the Vue ecosystem.

Typical engagements include Vue 3 migrations from Vue 2, integrating Vue components into existing applications, and shipping new features in Vue codebases that need the same TypeScript-strict, well-tested approach we use for React work.

Recent work: teachwithepi.com (Education Partners International, our 8-year client) is a partially decoupled application where Drupal handles the editorial workflow and partner-management data model while Vue components are embedded for interactive UI surfaces. Drupal renders the page shell and admin tooling; Vue handles the dynamic UI inside it.

05 Blazing fast custom API endpoints on the edge

Hono.js

Hono is a small, fast web framework built on Web Standards. We use it for API endpoints, lightweight backends, and edge workers, particularly on Cloudflare Workers where Hono's size and Fetch-API-based design map directly to the runtime. The same Hono application also runs on Deno, Bun, AWS Lambda, and Node.js with no code changes, so deployment targets stay flexible.

We typically pair Hono with a Next.js or React frontend, with Hono carrying the API surface: authentication, third-party integrations, business logic, webhooks. Built-in middleware (CORS, JWT, request validation) and TypeScript-first design fit the kind of focused API work that runs on Cloudflare Workers and similar edge runtimes.

Recent work: the licensing and package-distribution API for dripyard.com (our sister theming practice), built in Hono on Cloudflare Workers. The API handles license validation, theme package distribution, and customer-facing endpoints, all running at the edge.