trailmark

Production-grade by design

Built like infrastructure.

Trailmark is engineered the way race organizations need the software holding their runners' money and safety data to be built — for the noon rush when registration opens, for the lottery that closes to the second, for the race day where a dropped connection is not an option — and operated that way for as long as they run it. Every item below says whether it is in place today or planned.

What a professional platform developer brings

The parts nobody sees until they fail.

A registration platform is judged on the morning registration opens, the day a refund goes wrong and the weekend a runner is overdue at an aid station. This is the work underneath the screens — built in from the start, not bolted on after the first incident.

  • In place today built and tested
  • Planned · Phase N on the roadmap
  • no tag: how the work is done

Security & privacy

7
  • Tenant isolation

    In place today

    Every query scoped to its organization, checked by a code rule and by tests.

  • Authorization on every request

    In place today

    A policy decides each action; a request that skips one fails the build.

  • Audited access

    In place today

    Staff impersonation and sensitive actions are logged with who, what and when.

  • Secrets management

    Credentials live in encrypted configuration, never in code or logs.

  • Dependency patching

    In place today

    Security audits run on every change; upgrades are routine, not a project.

  • Privacy-law requests

    Planned · Phase 2

    Account deletion and data export handled as a workflow, not an email thread.

  • Minors' and medical data

    Planned · Phase 1

    Guardian consent, need-to-know access and short retention for the most sensitive fields.

Scale & reliability

11
  • Registration-open spikes

    Planned · Phase 2

    The noon rush modeled, load-tested and sized for before it happens.

  • No overselling under concurrency

    Planned · Phase 1

    Capacity is enforced where the data lives, so two last spots never become three.

  • Idempotency

    Planned · Phase 1–2

    A retried click or a network blip charges once and registers once.

  • Background queues

    In place today

    Email, SMS and exports run off the request path with retries.

  • Caching

    Hot pages served fast without ever showing one runner another's data.

  • Zero-downtime deploys

    Planned · Phase 2

    Releases on a race morning without anyone noticing.

  • Failover

    Planned · Phase 2

    A failed server or database is replaced without losing a registration.

  • Backups and point-in-time recovery

    Planned · Phase 2

    Restore the database to any minute, not just last night.

  • Restore drills

    Planned · Phase 2

    Backups that are tested by restoring them, on a schedule.

  • Capacity planning

    Headroom decided from the race calendar, not discovered during an outage.

  • Load testing

    Big openings rehearsed against production-sized data first.

Money

7
  • Payment processing

    Planned · Phase 1

    Each organization is paid through its own connected processor account.

  • Platform fees

    Planned · Phase 1–2

    Fees taken at checkout, visible and reported, never hand-calculated.

  • Payouts

    Planned · Phase 2

    Organizers see what is coming, when, and why.

  • Refunds and credits

    Planned · Phase 1

    Full, partial, deferral and credit — recorded as a ledger that always balances.

  • Disputes

    Planned · Phase 2

    Chargebacks answered with the waiver, the receipt and the check-in record.

  • Tax reporting

    Planned · Phase 2

    Year-end reporting for organizers handled through the payment processor.

  • Reconciliation

    Every payout ties back to registrations, to the cent.

Compliance

4
  • Card data out of scope

    Planned · Phase 1

    Hosted checkout keeps card numbers off Trailmark's servers entirely.

  • SMS carrier registration and consent

    Planned · Phase 1

    Registered sender, recorded opt-in and working STOP, so texts actually arrive.

  • Email sender rules

    Authenticated domains, one-click unsubscribe and bounce handling for deliverability.

  • Accessibility

    In place today

    WCAG AA contrast is a build gate; keyboard and screen-reader use are designed in.

Operations

10
  • Observability

    In place today

    Errors and structured logs traced to the request that caused them.

  • Alerting

    Planned · Phase 2

    Pages for symptoms a runner would feel, not for noise.

  • On-call

    Planned · Phase 2

    A named person and a runbook for every race weekend.

  • Incident response and postmortems

    Contain, communicate, fix, then write down what changes so it can't recur.

  • Status page

    Planned · Phase 2

    Organizers hear about a problem from Trailmark first.

  • Support tooling and automated tickets

    Planned · Phase 2

    Common questions answered automatically; the rest arrive with context attached.

  • Audit logs

    In place today

    Who changed what, for every organization.

  • Feature flags

    Planned · Phase 2

    New work ships dark and turns on per organization.

  • Release management

    Small, reversible releases, frozen around the biggest race weekends.

  • Cost control

    Hosting, messaging and processor costs watched per organization as it grows.

Product & engineering craft

