Co-Founder / Founding CTO

Technical Co-Founder / Founding CTO

Rally is hiring a Technical Co-Founder / Founding CTO to take long-term ownership of the technology behind a new operating and distribution layer for live events.

Important: Rally is currently bootstrapped. This is an equity-based co-founder opportunity and does not include a guaranteed salary initially. We are looking for someone who wants meaningful ownership of the company and is prepared to build mission-critical infrastructure—not someone looking for a short-term freelance project.

ABOUT RALLY

Rally is building infrastructure for the live-events industry.

The platform connects the systems surrounding an event: organizers, talent agencies, middle buyers, venues, production partners, ticket buyers, payments, ticketing, transportation, documents, safety, settlement, CRM, analytics, and door operations.

We are initially focused on concerts originating through college and group demand, with the broader goal of building infrastructure that can support professional live events at scale.

Rally is being designed as a multi-sided platform with separate experiences for:

• Event organizers and organizations
• Talent agencies
• Middle buyers and booking partners
• Rally administrators and operators
• Venues and production partners
• Ticket buyers
• Door and scanning teams

An extensive product foundation and initial codebase already exist. The technical co-founder will audit what has been built, determine what should be retained or rebuilt, establish the production architecture, and own the platform from launch through scale.

THE MOST IMPORTANT SYSTEM: TICKETING

One of the highest-priority responsibilities is building Rally's ticketing infrastructure into a system we can trust for real concerts.

Think about the engineering requirements behind a Ticketmaster-style onsale:

A major artist announces a show.

Thousands or tens of thousands of fans hit the event page at once.

Inventory cannot oversell.

Payments cannot be duplicated.

A customer cannot be charged without receiving the correct ticket.

Every ticket must have a unique, auditable ownership history.

Transfers and resales must invalidate previous credentials.

QR codes must validate securely.

Tens of thousands of attendees may arrive within a narrow entry window.

Venue connectivity may become slow or disappear entirely.

Scanners still need to work.

Capacity counts still need to remain accurate.

If one service fails, the entire event cannot fail with it.

We need an engineer who understands that this is distributed systems + payments + inventory + identity + access control + real-world operations.

WHAT YOU WILL OWN

Ticketing & Inventory

• High-concurrency ticket onsales
• Event inventory and hard capacity enforcement
• Reserved and general-admission inventory
• Organization and promoter ticket allocations
• Inventory holds and expiration
• Atomic inventory reservation
• Queueing / waiting-room architecture when required
• Checkout concurrency and race-condition prevention
• Idempotent order creation
• Ticket issuance
• Cancellations and refunds
• Ticket transfers
• Verified resale infrastructure
• Ownership history
• Seller and promoter attribution
• VIP and backstage credentials
• Fraud and abuse prevention
• Complete ticket audit trails

Payments & Financial Infrastructure

• Stripe payment architecture
• Stripe Connect
• Payment intents
• Webhooks
• Idempotency
• Payment retries and failure recovery
• Refunds
• Disputes and chargebacks
• Platform fees
• Promoter and organization revenue attribution
• Financial ledgers
• Reconciliation
• Settlement reporting
• KYC-related platform workflows
• Prevention of double charges and inconsistent payment states

Every dollar moving through Rally should be traceable from the customer transaction through settlement.

QR Codes & Venue Access

Build a scanning system capable of operating at real concert scale.

This includes:

• Secure unique ticket credentials
• Rotating or otherwise screenshot-resistant QR codes where appropriate
• One-time ticket validation
• Immediate duplicate-use detection
• Transfer invalidation
• VIP/backstage permissions
• Wrong-event detection
• Scanner device authorization
• Real-time check-in state
• Entry and exit tracking
• Live venue capacity
• Offline and degraded-connectivity scanning
• Local scanner synchronization
• Conflict resolution when connectivity returns
• Manual attendee lookup and recovery workflows
• Lost-phone and dead-phone procedures
• Complete access audit logs

The system must be designed around the reality that cellular service inside a packed venue can be unreliable.

Reliability & Scale

Rally cannot discover whether its ticketing architecture works during the first major concert.

You will own:

• Load testing
• Stress testing
• Concurrency testing
• Payment failure simulations
• Database failure simulations
• Scanner failure simulations
• Network-loss simulations
• Queue testing
• Rate limiting
• Caching
• CDN architecture
• Database scaling
• Backups
• Disaster recovery
• Monitoring
• Alerting
• Observability
• Incident response
• Rollback procedures
• Security reviews
• Production runbooks

Before Rally handles a 10,000-, 20,000-, or 50,000-person event, we should have already simulated conditions significantly worse than the expected event.

THE BROADER RALLY PLATFORM

Ticketing is only one part of the system.

The technical co-founder will also lead development of Rally's broader infrastructure.

Agency Platform

A workspace for talent agencies and large artist rosters, including:

• Artist and roster management
• Calendar and routing intelligence
• Geographic visualization of artist movement
• Schedule gaps
• Demand by market
• Offer and opportunity tracking
• CRM
• Documents and institutional knowledge
• Search and AI-assisted analysis
• Feasibility analysis across artist, market, venue, timing, routing, and budget

