Project Brief
As the Senior Product Designer at Superfile, a venture backed cybersecurity startup, I led the design of a secure monetization system for file sharing platform built on zero trust principles. Superfile enables creators and organizations to share files while maintaining full control over who can access them, for how long, and under what conditions, using a custom file format designed to prevent unauthorized use.
The challenge was enabling people to sell access to files without weakening security or trust. My role spanned product strategy, system design, and UX execution. I worked closely with the CEO, CTO, product manager, and seven engineers to define how payments, access, and permissions worked together across macOS and web. The result was a pay to unlock experience that felt simple for users while preserving Superfile’s security model and supporting the company’s business goals.
The Challenge
These principles caused issue with monetization be cause the concept of refunds created revocation edge cases.
Superfile was built on three main principles.
Files are heavily encrypted
Access is tightly controlled
Real time tracking of files
Context
The push for monetization came directly from leadership and investors. There was a focus to really dive into the ownership of files. The target audience weren't just creators they are owners of digital assets who want control, protection, and the ability to sell access without giving up ownership.
Payment wasn't meant to replace security.
It was meant to sit on top of it. That framing immediately ruled out traditional paywall patterns.
If access could be copied, bypassed, or granted prematurely, the product would undermine the very idea of ownership it claimed to protect. The real question wasn’t whether to monetize. It was how to do so without breaking Superfile’s zero-trust foundation.
What did ownership look like?
It was very much End-to-end across product strategy, UX, and engineering execution.
I partnered directly with the CEO, CTO, and seven engineers to design and ship a secure monetization system without compromising Superfile’s security model. My responsibility wasn’t just designing screens. It was defining what was allowed, disallowed, and technically impossible inside the system.
Building with Stripe
I owned this work end-to-end across product strategy, UX, and engineering execution.
Stripe was intentionally used as the transaction layer rather than reinventing payments in house. The work was not simply integrating a checkout form, but defining how an external payment provider could safely trigger access inside a security first system. I led the design and implementation strategy for how Stripe events connected to Superfile’s access model. Payments were treated as a prerequisite for access, not proof of ownership. A successful transaction did not unlock a file by default. It only allowed the system to release access after payment confirmation was validated and matched against the correct file and recipient. This approach allowed Superfile to support retries, failures, and revocation without exposing sensitive states or granting premature access. Stripe handled the transaction. Superfile retained full control over when and how access was granted.
This system map became a shared contract between design and engineering, defining ownership boundaries and distinguishing which states were technically impossible versus simply undesired.
Creating a controlled payment surface that preserves security boundaries.
Visual consistency and reduced context switching were important outcomes, but the primary goal was to ensure monetization could exist inside the product without weakening its zero-trust foundation.
Rather than relying on Stripe’s default checkout, I designed a custom pay card component that could live natively inside the Superfile experience. This allowed us to control how payment intent was expressed and validated, while ensuring that transactions could never directly grant ownership or bypass Superfile’s security model.
Component Architecture of the pay to unlock system
A layered component structure designed to separate payment intent from access authority, ensuring monetization never weakens Superfile’s security model. Each layer increases system authority while intentionally reducing user-controlled outcomes.
Primitive inputs
Card number
0000-0000-0000-0000
Transaction Intent Layer
Price to unlock
$25.00
Cardholder name
Enter name
Card number
0000-0000-0000-0000
Pay to unlock
Unlock Container
for @Superuser
Price to unlock
$25.00
Access granted
Cross platform decisions and trade offs
A major decision point was whether to implement platform-specific payment logic for macOS versus web. While native implementations felt appealing, they introduced a long-term risk of divergence in payment behavior, webhook handling, and security assumptions. I proposed embedding a lightweight web view inside the macOS app so both platforms reused the same Stripe checkout flow and backend logic. This was to reduce the surface area for bugs and security drift.
Execution, Checks, and Learnings
Throughout the project, I ran structured sprints along side the product manager, I prioritized work in Jira, and documented system flows, UI decisions, and constraints in Figma and Notion. These artifacts weren’t just deliverables for me they were safeguards against misalignment in a security-sensitive feature. This was crucial while working at superfile there was consistent pivoting and feature changes that created difficult communication and daily misunderstanding.
This product was launched internally, and was tested and used by investors. They were able to successful experience the pay to unlock feature on while logged into their invite only Superfile account.