10
  • Data modeling for multi-year events

    An event, its yearly editions and its distances — so history and records carry forward.

  • Migrations from existing platforms

    Planned · Phase 2

    Past registrations and results moved with dry runs and totals that must match.

  • Automated tests and quality gates

    In place today

    Style, security, accessibility and full-season browser tests on every change.

  • Design system

    In place today

    One set of components and themes, so every screen looks and behaves the same.

  • Internationalization

    Languages, dates and currency formats handled properly, not string-replaced.

  • Native mobile release pipelines

    Planned · Phase 3

    Builds, signing, store review and staged rollouts for iOS and Android.

  • Offline race day

    Planned · Phase 3

    Aid-station check-in keeps working with no signal and syncs when it returns.

  • Documentation

    Decisions recorded as they're made, so the next person knows why.

  • Roadmap and prioritization

    Built in the order that earns the next race, not the order that's fun.

  • Vendor evaluation

    Processors, messaging and hosting chosen on cost, risk and lock-in.

Security

The parts of the system that have to be right every single time, not just on launch day.

Tenant isolation, enforced twice

In place today

A static-analysis rule fails the build on any unscoped query against tenant data; a runtime check verifies every request was authorized and every index was policy-scoped.

Authorization on every request

In place today

Pundit on every action, with a pinned, tested list of the only public endpoints — a cop forbids skipping authorization for a whole controller.

Audited impersonation

In place today

Support can act as an organizer to help — every action records both the true and acted-as user.

Secure auth & session hygiene

In place today

Bcrypt passwords, password reset, and a background job that purges idle sessions.

Privacy-safe logs

In place today

Structured event logs carry ids, never emails or tokens; tokens in URLs are masked before they reach a log.

Security scanning & dependency audits on every change

In place today

A security scan and a gem/JS dependency audit run in the same gate as the tests — a known vulnerability fails the build, not a monthly report.

Encryption for sensitive fields

Planned · Phase 1

Medical notes and emergency-contact data encrypted at the field level, not just at rest.

Two-factor authentication for organizer accounts

Planned · Phase 2

Optional, then required, 2FA for the accounts that can move money and message a whole race field.

Periodic third-party penetration testing

Planned · Phase 2

An outside team probing for what internal review misses, on a recurring cadence.

Concurrency & uptime

Registration opening at noon is a traffic spike, not a normal day — thousands of runners checking out in the same minute, a lottery closing to the second. The platform is built so that minute is uneventful.

Capacity enforced at the database

Planned · Phase 1

A distance sells exactly its capacity — the database itself refuses the spot past the last one, so hundreds of simultaneous checkouts can never oversell.

Idempotent payments

Planned · Phase 1–2

Every charge carries an idempotency key — a retried request or a dropped connection never charges a runner twice.

Retries with backoff

In place today

Background work retries on failure with backoff instead of failing silently or hammering a provider that is already struggling.

Queued work off the request path

In place today

Confirmation emails, receipts and webhooks run on Solid Queue, so a runner's checkout returns the moment payment is confirmed.

Real-time without polling

In place today

Turbo Streams over WebSockets push updates to every open screen instead of every client polling for them.

Horizontal scaling

Planned · Phase 2

Stateless application servers scale out behind a load balancer ahead of a big opening, and back in afterward.

Load testing before big openings

Planned · Phase 2

Registration-open traffic rehearsed against production-sized infrastructure before it happens for real.

Zero-downtime deploys

Planned · Phase 2

A release rolls out without dropping a checkout or a live race-day session mid-request.

Failover

Planned · Phase 2

A standby database and application capacity take over if the primary fails, with a target measured in minutes.

What happens at noon on registration day

Illustrative timings

One runner's checkout, in the same second as thousands of others.

  1. 1

    12:00:00.0

    Doors open

    Thousands of runners hit Register in the same second.

    Load-tested and scaled out ahead of time

    Planned · Phase 2
  2. 2

    +0.1 s

    Fair queue

    Bots throttled; real runners go through in arrival order.

    Rate limiting on registration

    Planned · Phase 1
  3. 3

    +0.3 s

    Spot held

    The database holds one spot for this runner — or says sold out.

    Capacity enforced at the database

    Planned · Phase 1
  4. 4

    +2.1 s

    Payment confirmed

    Charged exactly once, even if the phone drops signal and retries.

    Idempotent payments

    Planned · Phase 1–2
  5. 5

    +2.2 s

    Confirmation queued

    Email, receipt and webhooks go to the job queue; the page returns now.

    Queued work off the request path

    In place today
  6. 6

    +2.4 s

    Dashboard live

    The organizer's count ticks up on every open screen.

    Real-time without polling

    In place today

