MyVirtualOps

Small businesses accumulate subscriptions nobody is tracking. The costs are spread across cards and inboxes, the accounts are often in a contractor's name rather than the owner's, and nobody can say what actually stops working if a given service lapses.

One screen that answers the money questions, with every account in the client's own name, on the client's own card, so leaving is always possible.

A marketing site and a separate operations application. The application lists each client's services, separates fixed from variable monthly cost rather than blending them, shows what renews next, records who owns each account, and states the blast radius of each service: what breaks if it lapses.

Fixed and variable costs are never combined into one figure, because a blended number hides the thing the owner needs to see. Status is stamped and dated rather than described as healthy, since a green light on a dead service costs exactly the trust the product exists to build.

Eric designed and built both properties, the marketing site and the operations application, and defined the ownership model the product is sold on. There is no third-party platform doing the interesting part here; the application is the product.

The ownership rule, which is a product constraint before it is a technical one: every account stays in the client's name on the client's card, so the client can leave at any time. That removes the usual lock-in an operations product relies on, and it forces the software to be worth paying for on its own. The design consequence is that fixed and variable cost are never blended into one number and status is stamped with a date rather than shown as a green light, because a stale reassurance is worse than no reassurance.

Results from client deployments are shared with permission on a call.

Deciding what the product refuses to do is most of the design. Once leaving is always possible, every screen has to answer a money question or it does not belong.

• Next.js
• React
• Vercel