The long-term goal is for firms to be able to ingest messy institutional information—CRM records, spreadsheets, calendars, documents, presentations, historical deals, and other internal data—and have Rally organize that information into a usable operating system.

Middle Buyer / Booking Platform

• Artist directory
• Availability
• Pricing ranges
• Offers
• Holds
• Booking workflow
• Event pipeline
• Routing
• Contracts
• Communication history
• Settlement
• CRM and institutional memory

Organizer Platform

Organizations, promoters, companies, fraternities, sororities, and other groups can:

• Plan events
• Pool budgets with co-hosts
• Select artists
• Evaluate feasibility
• Manage venues
• Coordinate production
• Handle transportation
• Manage insurance and compliance
• Manage ticket allocations
• Track sales
• Manage attendees
• Store contracts and event documents
• Operate the event through settlement

Rally Admin

A completely separate internal operating environment for Rally.

This includes:

• Event oversight
• Booking activity
• Ticketing
• Revenue
• Payments
• Settlements
• Organizations
• Agencies
• Artists
• Venues
• Production
• Insurance
• Contracts
• User management
• Permissions
• System health
• Error logs
• Fraud monitoring
• Scanner status
• Incident management

Data & AI

Rally should eventually become an intelligence layer over live events.

That includes:

• Unified event data
• Artist demand
• Market demand
• Routing intelligence
• Historical event performance
• Ticket conversion
• Sell-through
• Pricing intelligence
• Capacity forecasting
• Fraud detection
• Artist-event matching
• Operational risk signals
• Natural-language search across Rally data
• "Ask Rally" functionality for feasibility and operational questions

SECURITY & DATA ARCHITECTURE

Rally will hold sensitive commercial, customer, ticketing, payment, and potentially agency information.

You will own architecture around:

• Multi-tenant data isolation
• Role-based access control
• Authentication
• Authorization
• Encryption
• Secrets management
• Audit logs
• Least-privilege access
• Secure file storage
• Data retention
• Administrative access
• Environment separation
• Dependency security
• Vulnerability management
• Backup and recovery

Agency data must not leak between agencies. Organization data must not leak between organizations. Administrative systems must not accidentally become publicly accessible.

WHAT WE ARE LOOKING FOR

We care more about engineering judgment and ownership than years on a résumé.

Strong candidates should have experience with several of the following:

• TypeScript
• React
• Next.js
• Node.js
• PostgreSQL
• Distributed systems
• High-concurrency applications
• Transactional database design
• Stripe or comparable payment infrastructure
• Webhooks and idempotency
• Queueing systems
• Caching
• Secure authentication and authorization
• Multi-tenant SaaS architecture
• Real-time systems
• Observability
• Cloud infrastructure
• Automated testing
• CI/CD

You should understand concepts such as:

• Race conditions
• Atomic transactions
• Idempotency
• Event-driven architecture
• Exactly-once vs. at-least-once processing
• Database locking
• Inventory consistency
• Failure recovery
• Horizontal scaling
• Rate limiting
• Graceful degradation
• Distributed state synchronization

ESPECIALLY VALUABLE EXPERIENCE

We would be particularly interested in someone who has worked on:

• Ticketing platforms
• High-volume e-commerce
• Fintech
• Marketplaces
• Payments infrastructure
• Stadium or venue technology
• Travel booking
• Reservations
• Flash-sale systems
• Identity/access systems
• Offline-first applications
• High-traffic consumer platforms

Experience with systems where money, limited inventory, and high concurrency collide is particularly valuable.

WHO THIS ROLE IS NOT FOR

This is not a conventional frontend engineering job.

It is not primarily about building dashboards or making UI changes.

It is not a role where a founder hands you individual tickets and you implement them.

We need someone who can look at a requirement like:

> "40,000 people may attempt to purchase tickets, and thousands may arrive at the venue simultaneously"

and independently determine the architecture, failure modes, tests, monitoring, operational procedures, and safeguards required before saying the system is ready.

You should be willing to say "we are not ready to launch this yet" when the engineering evidence does not support it.

WORKING RELATIONSHIP

Caroline, Rally's founder, leads product vision, customer development, sales, partnerships, fundraising, and event operations.

The technical co-founder will own:

• Engineering
• Architecture
• Infrastructure
• Security
• Reliability
• Technical hiring
• Engineering standards
• Production readiness

Both founders will collaborate closely on product strategy and major company decisions.

This person should eventually be capable of building and leading Rally's engineering organization.

COMPENSATION

This is an equity-first co-founder position.

Founder equity is expected to fall within approximately 25%–40%, depending on commitment, timing, responsibilities, technical leadership, and the final co-founder agreement.

Equity will be subject to standard vesting and a one-year cliff.

Rally is currently bootstrapped, so there is no guaranteed salary initially. Salary can begin after Rally raises sufficient capital or generates sufficient revenue. No specific salary date is guaranteed.

THE STANDARD

We are not looking for someone who can make Rally appear production-ready.

We are looking for someone who can prove that it is production-ready.

For ticketing in particular, that means we should be able to demonstrate through architecture reviews, automated testing, load testing, failure testing, monitoring, and real-world operational procedures that Rally can safely handle the event before real customers depend on it.

If building infrastructure that has to work when tens of thousands of people show up at once sounds exciting rather than intimidating, we want to talk.
**