Back to work
Event Commerce Workflow Platform
Red Eye Tickets
Built the platform behind a live ticketing business, spanning checkout, payments, admissions, producer tools, refunds, and reporting.
ProductionOwned product
- Role
- Co-Founder & CTO
- Period
- January 2024–present
- Evidence
- Production platform
- Launch
- Custom platform launched October 2025
Production totals through September 11, 2026 at 3:51 PM PDT; rounded down with QA and local fixtures excluded. Definitions and limitations →
Overview
Red Eye started as a ticketing business with a WordPress-based MVP. That validated demand, but it could not support the reliability, operational control, or workflow specificity the business needed. I rebuilt the product as a full-stack platform around buyers, producers, admins, and door staff.
Field discovery
How I learned the workflow
I was the sole technical contributor, but the product was shaped through continuous contact with the people operating it. I met weekly with my co-founders, worked directly with a four-person admin and operations team, spoke with producers, and attended live events. Those inputs became requirements, interface changes, operational tools, and support workflows.
Weekly operating reviews
Co-founder priorities, business constraints, and feature tradeoffs.
Admin and support feedback
Refunds, corrections, accounting, producer communication, and recurring support problems.
Producer conversations
Event setup, inventory, reporting, access, and lifecycle needs.
Onsite door observation
Scanning, manual lookup, staff training, device constraints, line pressure, and recovery paths.
Observed workflowProduct decisionsProduction iteration
Users
- Ticket buyersclear checkout, mobile tickets, trust, confirmations
- Producersevent setup, visibility, sales reporting, inventory control
- Adminssupport tools, refunds, edits, issue resolution
- Door stafffast check-in, QR scanning, mobile usability, low-friction workflows
Problem
The original stack made checkout reliability, payment options, event operations, and support work too hard to change. The business needed a system that matched live-event operations instead of forcing teams through generic commerce tools.
Ownership
Co-Founder and CTO, sole technical contributor, and primary technical point of contact. I owned product direction, workflow discovery, architecture, full-stack implementation, operational tooling, production support, and technical iteration.
Constraints
- Payments, refunds, and ticket validation had to be deterministic and auditable.
- Door staff needed mobile workflows that worked under time pressure at live events.
- Producers needed useful reporting without exposing admin-level complexity.
Decisions
Decisions that shaped the work
Event lifecycle workflow
Events moved through multiple operational states before, during, and after sales. The platform needed to make those states clear to admins and producers.
DraftApprovedOn saleLive admissionsConcludedReported
Decision
Treat event setup as a lifecycle with explicit states rather than a generic publish/unpublish toggle.
Outcome
Producers and admins had clearer expectations for what could be edited, sold, checked in, refunded, or reported at each stage.
Ticket check-in workflow
Door staff needed to validate tickets quickly in crowded live-event conditions while preserving confidence and reducing device strain.
ProducerDoor staffScannerTicket validationAttendance reporting
Decision
Build a mobile-first scanner with pause/resume and battery-saver controls instead of assuming continuous camera use was acceptable.
Outcome
The check-in experience became more practical for real doors, long lines, and staff who were not sitting at a desktop.
Refund and support workflow
Support questions often involved buyer records, payments, ticket status, event context, and producer communication.
Buyer requestAdmin reviewPayment actionTicket status updateProducer visibility
Decision
Keep support actions connected to payment and ticket state so the operator could understand the consequence before making a change.
Outcome
Support workflows became easier to reason about and less dependent on manual cross-checking.
Implementation
What I built
Core implementation
- Custom event setup and publishing flows
- Checkout, wallet payments, QR ticketing, and confirmations
- Role-based admin and producer dashboards
- Refund, reporting, and support workflows
- Mobile check-in with scanner pause/resume and battery-saver controls
Technical context
RailsReactReduxPostgreSQLAuthorize.NetApple Pay
Production architecture
One system, four operational surfaces
The buyer, producer, admin, and door experiences share authoritative commerce state, but each surface has different trust, density, and failure-mode requirements.
01Experience layer
Buyer checkoutProducer toolsAdmin supportDoor check-in
02Application boundary
Rails APIAuthentication + rolesInventory rulesPayment + ticket state
03State + async work
PostgreSQLBackground jobsAudit trailsNotifications
04External systems
Authorize.Net + walletsEmail deliveryObject storageRender + GitHub
Money movement
Payment and refund transitions remain explicit, idempotent, and auditable; automation cannot silently widen them.
Ticket identity
Orders, issued tickets, refund state, and admission state stay connected so support actions have visible consequences.
Live admissions
Camera scanning degrades to manual lookup, while credentials constrain staff access and the server remains authoritative.
Publishing boundary
Approved event state triggers a controlled public-frontend rebuild so event pages and metadata can publish without a separate manual release.
Evidence
Work in context
Portfolio evidence note
Owned product work. Sanitized Red Eye screenshots, diagrams, test summaries, and code excerpts are approved for publication. Customer data, credentials, private endpoints, production environment values, and security-sensitive operational details remain excluded.
Engineering evidence
Decisions, incidents, and reliability work
The artifacts below expose the reasoning and failure handling behind the interface—not just the finished screens.
Event publishing and search discovery
Approved events needed to reach the static public frontend without requiring a manual deployment for every listing.
Event approvedControlled rebuildPublic event pageMetadata and discovery surfaces
- Decision
- Trigger a controlled frontend rebuild from the event approval workflow so public pages and metadata stay aligned with operational state.
- Outcome
- Approved events can be published through the product workflow instead of a separate manual release step.
Production implementation
From signed evidence to verified recovery
A guarded repair control plane with deduplicated tasks, separated planner/executor/reviewer passes, policy and approval gates, exact-commit deployment, rollback, and production verification.
AI implementation · release safety · measured outcomesRead artifact ProductionOne checkout across three payment protocols
How Authorize.Net, Apple Pay, and Google Pay were joined through provider-specific adapters, order-bound idempotency, recovery, and reconciliation.
Authentication · failure handling · ledger truthRead artifact Resolved production incidentThe final ticket was held, but capture counted it twice
A guest-origin hold became invisible to payment capture after account association. The fix binds consumption, session authorization, and replay to verified checkout provenance.
Origin-bound holds · fail-closed identity · verified releaseRead artifact Production incidentThe event title that broke ticket PDFs
A valid emoji exposed an implicit encoding contract between the web product, stored event data, fonts, and the PDF renderer.
Ownership · root cause · layered remediationRead artifact Accepted architecture decisionWhy production repair stays local-first
A documented tradeoff between autonomous cloud repair, CI-hosted automation, and a bounded local evidence-and-review loop.
Decision · alternatives · revisit conditionsRead artifact Evaluation evidenceSafety evals, operational evidence, and launch readiness
A local agent-safety benchmark, read-only GitHub/Render/runbook gateway, and producer-readiness report tested against production-shaped operating risks.
26 evals · 9 MCP tests · graceful degradationRead artifactProduct evidence
Workflow captures
Review audited Red Eye workflows through product captures and a portfolio-safe source snapshot.
Audited Red Eye product evidence
One product overview and two in-product captures, preserved without production data.
The shared platform boundary connecting buyer, producer, admin, and live-admissions workflows.
Audited workflow snapshot
Platform & Brand Overview
The shared platform boundary connecting buyer, producer, admin, and live-admissions workflows.
BuyerProducerAdminDoor staff
Provenance: portfolio-safe snapshot audited from Red Eye commit 265bf05. This evidence makes no production requests and does not depend on an interactive demo service being online.
The optional interactive build can be deployed in isolation from production and is currently disabled. These audited captures keep the product evidence reviewable without depending on that service.
Outcomes
What changed
Results
- Served 19.1K+ unique buyers across 285 sales-generating events
- Captured $1.44M+ in customer charges as of September 11, 2026 at 3:51 PM PDT
- Added Apple Pay and Google Pay as provider-specific checkout paths
- Replaced the WordPress MVP with a custom application built around event-commerce operations
Reflection
What I learned
Lessons
- Payment and support workflows need deterministic structure because small ambiguities become real operational costs.
- The best product decisions came from watching buyers, producers, admins, and door staff use the system in different live-event conditions.