The operating problem
A contact form is only useful if its submission becomes visible, assignable work. We needed a small-business operations system that kept the original inquiry durable, surfaced it immediately, and carried context through lead review, client conversion, project stages, tasks, notes, and meetings.
The build
KaiBear Ops is a responsive Next.js application backed by Postgres. Website inquiries are first written to private object storage, then sent through a signed, idempotent ingestion endpoint. If that immediate handoff is unavailable, the object remains a durable retry source. Operators can review and audit a lead, change its status, convert it into a client and project, then manage delivery without retyping the original context.
Access is invite-only. Invitations and password resets use expiring single-use tokens; sensitive mutations authenticate against the current database role; and important actions are recorded in an owner-visible activity feed. Outbound website checks vet and pin public IP addresses to reduce server-side request-forgery risk.
Why this is evidence, not a promise
This is our own system, so we can describe the architecture without inventing a client result or publishing someone else’s data. The useful proof is the working pattern: durable intake, explicit state, guarded transitions, recovery paths, and tests around the boundaries where data could be duplicated or lost.
The transferable pattern
The same approach fits service intake, approvals, content production, onboarding, and other workflows currently held together by email and spreadsheets. Start with the smallest end-to-end path, make every state visible, and design the retry before the happy path ships.