Stability & error reporting

Every change ships through the same gate — nothing merges that a serious reviewer wouldn't pass.

Error tracking with alerts

In place today

Every exception reaches Sentry with context, not a silent 500.

Structured logs

In place today

Every request and background job logs in a consistent, queryable shape.

Browser tests of the full race-season walkthrough

In place today

System tests drive a real browser through registration, lottery, race day and results, not just unit tests of the pieces.

Performance monitoring

Planned · Phase 2

Response times and slow queries tracked continuously, not discovered from a complaint.

Alerting on symptoms, not noise

Planned · Phase 2

Alerts fire on what runners feel — failed checkouts, slow pages, a growing queue — and page a person, not an inbox.

The quality gate

Every change passes this gate before it ships.

  1. 1

    Style & custom rules

  2. 2

    Security scan

  3. 3

    Dependency audits

  4. 4

    Schema & theme drift

  5. 5

    Tests

  6. 6

    Browser tests

  7. 7

    Deploy

Infrastructure & maintenance

One application to operate, not a fleet of services that drift out of sync with each other.

One container-deployed application

In place today

Jobs, cache and real-time all run alongside the database — no separate systems to patch, monitor and keep compatible.

Schema & theme drift checks

In place today

The gate fails if the database schema or the design tokens drift from what's checked in.

Dependency upgrades as routine

In place today

Audited on every change, so upgrading is a small, frequent decision instead of a once-a-year project.

Automated backups with point-in-time recovery

Planned · Phase 2

Continuous backups that can restore to any recent moment, not just last night.

Restore drills

Planned · Phase 2

Recovery tested on a schedule, so the first real restore isn't also the first attempt.

Multi-region failover

Planned · later

Once scale calls for it — resilience beyond a single region.

Payment processing

Money movement designed so card data never touches Trailmark and every dollar is accounted for.

Stripe Connect, one account per organization

Planned · Phase 1

Each organization's revenue lands in its own connected Stripe account, not a shared pool.

Card data never touches Trailmark

Planned · Phase 1

Stripe-hosted checkout keeps PCI scope minimal — Trailmark never sees or stores a card number.

Destination charges with application fees

Planned · Phase 1–2

The platform fee is taken automatically at the moment of charge, not reconciled after the fact.

Refunds, partial refunds, coupons and credits as a ledger

Planned · Phase 1

Every adjustment to what a runner paid is a ledger entry, auditable after the season is over.

Payouts

Planned · Phase 2

Real money landing in an organizer's own bank account, on a schedule they can see.

Disputes & chargebacks handled

Planned · Phase 2

A structured process for the moment a cardholder disputes a charge, not an email nobody sees.

Bring your history with you.

Migration, handled with care

Moving a race's history is the highest-care step of adopting any platform. Trailmark treats it as a project with a named plan, dry runs, a parallel-run period and a reconciliation report that has to match to the record and to the dollar before anything goes live.

Migrate from UltraSignup, spreadsheets or any other registration platform.

  1. 1Migration plan

    A named plan per organization: what moves, who signs off, and the checkpoint dates.

  2. 2Dry-run import

    Every import runs first as a dry run — nothing is written until the report is clean.

  3. 3Match & deduplicate

    Athletes matched on email, name and birth year; uncertain matches go to a review queue.

  4. 4Parallel run

    Both systems run side by side for a period, with nightly reconciliation.

  5. 5Reconcile & sign off

    Record counts and dollar totals must match before the organizer signs off.

  6. 6Cut over

    Go-live with one-step rollback to the pre-import snapshot if anything looks wrong.

  • Past registrations, results and course records, by year
  • Athlete accounts matched and deduplicated, with a review queue
  • Waitlists, deferrals and volunteer credits carried over
  • Counts and dollar totals reconciled to match exactly
  • Dry runs and one-step rollback — zero lost records
  • Sign-off checkpoints at every stage
Planned · Phase 1–2 See an import run →

Mobile apps

The same product, wrapped natively, once race day calls for it.

Native iOS & Android, from the same screens

Planned · Phase 3

Hotwire Native wraps the existing server-rendered screens — nothing to rebuild twice.

Push notifications

Planned · Phase 3

A race-day alert reaches a phone's lock screen, not just an open tab.

Offline-tolerant race-day views

Planned · Phase 3

Built to keep working through the weak signal at an aid station, not just a strong wifi bar.

Running the platform

The work nobody outside sees — support, incidents, privacy, fraud, patching — done as a routine, by the people who built the system.

Automated customer support

