Case study: 12 client backends, one panel

The problem: a four-person agency maintained ~12 client sites, each with its own WordPress, plugins, updates and 2am pages. Content edits were tickets; handovers were runbooks.

The migration pattern

Each client became an APIForge project: isolated endpoints, keys, files and team. Frontends were rebuilt as static/Next.js sites consuming the gateway: fast, unhackable, CDN-cached. Repeated site types became templates, so a new client starts at 80% done.

Access without fear

Clients got manager accounts: CMS-only, restricted to their own project's content endpoints. The 16-permission model means a client can edit their menu without ever seeing API keys, or another client's data.

Operations

• One upgrade updates every client at once: no per-site plugin roulette.
• Per-project scheduler syncs external feeds (one client's inventory updates nightly from their ERP's JSON).
• Portable ZIP export: when one client insisted on leaving, their entire project (content, files, settings) left with them. That portability is now a sales argument.
• Usage metering feeds tiered retainers: heavy API users moved to a bigger plan with data, not vibes.

The punchline

Maintenance hours fell by roughly two thirds, and the agency now sells "backend included" instead of itemizing hosting, forms, auth and a CMS as separate line items.