Product Design + Development
Portix
Portix is a two-sided event ticket marketplace I designed and built to fix what I saw as the core rot in ticketing: buyers never truly own what they pay for, hosts lose control after the sale, and scalper bots win. I built it on Hyperliquid so a ticket is a real, resellable on-chain asset with near-zero gas, and I gated checkout behind KYC to keep tickets with real fans. As the sole founder, designer, and developer, I owned the whole arc, from strategy and UX through to the on-chain minting and the door-scanning flow.
Role: Founder, designer, and full-stack developer. I owned product strategy, UX, visual design, and the end-to-end build: the marketplace and ticket-detail flows, the host Box Office dashboard, and on-chain minting/redemption.
- Shipped a complete two-sided product solo: a consumer marketplace plus a host Box Office (event deploy, live mint/redeem metrics, QR scan-to-redeem).
- Reframed a ticket as an owned, resellable on-chain asset (HIP-1), removing gas and custody friction that make most on-chain ticketing unusable for real events.
- Designed a KYC-gated, anti-scalping purchase flow and can explain the tradeoff versus pure anonymity.
The Problem
Event ticketing is plagued by scalpers, opaque fees, and tickets that buyers never truly own. Fans overpay on resale, hosts lose control after the sale, and there is no clear record of who actually holds a ticket.
The gap I wanted to close: make a ticket a real asset the buyer owns and can resell, while keeping hosts in control of issuance and redemption and shutting scalper bots out by design.
The Insight & My Approach
The leverage point is settlement. If a ticket lives on-chain as a transferable token, ownership is real and resale is just a transfer, no opaque intermediary. Hyperliquid HIP-1 gave me that with near-zero gas, so the on-chain version could finally feel as smooth as a normal app.
Because I was solo, I scoped to the two sides that matter most: the fan buying and reselling, and the host issuing and scanning. I cut everything that did not serve that loop (secondary analytics, multi-event bundles) for v1.
Design Decisions & Tradeoffs
Phone-first, not web. Ticketing happens at the door and on the move, so the buyer and scanner flows are mobile-native; the host dashboard is the one wider surface. I accepted a smaller canvas to match where the product is actually used.
KYC-gated checkout over pure anonymity. It costs conversion (a verification step before buying) but it is the mechanism that keeps tickets with real fans and out of bot farms. I judged the anti-scalping value worth the friction, and it is the tradeoff I am most ready to defend.
On-chain HIP-1 over a traditional database. It means buyers genuinely own the ticket and resale is a transfer, but it also means designing around wallet and chain realities rather than a simple row in a table.
The Marketplace
The customer side is a clean, dark marketplace to browse events, view ticket detail, and buy or list tickets for resale. Listings show real availability and price, and checkout is gated by KYC so only verified fans can purchase.
Because tickets settle on Hyperliquid HIP-1, ownership is on-chain and gas is effectively zero, so reselling is as simple as listing and transferring.
Box Office (Host Portal)
Hosts get a Box Office dashboard to deploy a ticket token (HIP-1) for each event, set supply and face value, and watch mint and redeem progress live. Each event card shows minted vs. total supply and how many tickets have been scanned at the door.
A built-in scanner lets staff redeem tickets on entry, updating attendance in real time so hosts always know how many fans are in the building. This is the moment the on-chain record becomes useful in the physical world.
Why It Stands Out
Portix treats tickets as owned, resellable assets instead of rental keys. Buyers get a transferable record of their purchase, hosts retain issuance and redemption control, and the Hyperliquid settlement layer removes the gas and friction that make most on-chain ticketing unusable for real events.
What I Learned & Would Improve
The hardest part was making an on-chain flow feel normal. Wallet and chain states add friction that a traditional app hides, and if I rebuilt it I would invest more in graceful wallet-error states and a clearer first-run so a non-crypto user is never stuck.
I also have not run real host or fan testing yet, so the current 'impact' is design intent, not measured conversion or scan-through rates. The next step is a small pilot event to validate the door-scan flow under real conditions.
That honesty about what is proven versus assumed matters to me: the build is complete and demonstrable, and I have a clear line of sight on exactly how I would take it further.
Key Features
Two-sided marketplace
Customers buy and resell; hosts issue and manage, all in one app.
On-chain tickets (HIP-1)
Tickets mint and settle on Hyperliquid with near-zero gas; buyers truly own them.
KYC-gated checkout
Anti-scalping purchase flow keeps tickets with real fans; a deliberate tradeoff.
Box Office dashboard
Live mint/redeem metrics per event for hosts.
Scan-to-redeem
QR scanning at the door with real-time attendance.
Resale built in
List and transfer tickets without leaving the app.