Race event software that keeps entries, timing and race day in one place.

Race event management software runs a single-day endurance event in one system: entries, bibs, wave starts, packet pickup, volunteers, timing, results, sponsors and fundraising. Participants register and pay in one place, and the race team works from one entry list for bibs, waves, volunteers and timing, instead of keeping separate lists that drift apart. It is built for events whose entries, race-day jobs and results no longer agree across separate tools and spreadsheets.

This page is about single-day endurance events, not team-sport seasons. A youth league runs fixtures, standings and team rosters across a season. A race runs one day with a hard start time: entries close, bibs go out, waves start, timing runs, results publish, and awards follow, all in a few hours. The workflows are different, the failure points are different, and the software should be shaped around race day, not a season calendar. If your organisation runs both, the first call names which one comes first, because one operation's rules should not be forced onto the other's.

Spreadsheets and a registration form are fine while one person holds the whole race in their head and the entry list barely changes. They stop being enough when one change has to be reworked by hand in several places at once: the entry list, the bib list, the wave list, the packet pickup list and the timing export. That is also when mistakes get expensive, because a missed edit can mean a bib with the wrong name, a wave that starts overfull, a volunteer sent to the wrong post, or a result that belongs to someone else. If the race director is the only person who can run race morning, the spreadsheet is doing a job it was not made for.

Entries hold the participant, the distance or wave, the price tier, add-ons such as a shirt, and payment in one record. Price tiers change on dates the race sets, so early entries, standard entries and late entries price themselves without anyone editing a form by hand. Race-day signups go into the same record, entered by staff at the desk, so a race-morning entry gets a bib and a timing record in the same step instead of living on a paper list that never reaches timing. Caps per distance and per wave are enforced at entry, not discovered at the start line.

A bib is assigned from the entry record, not typed in separately, so the bib, the participant and the timing chip all point at the same person. Waves group participants by distance, expected pace or start time, and each wave has its own cap and start order. Timing reads from the same list: start, split and finish reads land on the right participant because the bib assignment and the timing list come from one record. When a bib changes hands through an approved transfer, the new holder's name, waiver and emergency contact replace the old ones before race day, so results and safety records never belong to the wrong person.

Packet pickup is planned around how volunteers actually find a bib: pre-packed packets in bib order, or shirt and sponsor items kept separate with bibs handed out on lookup, are both supported, and the choice is made before race week, not on the morning. Volunteers search by name, confirm the bib, and mark the packet collected in one step, so a packet cannot be handed out twice and an uncollected packet is visible at a glance. Early pickup and race-morning pickup draw on the same list, so a participant who collected early cannot collect again, and race-morning staff see exactly who is still outstanding.

Volunteers are assigned to named posts with named shifts, not to a general pool, so a gap shows up as a specific post at a specific time, not as a vague shortage. The race team sees which posts are covered, which are short, and which volunteers have confirmed, and can move a confirmed volunteer from a post that is covered to one that is not. Confirmation reminders go out before race day, and no-show posts are visible early enough to reassign, instead of being discovered when a course turn has nobody on it. The plan also names who covers a post when nobody can be found, because race day always produces at least one gap.

Results come from the timing reads on the same entry list, so finish times, split times and age-group places are calculated from one record instead of being retyped from a timing export. Results publish to one place participants can check, and corrections go through a named review step: a disputed time is checked against the timing reads, corrected once, and the correction shows in the published results. Awards follow from the same results, so the awards list and the published results cannot disagree. The aim is results participants trust quickly, not results that arrive after the awards ceremony has already happened.

Transfers, deferrals and refunds are rules set before entries open, not decisions made inbox by inbox. A transfer moves the entry to a new participant who signs the waiver and gives emergency contact details before the bib is reissued, because a bib must never belong to someone the race has no record of. A deferral moves the entry to a later event under rules the race sets, including any deadline. Refunds follow the policy the race publishes at entry, including what is refundable and what is not, so staff are not negotiating the same policy differently for every participant who asks.

Sponsors are held as records with their level, what they paid or provided, what they were promised, and what has actually been delivered. Logos, mentions, booth space, entries included in the deal, and photo or results-page visibility are tracked against the same record, so the race team can see before race day which promises are still outstanding. After the race, the same record supports renewal: what the sponsor received, how many participants saw it, and what is offered next year. A sponsor who cannot see what their support delivered rarely comes back, and a sponsor record is what makes that conversation possible.

For a charity race, participants and teams get fundraising pages tied to their entry, with a goal and a running total that donors can see. Donations, entry fees and sponsor money are kept as separate kinds of money in the same system, so the charity can report what came from entries, what came from donations, and what came from sponsors without reconciling three tools. Team totals roll up from individual pages, so a team captain sees the team's progress without anyone adding it up by hand. The charity owns its donor record, and the race team owns the race record, and the two agree.

