Superfile

With normal file sharing, you lose control the moment someone downloads a copy. Ownership, rights, and access are gone. For the people Superfile was built for (directors, artists, content creators, and anyone responsible for delivering a valuable file), the value isn't only in the file itself. It's in what happens afterward: who has it, how it's used, and whether it stays protected.

Superfile keeps that control. You upload a file, grant access, watch how it's used, adjust permissions, and revoke access whenever you want, all while keeping ownership. My job was to let people charge for access to those files without weakening any of that, and without making the buyer wait to open what they'd just paid for.

Changing how ownership works meant designing around permissions and durable access control. Rather than treating a file as infinitely copyable, Superfile tracks where it came from, verifies who's opening it, and adjusts what each viewer can do. Control flows from the creator into the file, and each viewer gets their own permissions, a little like enterprise access controls applied to creative rights.

That model spans a macOS app, a web platform, secure viewers, payments, permissioning, ownership verification, accounts, and usage tracking. The map below lays out how the pieces relate and where value moves between them, so the system stays legible whether you're an engineer or an investor.

The push to monetize came straight from leadership, and the CEO wanted access to feel immediate: pay, and the file opens. Anything slower would make the purchase feel broken. That constraint didn't loosen security. It just meant the buyer could never be the one left waiting.

So we used Stripe for payments instead of building our own, and the real work wasn't dropping in a checkout form. It was deciding what a successful charge was allowed to mean. The obvious version, unlocking the instant the charge succeeds, was the one we rejected: a charge can succeed and still be wrong, from fraud to a mismatched recipient to a refund seconds later. Access was released only after the payment was confirmed and matched to the right file and the right recipient. To the buyer it still felt immediate; underneath, Superfile, not Stripe, stayed the authority over access.

I led how Stripe's events connected to Superfile's entitlement model, in both design and implementation. The map became a shared contract between design and engineering: it drew who owned what, and separated the states that were technically impossible from the ones we simply chose not to allow.

I mapped how payment, identity, and entitlement had to work together before a file could open, and, just as important, every way that could fail. The model carried the states the system actually needed: denied, paying, confirmed, granted, refunded, revoked, expired, mismatched, and attempted-sharing. Each one had an owner and a defined next step, so design and engineering could agree on what was technically impossible versus what we simply chose not to allow.

The interactive map below is that model: the same contract I documented in Figma and Notion for the team. Follow the primary journey, or open any node for what it does, who owns it, and where a policy was still undecided.

Once a transaction was confirmed, the interface itself needed only a small visible change: an indicator that the buyer could now view the file. The screen update was minor. The transition behind it, from requesting access to holding a verified entitlement, was the substantial work.

Instead of Stripe's default checkout, I designed a custom pay card that lived natively inside Superfile. It captured transaction intent (the intended recipient, the unlock price, and the payment inputs behind a single Pay to unlock action) and nothing more. The authority to grant or keep access was deliberately kept out of the card itself.

The surface is built in layers that separate the intent to pay from the authority to grant access. As you move up the stack, the product takes on more of the decision and the user controls less of the outcome: from basic inputs like card number and cardholder name, through the transaction-intent layer, up to the container that finally releases access.

One big call was whether to build separate payment logic for macOS and web. Going fully native on each was tempting, but over time the two would drift apart in how they handled payments, webhooks, and security. I proposed embedding a lightweight web view inside the macOS app so both platforms ran the same Stripe flow and the same backend logic, leaving fewer places for bugs or security gaps to creep in.

The payment surface stopped at intent; the entitlement carried authority. The clearest way to see the difference is to lay every capability against every actor. What a buyer received was a scoped, revocable right to view, not the owner's standing control, and never anything Stripe could touch.

Complex technology only matters if people get it. Early on, investors were handed technical diagrams. Later, they followed a story instead: the problem, ownership, how it makes money, control, and the market. Making it legible visually, and operable in their own hands, turned out to be the bridge between technical depth and business value.

The feature launched internally first. From invite-only accounts, investors ran the full flow themselves: they purchased access, opened the protected file immediately, monitored who had access, saw an attempted share, and revoked access live, completing real tasks instead of reading a diagram.

That validated the model's clarity and technical viability. It was not creator adoption or behavioral validation. The work happened before Superfile had an active creator cohort, so the flow couldn't yet be tested against real seller behavior; I pressure-tested it against payment and entitlement failures instead, then used the live investor walkthroughs to confirm the system was understandable and operable. Creator validation remained the next step.

Because the feature kept changing while the company pivoted, I documented every flow, state, and security boundary in Figma and Notion, the same contract shown in the map above. On a security-sensitive surface those weren't deliverables; they were how design and engineering stayed aligned on what was impossible versus what we chose not to allow.

The hardest part of this project was never the interface. It was holding one line steady, that a payment can unlock access without ever transferring ownership, across product, design, and engineering while the rest of the product kept moving underneath it.

If I did it again, I'd draw the state diagram before the first screen, not after. My early screens treated access as a simple visual condition: paid, so unlocked. Once the state model settled, that same indicator turned out to represent a verified entitlement, something the owner could still monitor and revoke, and the screens I'd made had to be redrawn around it. On a product where the states are the thing you're selling, the interface is downstream of getting those boundaries right.

It taught me that on infrastructure this abstract, the design work is as much about making the system legible to engineers, investors, and users as it is about the screens themselves.