LIFT & FIT Private Space: building the system behind a private gym.
A booking, payment, account, and access platform for a real-world service where software has to coordinate money, time slots, and physical entry.
LIFT & FIT Private Space is a private fitness studio in Roznov pod Radhostem where a customer books a time slot, pays online, receives a PIN code, trains without a shared gym floor, and leaves the space to lock automatically. The public promise is simple: choose a time, get access, train in privacy.
Behind that simple promise is a production system with stricter constraints than a normal brochure site. It handles reservations, packages, payments, customer accounts, transactional email, PIN access, admin workflows, and operational monitoring. When software controls a real time slot and a real door, reliability and security are not secondary concerns. They are part of the product.
The business model shaped the architecture.
This was not just a calendar. The service needed to sell exclusive 75-minute access windows, prevent double-booking, support one-off visits and prepaid packages, communicate clearly in Czech, and keep the operator in control without requiring a receptionist at the door.
The core product questions were practical:
- Can a customer see availability and reserve a slot without friction?
- Can payment state, booking state, and access state stay consistent?
- Can the operator handle cancellations, customer issues, packages, and schedule changes quickly?
- Can the system avoid exposing sensitive access details beyond the rightful customer and admin?
- Can failure in a provider, email, payment notification, or lock API be retried safely?
The platform is a small operations stack, not a single page.
The implementation uses a modern full-stack architecture with typed boundaries from the customer UI down to provider integrations. The point was not to collect fashionable tools. The stack was chosen because the domain is state-heavy: bookings, payments, passes, customers, access grants, audit events, and admin actions all need clear contracts.
Physical access changes the security posture.
A normal e-commerce bug might affect a receipt, a cart, or a user session. In this system, a bug can affect access to a physical space. That changes how the software has to be designed.
PIN codes, booking ownership, cancellation rules, calendar exports, account pages, admin views, and provider callbacks all need to be treated as security-sensitive surfaces. The design separates public browsing from authenticated customer data, keeps provider state transitions explicit, and avoids making external services the source of truth for money or access decisions.
Money, time, identity, and access are separate concerns.
A booking can exist before payment settles. A pass can be inventory. A PIN can have a lifecycle. Keeping those concepts separate makes failure handling clearer.
Access details are never treated as ordinary public content.
Customer ownership, authenticated account views, admin permissions, and provider callbacks are part of the application design, not add-ons.
Payments are treated as state, not as a button.
GoPay integration is modeled as a stateful backend flow. A payment notification is not blindly trusted as the final answer; it is a signal to reconcile server-side state. This keeps the booking lifecycle deterministic when callbacks repeat, arrive late, or need to be retried.
The same thinking applies to prepaid passes. A package is inventory. Using a pass has to be consistent under concurrency, cancellation, expiration, and admin handling. These are the details that make a simple booking product feel boring in the best possible way.
Access is issued through durable work.
Door access is handled as a lifecycle, not as a synchronous afterthought. The application persists the booking and related intent first, then background work can issue, reconcile, or revoke provider-side access. That separation keeps customer-facing requests responsive while making provider failures retryable and visible to the operator.
This is the difference between "call an API" and "operate a system." A production system needs to know what happened, what still needs to happen, and what is safe to retry.
The admin side matters as much as the customer flow.
Private Space is operated by people, not by a spreadsheet. The admin surface supports the day-to-day work: seeing bookings, managing slots, handling customers, reviewing payment/access state, and changing operational settings without editing code.
Good internal software should reduce operator uncertainty. It should show the current state clearly, make exceptional actions deliberate, and keep sensitive operations behind authenticated, role-aware boundaries.
What we intentionally do not publish.
This write-up stays at a product and architecture level. We do not publish lock identifiers, provider credentials, webhook verification details, raw payment payloads, PIN formats beyond the public product behavior, admin paths, operational runbooks, customer data, or infrastructure secrets.
The useful public lesson is not a provider recipe. It is the engineering pattern: model money, time, identity, and access as durable state; isolate side effects; verify ownership; make retries safe; and give the operator enough visibility to run the business.
Why this belongs next to security research.
Gloryck's work is not only low-level research. We also build production software for companies where business logic, trust, and security meet. LIFT & FIT Private Space is a useful example because the project combines full-stack delivery with practical security thinking: payments, authenticated accounts, physical access, operational tooling, and real users.
That combination is the point. The strongest systems work is not just code that compiles. It is software that respects the business model, handles edge cases, protects sensitive data, and remains understandable when something goes wrong.