Case Study
AMP Ticket Add-On Flow
A production feature designed to improve add-on visibility and checkout usability within an existing ticketing ecosystem.
Role
Sole Developer
Status
Production
Focus
Ticketing UX
Type
Product Feature
Overview
What this project is
This project was a production feature built within an existing ticketing environment to improve how event add-ons were surfaced during the purchase experience. The work focused on usability, integration constraints, and feature implementation inside an established system.
Problem
Why this project exists
Add-on opportunities can be missed when they are not clearly surfaced in the purchasing flow. The goal of this work was to improve add-on visibility and usability without disrupting the surrounding ticketing experience.
Goals
Project goals
- • Improve visibility of add-on options during checkout
- • Integrate the feature cleanly into an existing ticketing environment
- • Preserve usability and accessibility while extending the flow
- • Support a production-ready implementation within platform constraints
System
System architecture
Because this was a feature integration rather than a standalone system, the architecture centered on extending an existing frontend flow while respecting current platform boundaries and dependencies.
User enters checkout flow
↓
Add-on feature UI
↓
Existing ticketing integration
↓
Selection / state handling
↓
Checkout continuation
Stack
Technology used
- • React
- • TypeScript
- • Tailwind CSS
Features
Key capabilities
- • Integrated add-on visibility within the purchase flow
- • Usability-focused frontend interaction patterns
- • Feature implementation inside an existing production ecosystem
- • Accessibility-conscious UI refinement
- • Improved alignment between business goals and user flow
Technical Decisions
Important implementation choices
Why integrate instead of rebuilding
The existing ticketing environment already had production dependencies, so the feature had to be implemented in a way that extended current behavior without destabilizing the broader system.
Why TypeScript for the feature layer
TypeScript helped keep state and interaction behavior more predictable while integrating the feature into an existing frontend codebase.
Why UX clarity was central
Because the purpose of the feature was visibility and conversion within the purchase flow, interface clarity and placement decisions mattered as much as the implementation itself.
Constraints
Challenges and limitations
Feature work inside an existing production system is constrained by upstream integrations, surrounding UX patterns, and the need to avoid regressions. This project required balancing product goals with system stability.
Outcome
What this project demonstrates
This work demonstrates production-minded frontend implementation, the ability to ship features inside existing systems, and thoughtful alignment between user flow, technical constraints, and business priorities.
Next Steps
Future improvements
- • Measure interaction performance and add-on engagement more deeply
- • Refine feature placement based on user behavior
- • Expand analytics around add-on selection patterns
- • Document implementation considerations for similar feature work