Planned · Phase 2

Athlete and organizer tickets auto-categorised, answered from each race's own guide, and escalated with SLA timers when a person is needed.

Status page & incident communication

Planned · Phase 2

One public page for every component, updated during an incident, with a postmortem afterward.

On-call rotation

Planned · Phase 2

A primary, a secondary and an escalation path once real races depend on this running.

Audit logs

In place today

Impersonation and actor columns record who really acted and on whose behalf; a full audit trail of sensitive actions follows in Phase 2.

Role-based access, least privilege

In place today

Organization roles and a policy on every request mean each person sees only what their job needs; a medical-only role follows with race day.

Data retention & deletion requests

Planned · Phase 2

Clear retention periods, and a runner's request to export or delete their data handled end to end.

Fraud & chargeback handling

Planned · Phase 2

Suspicious payments flagged before payout, and disputes answered with the evidence already attached.

Abuse & rate limiting on registration

Planned · Phase 1

Bots and scripted checkouts throttled, so real runners get the spots on opening day.

Patching cadence

In place today

Dependencies and security advisories audited on every change and upgraded on a routine, not an emergency.

Observability dashboards

Planned · Phase 2

Uptime, latency, error rate and queue depth on one screen, with history to compare openings year over year.

Releases behind feature flags

Planned · Phase 2

New work ships dark, turns on for one organization first, and turns off in seconds if it misbehaves.

Disaster-recovery drills

Planned · Phase 2

Restores and failovers rehearsed on a schedule, so the first real one isn't the first attempt.

When something breaks

The same five steps, every time. Planned · Phase 2

  1. 1

    Detect

    Monitors on checkout success, latency and queue depth notice first — before a runner writes in.

  2. 2

    Alert

    The on-call engineer is paged with the failing symptom and a runbook.

  3. 3

    Fail over

    Traffic moves to healthy capacity or a standby database while the cause is found.

  4. 4

    Communicate

    The status page and affected organizers hear what's happening, and when it's fixed.

  5. 5

    Postmortem

    A blameless write-up, and the fix that stops it happening twice.

Platform health

Illustrative
Uptime · 30 days
99.98% target 99.95%
p95 latency
182 ms budget 300 ms
Error rate
0.03% budget 0.1%
Job queue depth
14 alert at 500

What the on-call engineer watches — see it with incidents, the status page and support queue on the platform operations screen.

Accessibility & design system

One design system, tokens only, checked automatically instead of by eye.

Automated WCAG AA contrast gate

In place today

Every colour pair in the design system is checked for contrast on every change, in both themes.

Light and dark themes

In place today

A full theme pair, not a dark mode bolted on afterward.

Tablet-first operator screens

In place today

The design system's layouts are built tablet-first for race day, where a laptop doesn't fit on the table.

Locale-aware formatting, translation-ready

Planned · Phase 2

Dates, numbers and currency follow the runner's language; this prototype already switches between English, Spanish, French and German.

Architecture, at a glance

One Rails application, one database, real-time and background work built in — no fleet of services to keep in sync. Dashed boxes are planned.

Browser Native iOS / AndroidPlanned · Phase 3 One Rails application Organizer Athlete Platform Postgrestenant-scoped rows Job queueSolid Queue CacheSolid Cache Realtime channelper tenant Stripe ConnectPlanned · Phase 1–2 Email / SMS providersPlanned · Phase 1–2 Timing / RFID integrationsPlanned · Phase 3

What's next

Further out on the roadmap, once the foundation above is carrying real races.

  • Timing / RFID & GPS integrations Planned · Phase 3
  • Data export API Planned · Phase 2
  • SSO for large organizations Planned · later
  • Analytics warehouse Planned · later

AI, where it helps

A secondary priority, used where it saves real time.

A secondary priority, not the core of the platform — used where it removes real toil, paid for by the organization that uses it through usage credits, never a hidden cost.

For organizers

  • Natural-language answers about registrations Planned · Phase 5
  • Drafting announcements and race-day alerts Planned · Phase 5
  • Waiver / medical-note triage flags Planned · Phase 5
  • Volunteer schedule suggestions Planned · Phase 5
  • Anomaly alerts — payment spikes Planned · Phase 5
  • Photo bib-matching Planned · Phase 4

For athletes

  • Plain-language race search Planned · Phase 5
  • Training-plan suggestions toward an entered race Planned · Phase 5
  • Pacing and cutoff projections Planned · Phase 5
  • Auto-generated race recaps and share cards Planned · Phase 5

See it running, then see where it's going.

The prototype is clickable screens over sample data; the roadmap is the order we build the rest.