Race-day messages go to participants, volunteers and sponsors from one list, so nobody gets the old plan while someone else gets the new one. A course change, a delayed start, or a weather update is written once and sent to the groups it affects, with the message recorded against the event so staff answering questions later can see exactly what was sent and when. Wave start times, volunteer post times and packet pickup times that move with the change are updated in the same step, instead of being corrected separately in three places after the message has already gone out.

Buy a maintained race platform when it handles your entries, bibs, waves, packet pickup, volunteers, timing, results, sponsors and fundraising with reasonable setup and its pricing makes sense. Commission custom software when the way your event runs is itself the reason participants return, when repeated manual work has a measurable cost, or when a critical connection to your timing system or other tools cannot be done cleanly any other way. If your distances, wave rules, sponsor levels or fundraising model are still changing every week, wait and settle them first.

For a small, well-defined task with someone technical managing it, freelancers are often cheaper. The pattern that goes wrong is a non-technical buyer coordinating several freelancers becoming the project manager, the tester, and the person who discovers the pieces do not fit. A software company earns its fee when the work needs coordination across screens, rules, data, and connections: one accountable party, one phase price, and checkpoints against the whole race workflow. If your need is one screen or one fix, hire the freelancer.

The first paid phase may cover a bounded audit, a proof of concept, a recovery plan, or a small first release. The final price depends on how deep the race workflow goes, how many kinds of users it serves, what it needs to connect to, whether data needs moving over, whether phones or tablets are involved, any timing or payment rules, and the condition of existing code. The agreed phase is priced in writing before it starts.

Timing depends on scope: a bounded audit or proof of concept is a smaller engagement, while a system with several connections to other systems, data to move over, tablet use at packet pickup or on course, or formal timing and payment rules takes longer. The schedule is set once the first workflow and what 'done' looks like are clear, and it is set against a real race date, not an open-ended calendar.

Yes. Takeover is a common first engagement, and it always starts with an audit: where the code lives, how your data is organized, what is tested, which outside services it depends on, who can access what, and how updates go live. Code that is understandable and fit for the next release stays; only the parts blocking reliability get replaced. For spreadsheets, the audit maps which sheets hold the real entry, bib and timing truth, and which are copies that have drifted.

Ask for the quote to name everyone who will use the system, including your own team. Every platform has two products: what participants see, and what your people use all day: bib holds, exceptions, refunds, volunteer schedules, sponsor records, and a record of who did what. When that second product is quoted as an 'admin panel' on a single line, it becomes the overrun. Our quotes treat your team's screens as their own scope, with their own users. Then the phase names the workflow, what 'done' looks like, the price, and the exclusions, all before paid work starts.

You judge what you can see, not the code. Every checkpoint is working software you click through yourself, tested against the workflow agreed at the start, using your own entry list, your own waves and one full rehearsal of race morning. Progress is reported in plain language: what changed, what is next, and what it costs. Because you own the code, the accounts, and the operating notes throughout, nothing about the work is locked inside our heads. Our job is to make the work checkable; your job is to check it against your race.

Security starts with the data, the people, who can see and change what, the systems it connects to, and where it runs. The scope can include access controls, separate testing and live environments, protected passwords and keys, activity logs, backups, and recovery plans. Race data needs particular care: waivers, emergency contacts, medical notes given at entry, and payment details are held under the access rules the race sets, and are visible only to the roles that need them on race day. We write down which protections are included and which evidence your team or an independent specialist must provide. We do not call a product compliant until the technical, operational, and legal requirements are all verified.

We need one person who owns the race workflow, access to the relevant users and systems, timely answers on race rules, and someone who can accept or reject each milestone. A weekly working session is usually enough once the scope is stable. Your team should not have to manage developers day to day. The team that scopes your project is the team that does the work: no handoff to another vendor after you sign, and you can talk to the people doing the work directly.

You own the code built for you and control where it lives, the cloud accounts, the data, analytics, and third-party subscriptions. Outside services and open-source pieces keep their own licence terms. The operating notes and handover material stay current so another capable team can take over.

Every launch includes post-launch warranty cover for defects in the agreed scope, release support, and small screen corrections. After that, work can continue as another fixed phase or an ongoing product engagement. The code and accounts stay under your control either way.

Not every participant will register online, and the first release has to say so plainly. Participants who sign up on paper or by phone still get an entry in the same system, entered by staff, so the entry list stays complete and a paper entry cannot miss out on a bib or a timing record. The test at checkpoint includes paper and phone entries, not a demo with only online users. Race morning staff work from one list, however the entry arrived.