A facility owner wants customers to book out a batting cage, field, or court online and walk in without anyone at a front desk. This feels doable. A reservation comes in, a PIN goes out. One trigger, one action, one integration point between the booking system and the lock. What other things are there to consider?
- What happens when the customer reschedules or cancels ten minutes before their session?
- What if a card payment fails after the PIN already went out?
- What if two bookings somehow overlap on the same space?
- What if the lock loses its internet connection for twenty minutes right at check-in time, or the customer shows up forty minutes early because they left work sooner than planned?
A facility with three entrances and six individually controlled spaces makes those questions a bit more complicated. Maybe a firmware update quietly changes how a lock's API responds, or a customer stands outside a door that won't open with nobody around to call at 11:30 pm.
Hopefully this doesn’t deter you from making the jump to automating your facility, because the upside in cost/time savings + revenue opportunity can be huge. Poking holes in the setup is only meant to ensure the experience is built and deployed in a way that your customers have the best experience possible.
Map what the access system actually needs to do
Before comparing approaches, write down what you're asking the system to handle. Facilities skip this more often than you'd expect, which is usually why a build runs over budget or a purchased system feels like it doesn't fit.
Worth answering before you evaluate anything:
- Is access tied to one-time bookings, recurring memberships, staff roles, coaching privileges, or some mix of all four?
- Are you managing one front door, or a network of exterior and interior doors with different permission levels?
- Does a customer need access to the building, a specific room or field, or both?
- Will people get in with PINs, mobile credentials, cards, fobs, or some combination?
- How far in advance should access open, and how long should it stay active after a session ends?
- What should happen after a cancellation or a failed payment?
- Do you need remote unlock, lockdown, or the ability to revoke a credential the moment something goes wrong?
- What access logs and alerts does your insurance carrier, landlord, or own peace of mind require?
- Should a booking also trigger lights, HVAC, or equipment like ball machines or simulator software?
- What has to keep working if the internet drops?
- Who is actually on call after hours, and what can they do remotely?
Map the normal booking journey first, then note every exception within the journey that you can think of.
What building your own system can offer
Building isn't a reckless choice, and it isn't automatically the wrong one. Operators who go this route usually want something a packaged product doesn't quite offer: tighter control over the customer experience, the ability to support an unusual membership structure, or a way to tie access into specialized equipment.
For example, a multi-location batting cage operator with a loyalty tiers grants members priority booking on premium cages, staff who need different access windows for cleaning and maintenance, and a batting cage software that should power on the moment a cage unlocks. A custom workflow can coordinate all of that in ways a general-purpose access product might not support out of the box, because it's built around this facility's particular rules instead of the average customer of a mainstream platform.
Custom development tends to make more sense when several of these are true:
- Your access rules are highly complex.
- Existing products can’t support a workflow you consider essential.
- You have technical staff or a development partner you trust to maintain the system long term.
- Your business can support ongoing software maintenance.
The scale of your operation justifies the investment.A single-location facility with one entrance rarely meets those requirements. A regional operator with a dozen locations and a genuinely custom membership model sometimes does.
The responsibilities that come with building
Generating a PIN when a new booking comes in is straightforward. A system that actually holds up in production also has to remove that PIN when the booking is canceled, reissue it correctly when a customer moves to a different court, avoid creating duplicate credentials when a webhook fires twice because a network request timed out and retried, and tell somebody when a lock never received the update in the first place. Not that this is insanely complex, but this does have to be built, tested, and monitored.
If you build the system yourself or work with a development partner, your responsibilities extend well beyond the initial integration. You’ll need to secure customer credentials, keep the APIs and webhooks connecting your booking software and locks reliable, and correctly process cancellations, schedule changes, and delayed or duplicate events.
You’ll also be responsible for hardware compatibility, firmware and API updates, system testing, access logs, remote overrides, and alerts when something fails. Then there are the operational questions: What happens during an internet or power outage? Who helps a customer who can’t get in? And is the system documented well enough for someone else to maintain if the original developer leaves?
That last one matters more than it sounds. Many custom access setups are built by one motivated person, whether an owner, an operations manager, or a contractor, and they work fine until that person is unavailable and a lock starts behaving strangely on a Saturday morning with a full schedule of bookings.
What buying an existing system can offer
A supported access platform has usually already solved the problems described above, because a vendor building for many facilities has run into the edge cases you haven't hit yet. That would include tested hardware integrations, consistent credential creation and revocation, audit logs, system monitoring, automated updates, and tools for managing access remotely.
You may also receive broader hardware compatibility, implementation guidance, and a defined path for escalating technical issues. These capabilities can shorten the time to launch and make ongoing maintenance more predictable, but they shouldn’t be assumed. Confirm exactly what the provider supports, monitors, and takes responsibility for before committing.
Buying doesn't mean plug-and-play, though. You still need compatible locks and readers, a competent installation, proper configuration, testing before you rely on it for actual customers, internal policies for staff, training so your team can actually use the admin tools, and an after-hours process for when something goes wrong at 11 p.m. A vendor's product being reliable in general doesn't mean it's been reliable at facilities like yours, so the evaluation work doesn't disappear just because you're not writing code.
Compare the total cost of ownership
For a custom build, look beyond the initial development work. Your costs may include hardware and installation, cloud infrastructure, automation-platform fees, security reviews, monitoring tools, ongoing testing and maintenance, and after-hours support. You should also account for the impact of access failures and the time required to bring a new developer up to speed if the original one moves on.
A purchased system has its own costs beyond the advertised subscription. Include hardware and installation, setup or onboarding fees, per-door or per-location charges, contract minimums, integrations, and the level of support your facility will actually need. Then consider how those costs could change as you add doors, open new locations, or eventually switch providers.
Questions to ask a vendor or development partner
Before committing to either path, get clear answers on:
- Which locks, readers, and access-control systems does this actually support?
- Is the connection to your booking system direct, middleware-based, or fully custom?
- What happens automatically when a booking is changed, canceled, or refunded?
- Are credentials unique per booking and time-limited?
- Can access be scoped to specific doors and spaces, not just the building?
- What happens during an internet or power outage, and are events queued and synced once service returns?
- Are access attempts logged, and for how long?
- Can staff revoke access or unlock a door remotely, and how quickly?
- How are errors surfaced, and to whom?
- Who actually supports the customer standing at a locked door?
- How are software, API, and firmware changes rolled out and communicated?
- Who owns the custom code and documentation if you built anything in-house?
- Can your data be exported if you switch systems later?
- What's the full cost, including hardware, setup, subscription, support, and future expansion?
- What happens if you change your booking software or hardware down the road?
Conclusion
A single-entrance facility with a handful of bookable spaces rarely has much to gain from building this from scratch, and a lot to lose if the one person who built it moves on. A multi-location operator with unique rules and the technical team to support them has a stronger case. Most facilities in between are better served buying a supported platform and verifying it actually does what they need. Then, take chances on building additional features (start small). Reliability, safe egress, and a clear answer for who responds at 11:30 p.m. will take priority, while features with less impact should carry less weight.
