TickIT
A full-stack event platform spanning public discovery, ticket commerce, QR access control, organizer operations, and analytics.
- Role
- Full-Stack Engineer
- Stack
- Next.js / TypeScript / React / Rails / PostgreSQL / PostGIS / Devise JWT / Stripe / Tailwind / shadcn/ui
The product boundary
TickIT combined attendee-facing event discovery with organizer event operations, ticket commerce, access control, and decision support. I worked across the Next.js and TypeScript interface and the Rails and PostgreSQL backend as part of a four-developer remote team.
The delivered product included the event-operations core together with implemented ticket purchasing, Stripe payments, QR generation and validation, friend sharing, customer-spend tracking, forecasting, and organizer planning tools.
Current platform
- Public event index and detail APIs expose active event discovery.
- Organizer surfaces cover event creation and details, ticket and tier management, event teams, invitations, and checker-routine controls.
- Business API requests authenticate with Devise JWT and resolve organization scope before accessing events and related records.
- PostgreSQL and PostGIS persist events, geographic locations, ticket catalogs, members, invitations, checker routines, and JWT allowlists.
- Event creation applies the active checker routine by creating event-member records through the supplied after-create job.
Implemented commerce and access
- Shipped attendee ticket purchasing with Stripe at the payment-processing boundary.
- The inspected platform source documents typed ticket and tier APIs plus PostgreSQL event and catalog state; the case study does not reconstruct an unavailable production payment sequence.
- Surviving implementation artifacts show Rails generating encrypted-and-signed expiring QR tokens and the TypeScript client fetching and rendering them in the attendee interface.
- Implemented validation and friend-sharing capabilities for attendee access management; their private production internals are not reconstructed from the artifact snapshots.
Organizer intelligence
- Built customer-spend tracking systems and analytics pipelines around ticket and event activity.
- Implemented organizer dashboards for spending predictions, inventory forecasts, operational metrics, and event cost planning.
- Kept private schemas, jobs, API contracts, model families, and forecasting metrics outside the published architecture where source was unavailable.
Cross-stack delivery
The work moved between responsive product interfaces, typed browser-to-API contracts, Rails controllers and models, data persistence, planning, and code review. That cross-stack collaboration mattered more than treating frontend and backend work as separate tracks.
Implementation details
The surviving access artifacts use an authenticated Rails endpoint to build an expiring payload, encrypt and sign it with application key material, and return a token for a typed React QR viewer. The artifacts preserve concrete implementation detail without being treated as an exact production snapshot.
Across the inspected platform, React and TypeScript handle public and organizer interfaces, Rails owns authenticated business boundaries, and PostgreSQL with PostGIS persists event state. The delivered product adds Stripe purchasing and organizer intelligence at the capability boundary supported by the author’s implementation attestation.
Implementation status
Implemented, shipped, and mapped across the stack.
TickIT joined the current event-operations core with delivered commerce, access, and organizer-intelligence systems. The case study shows their implementation status and the technical boundaries connecting the Next.js client, Rails services, PostgreSQL state, and external payment processing.
- Current code snapshot
- Solid yellow marks behavior inspected in the supplied Rails and Next.js repositories.
- VerifiedImplementation source inspected
- Delivered product systems
- Solid blue marks the implemented commerce, access, analytics, forecasting, and planning capabilities.
- Implemented and shippedCross-stack production work
- QR access implementation
- Surviving Rails and client artifacts document expiring encrypted-and-signed tokens, typed retrieval, and attendee QR rendering.
- Implemented and shippedImplementation artifacts inspected
Current event-operations core
Product controls remain attached to their boundaries.
Public event reads and organizer workflows cross typed client modules into separate Rails route surfaces. Business requests authenticate, resolve organization scope, and operate on explicit event, location, catalog, membership, invitation, and checker models.
Discovery, event setup, tickets, team, and routine controls.
Typed clients, route boundaries, JWT, scope, and controllers.
PostgreSQL, PostGIS, event state, invitations, and checker job.
Interactive system 01
Current event-operations platform
Isolate the supplied Next.js product surfaces, the authenticated Rails boundary, or the persisted event-operations layer. Every view stays aligned to one full-frame source master.
Implementation source available
The supplied snapshot connects public discovery and organizer controls to authenticated, organization-scoped Rails services and persisted event operations.
BoundaryThis master focuses on the event-operations core; the implemented commerce, access, and intelligence layers are mapped in the second system.
Cross-snapshot product sequence
One event journey, with every evidence handoff exposed.
Event setup, commerce, access, and organizer intelligence were all implemented and shipped. The sequence relates those product handoffs to the client, Rails, PostgreSQL, and QR boundaries that remain inspectable, without treating the surviving snapshots as an exact production trace.
Operational sequence / explanatory view
From event setup to organizer planning
Implementation source available
An organizer creates an event, resolves its location, and builds the ticket and tier catalog in the supplied snapshot.
BoundaryThis stage stops at current event operations; it does not imply that the supplied snapshot contains purchasing.
Implemented product system
Commerce, access, and intelligence shipped together.
The four-developer remote team shipped attendee ticket purchasing, Stripe processing, QR access, friend sharing, spend tracking, analytics, predictions, inventory forecasts, operational metrics, and event cost planning across the product stack.
Interactive system 02
Implemented commerce, access, and intelligence
Inspect the delivered product boundaries alongside the technical details preserved in the current platform source and surviving QR implementation artifacts.
Author-attested delivery + inspected artifacts
The delivered product connected attendee commerce and access workflows to organizer operations, analytics, forecasting, and planning.
BoundaryThe view groups implemented product capabilities without treating the surviving source snapshots as an exact copy of the production topology.
Technical implementation
Implemented across the product stack.
The inspected platform uses Next.js and TypeScript for public and organizer interfaces, Rails for authenticated organization-scoped business APIs, and PostgreSQL with PostGIS for event state. The shipped attendee purchase flow integrated Stripe at the payment boundary.
Surviving QR artifacts show an authenticated Rails endpoint building an expiring payload, encrypting and signing it, and returning the token to a typed React viewer that renders a scanner-ready code. They preserve implementation detail without being presented as an exact production snapshot.
The shipped organizer-intelligence system covered customer-spend tracking, analytics, spending predictions, inventory forecasts, operational metrics, and event cost planning. Private schemas, pipeline jobs, and forecasting algorithms are intentionally not reconstructed.