Why Ox Ranch is moving its waivers to Waiver.com

Ox Ranch is a hunting and outdoor ranch in Texas, and it is the reason Waiver.com exists. Its owner built a waiver and check-in tool for the ranch years ago, watched staff live with it, and decided the next version should be a product that other activity businesses could use too. That makes Ox Ranch the launch partner and customer number one. This is the story of what the ranch was running, why it is being retired, and what the new setup looks like. The migration is still in progress, so there are no before-and-after numbers here and no quotes; those can come when they are real.

What the ranch was running

The legacy system was a set of PHP pages on a single server with a MongoDB database behind them, written for the ranch and never packaged for anyone else. It grew into three websites that shared one database. A staff portal held the template builder, the list of signed waivers, PDF and CSV generation, and the tools for creating event groups and emailing invitations. A kiosk site, locked behind a PIN, let guests at the ranch pick a template and sign on a tablet. A third, older site handled the hunting-tag side of the operation and exposed a small lookup API that found a guest's signed waiver by the last digits of their phone number and read the field values out of it.

In production the ranch used two templates: one for adults and one for adults signing with children under eighteen. The builder that produced them supported a long list of field types, from name, date of birth, address, phone and email to signature, initials, checkboxes, multiple choice, custom questions, headers, images and a conditional repeater for adding children. The adult form asked for a signature three times, once for the release itself, once for a firearms certification and once for an agritourism acknowledgment, followed by a driver's licence number, a hunting licence number and a citizenship question. It was a real, working waiver, and by the time of the review the database held on the order of thirty-two thousand signed copies.

The event side was the most thoughtful part of the old system. A staff member could create a waiver group for a date and location, add invitees, send each one a personal link, and then watch a management screen with totals for invited, signed, pending and bounced, with tabs for invitees, submissions and the mail log and a button to remind everyone still pending. That screen is the one thing about the legacy system that the new product deliberately keeps the shape of.

Why it is being retired

The problems were the ordinary problems of a home-built tool that outlived its first author. There was no version control, no test suite and no framework, so every change was risky. The list of signed waivers, the screen staff used most, ran a database query so slow that in the review it never finished loading. Each event group was implemented by generating a new PHP file on the server, which worked until someone needed to change how all of them behaved. Two products, the waiver system and the tag system, were tangled in one admin with the same menus, so a receptionist looking for a signed form navigated past species lists and taxidermy emails to get there. The admin theme was a purchased dashboard kit whose demo widgets were still on the home page. Staff described the whole thing, fairly, as hard to use.

None of that is unusual. Most activity businesses that outgrow paper end up with something similar: a form builder someone set up, a spreadsheet export, a shared inbox of PDFs, and a growing sense that the system is one departure away from being unmaintainable. The ranch's situation was simply a more complete version of it, which made it a good first test of what a replacement has to do.

What the new setup looks like

The Waiver.com account for the ranch is organised around the same two documents, rebuilt in the template builder as blocks: the release text, the firearms certification and the agritourism acknowledgment each as their own block with its own signature or initials field, the identity and licence fields as typed fields with validation, and the children handled by the guardian and minor flow rather than a repeater bolted onto an adult form. Each template is published as a version, so a change to the wording produces a new version and every existing record keeps the text its signer actually saw.

Guests sign in the same three ways they did before, without the seams. A shared link goes out ahead of a visit. The tablet at the ranch runs in kiosk mode, which presents the template picker and hands the device back to the desk after each signature without a PIN screen the guest has to get past. For a booked hunt or a group day, staff create an event, add the invitees and send personal links, then follow the same invited, signed and pending counts they are used to, with reminders for the people still outstanding. At arrival, check-in finds the record by name, phone or email in a search that returns while the guest is still standing there.

The hunting-tag system stays with the ranch, and it still needs to find a guest's waiver by phone number. That is what the public API is for: the tag system will call Waiver.com to look up the participant record and read the fields it needs, instead of querying a shared database directly. Webhooks let the ranch's own tools hear about a new signature the moment it happens rather than polling. This is the reason the API and webhooks were built as core features from the start rather than added later.

The migration, honestly

Three pieces are still ahead. The historical signed waivers have to be imported, which means an adapter for the legacy MongoDB database that maps its field names to the new record shape, brings the signed PDFs across from the ranch's file storage, and preserves the original signing dates so a record from several seasons ago still says when it was signed. The signing links and the kiosk have to be cut over on a day the ranch chooses, with the old system left readable until the new one has run through a busy weekend. And the ranch's staff have to learn a new front desk, which is where the how-to guides on training a team and switching providers came from.

When those steps are done, this page will say so, and it will be able to report what actually changed. Until then it is what it says it is: a launch partner's reasons, and a plan.

What another business can take from it

The ranch's list of requirements is a good checklist for anyone replacing a system they built themselves. Bring the history with you, or you will keep the old server alive forever. Keep the version of the form with each record, because the question after an incident is always what the person signed. Separate the waiver from the other things your business tracks, so the person at the desk sees only what they need. Give the event and group workflow real status counts and reminders, because that is where staff time goes. And make sure the new system can be asked questions by your other tools, through an API, rather than by opening its database. Those are the things Waiver.com was built to do first, because a real business needed them first.