Running legal SaaS on Cloudflare production infrastructure

Problem

NepalIPMS started on Firebase-shaped infrastructure. As the register grew past 130,000 trademark rows and the API surface passed 300 endpoints, latency variance and operational complexity became product problems. Firms in Kathmandu could not depend on a stack that felt fast on demo day but sluggish during Monday morning search load.

Context

Legal SaaS has a narrow downtime tolerance. Renewal season does not pause for migrations. We needed edge-adjacent compute, relational data with migrations, object storage for filings and bulletins, and a deployment model a small team could operate without a dedicated platform engineer.

Constraints

No dedicated platform engineer. Firms cannot pause renewals for a weekend cutover. Data model must survive the move intact. Rollback paths required at every stage.

Architecture

Next.js firm portal. Workers REST API. D1 relational state + FTS5. R2 documents. KV sessions and hot cache. Cron for deadline notifications. Domain model unchanged — company → file → matter → asset.

Implementation

Migration staged, not big-bang. Schema to D1 with 150+ migrations in version control. Documents to R2 with signed access. API routes consolidated with shared auth and KV rate limits. Each stage verified against live firm workflows before the next cutover.

Result

Firms continued daily operations. Search latency stabilized. Ops simplified — no always-on servers to babysit. The stack became part of the product’s reliability story.

What I Learned

Edge infrastructure is a product decision. Migrate in slices aligned to desk workflows. Choose the platform your team can operate at 2am during filing season — not the one that looks best in a slide.