The interface doesn’t end at the screen.

I left the old Wix website untouched for about a year. I’d also put BayFlow on hiatus. Coming back to the work at the start of September wasn’t a gradual expansion of the original project. It was a decision to try again under very different circumstances.

We couldn’t pay our leases, and the landlord was making us leave. If this was going to be our last winter season at Airways Mall, I wanted to make it as financially painless as I could for my family. There was no budget for any of the things I wanted to revamp.

I hadn’t wanted to be part of the business from the beginning. Most of my ideas about how the system should operate had been rejected, and I’d felt discouraged about continuing. Most of what you might see on the old website was dictated by my family. I designed and managed it, but that didn’t mean I had authority over the decisions it communicated. My expertise had grown while I was working on other projects, and I wanted to see what I could improve with it here.

BayFlow wasn’t a new idea from that week. I’d started it last year and worked on it for about two months before putting it aside. I already knew what I wanted to implement because I’d been working within our actual operations for a while. The two screens here are from those early iterations, not the current product.

The starting point was the Wix website I’d designed and managed, alongside Microsoft Bookings. We used Bookings for about a year before switching to BayFlow. It solved our main pain points within the constraints we had. It wasn’t a random choice, and neither was the decision to build something ourselves.

One interaction I definitely wanted was click, drag, and release to create a reservation directly on the schedule. I wanted to choose the space and block out the time where I was already looking, with the reservation taking shape on the schedule itself.

Among the other booking platforms I researched, SuperSaaS and Microsoft Bookings stood apart from the pattern I kept encountering: services or products with a predetermined, approximate duration. That wasn’t the whole problem I was trying to solve. I needed to manage time and physical spaces as the day actually unfolded.

I watched demo videos as part of that research. Lightspeed felt too expensive for us and much broader than what I needed. Watching those workflows, my reaction was: damn, this UX doesn’t fit how we run this place. That’s my assessment of the fit for our operation, based on the demos I watched.

BayFlow has a narrower priority: managing reservations, time, and spaces when the plan and the live situation don’t line up neatly. Indoor golf is the business I’m building it around. I can see the same question being relevant to places like escape rooms, but that’s a direction to explore, not something I’ve validated by building for them.

When I picked BayFlow back up this September, I wasn’t starting from a blank brief. I was returning to those decisions alongside the website redesign. I spent something like four or five days working straight through to finalize the redesign and transfer.

The work touched the website, room information, booking, food and drinks, and the instructions people encounter when they arrive. I couldn’t treat each one as an isolated page. Someone makes a choice online, then walks into a physical space expecting that choice to make sense.

Guest count is one example. Counting only the people playing golf leaves out the friends who come along. The booking flow needs to describe the actual group entering the space, because that number affects which room can accommodate them.

The instructions at the door belong to that same experience. A request for clean shoes needs to explain why it matters: debris can affect simulator shot readings. The wording has a job to do at a particular moment in the visit.

BayFlow connects that online choice to a reservation staff can understand and manage. This is where interface decisions become operational decisions: what someone books has to make sense when they arrive, and the information can’t stop being useful once they leave the website.

I’ve done this work alone, with AI helping me code and flesh out my UX design decisions. I would’ve loved to work with other people. Working alone wasn’t the ideal setup; it was the situation I had.

As of this update, I think BayFlow is stable enough to call the MVP complete. That’s my assessment of where it is today. It doesn’t mean every part of the work is finished, and it doesn’t prove the redesign will change the business’s financial situation.

For now, the question I keep coming back to is practical: does the next part of the visit support what the previous part promised? That’s what I’m trying to connect, from the website to the booking to the room itself.