Designing secure monetization for a zero-trust file platform.

With normal file sharing, you lose control the moment someone downloads a copy. Ownership, rights, and access are gone. For creators, the value isn't only in the file itself. It's in what happens to it afterward: who has it, how it's used, and whether it stays protected.

Superfile changes that. You upload a file, grant access, watch how it's used, adjust permissions, and revoke access whenever you want, all while keeping ownership. A file stays an asset instead of becoming a liability the moment it leaves your hands. My job was to let people sell access to those files without weakening any of that.

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. It works a little like enterprise access controls, but applied to creative rights.

Superfile spans a macOS app, a web platform, secure viewers, payments, permissioning, ownership verification, accounts, and usage tracking. Together they enforce digital rights and let creators actually make money from their work.

The map below lays out how the pieces relate and where value moves between them, so the whole thing stays legible whether you're an engineer or an investor.

Payment had to sit on top of security, never replace it.

The push to monetize came straight from leadership and investors, centered on file ownership. The audience went beyond creators. It included anyone with digital assets who wanted to sell access while keeping control and protection intact.

That ruled out ordinary paywall patterns right away. If access could be copied, bypassed, or handed over too early, the product would undercut the exact thing it promised to protect.

I owned this end to end, across product strategy, UX, and engineering.

We used Stripe as the payment layer instead of building our own. The real work wasn't dropping in a checkout form. It was figuring out how an outside payment provider could safely unlock access inside a security-first product. I led how Stripe's events connected to Superfile's access model, in both design and implementation.

A payment was a prerequisite for access, not proof of ownership. A successful charge didn't unlock a file on its own. Access was only released after the payment was confirmed and matched to the right file and the right recipient. That gave us room to handle retries, failures, and revocation without ever exposing a sensitive state or granting access too early.

The map became a shared contract between design and engineering. It drew the boundaries of who owned what, and separated the states that were technically impossible from the ones we simply didn't want.

Monetization had to live inside the product without weakening its security.

Instead of Stripe's default checkout, I designed a custom pay card that lived natively inside Superfile. It let us control exactly how a payment was expressed and validated, and made sure a transaction could never hand over ownership or slip past the security model.

The pay-to-unlock 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. That left fewer places for bugs or security gaps to creep in.

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. Showing it visually turned out to be the bridge between technical depth and business value.

Discovery, product definition, design systems, investor demos, user testing, engineering collaboration, and fundraising support. Every stage asked me to think across the whole thing, from the interface out to the pitch deck.

I ran sprints with the product manager, prioritized in Jira, and documented flows, UI decisions, and constraints in Figma and Notion. Those docs were more than deliverables. On a security-sensitive feature, they kept everyone aligned, which mattered while Superfile was pivoting and changing features often.

The feature launched internally, and investors used it themselves, going through the full pay-to-unlock flow from their invite-only accounts.

In the end, Superfile was less about pixels and more about how the product was framed, who I built it with, and what it delivered. It taught me as much about product storytelling as product design.