This one started with a simple brief: make it easier for people to book the dog park online.
What we ended up building books, pays, unlocks a physical gate, refunds automatically when something goes wrong, and tells the council exactly what happened. All without anyone being at a desk.
The problem
Y Bark is a dog park in Holyhead run by the town council. Before we got involved, every booking meant a staff member opening the iglooaccess app to generate a PIN for the gate lock, copying it, and typing it into an email to the customer. Hopefully without a typo.
Staff handled bookings from the local pancake cafe. The cafe had opening hours. The dog park didn't. Saturday morning slot at 7am? You're waiting until Monday. A lot of people didn't wait. They went somewhere else.
It was a system that worked for a handful of bookings a week. It was never going to take Y Bark anywhere.
What we built
Customers now go to ybark.holyheadcouncil.co.uk. They see live availability up to eight weeks ahead, pick a slot, choose how many dogs, and pay via Stripe. Within seconds, they get a unique 4-digit PIN by email. That PIN is live on the gate lock for exactly their booked window. They walk up, type it in, walk in.
No phone calls. No staff involved. No waiting for a cafe to open.
Behind that booking page, six systems are doing their jobs quietly. Bookings land in the council's shared Microsoft 365 calendar through the Graph API. Staff can see and manage them in Outlook like any other appointment. The Igloo smart lock provisions its own PINs via the iglooaccess bridge. Stripe handles payment, with an automatic refund if anything fails before the PIN reaches the lock. Emails go via Microsoft Graph from the council's own domain.
No bespoke admin system for staff to learn. Block out maintenance time? Add it to the Outlook calendar. That's it.
The moment that showed it worked
Three weeks after launch, the gate's internet bridge dropped offline overnight. One booking came in during the outage.
The system detected the failure, refunded the customer automatically, logged what had happened, and resumed normal operation by the next morning.
The council found out through the audit log. Not through a complaint. Not through a customer standing at a locked gate at six in the morning with a dog that needed a run.
That's the bit that matters. The happy path is easy. Any competent developer can build a system that works when everything works. The work is in what happens when something breaks. Does it fail gracefully? Does it make the customer whole? Does it tell you what happened without you having to be there?
Week one by the numbers
No public promotion. Word of mouth and organic traffic only. Seventy-two bookings processed without a single member of staff doing anything beyond what they were already doing in Outlook.
What this means for other businesses
Y Bark is a dog park. But the pattern applies to a lot of service businesses still doing this manually: customer books online, system handles fulfilment end to end, things fail gracefully when they go wrong.
If your business takes bookings, confirms appointments, sends reminders, or manages access to something physical, there's a version of this that works for you. It doesn't require enterprise software. It doesn't require a development team to maintain it. It runs, it handles the edge cases, and it tells you what happened.
The full case study is on the site if you want more detail on the build.
Could your business run like this?
If something in your operation still relies on someone being at a desk during opening hours, we should talk. Get in touch or read the full Y Bark case study to see exactly how it was built.
Get in touch Read the case study →