A coworking space. A connected system.

The rooms in each location are represented as areas with capacity, opening hours and booking rules. The original floor plans also appear in administration, connecting the spaces people recognise with the information needed to manage them. A room is both a physical place and a resource the platform can describe.

The spatial model above is built from those floor-plan paths. Selecting a location changes the same underlying geometry that staff see in the application. Its furniture and activity are illustrative; the rooms and wall layout are source material from The Factory.

A booking depends on more than an empty slot. The platform checks opening hours, closures, existing reservations and the area’s capacity. Hourly bookings are checked for overlapping times; other booking types also account for active subscriptions. The purchase flow carries the selected space and its conditions into a Stripe-backed checkout.

The rule below is a small part of the actual booking implementation. It shows why availability must be decided against the space’s capacity, not inferred from a calendar tile that happens to look empty.

if (overlappingBookings >= area.seats) {
  return {
    available: false,
    error: 'overbooking'
  }
}

Membership is represented as something operational. A member sees the current booking, can reserve the next day, and can read the resources available to use. At renewal, the subscription worker retires the previous resource allocation and creates the next one with its own expiry.

The account can therefore describe what a member can use now, as well as what they have purchased. The focused view below assembles the original booking and resource components with a fictional subscription and balances. It leaves billing and profile details aside to show the connection between a reservation and the services it grants.

The same platform becomes the administration centre. Staff can change location and date, read bookings against the original floor plans and open the associated area information. The overview refreshes every minute, keeping this operational view connected to the underlying records.

The administration shown below uses the original controls and SVG plans. Switch between Bergamo and Seriate to inspect how the same view follows two different spaces. The markers and bookings are fictional; the plans and interface are real.

At a location, the relay checks permissions against the member’s identity and current context. Door access and Wi-Fi use the same authorisation function with different access types. The captive portal registers devices, applies the account’s device allowance and authorises the connection through UniFi.

The two calls below show that shared decision. They do not imply that every physical access device is UniFi. Successful door checks are recorded as activity; unsuccessful checks become warnings.

const response = await authorizeUser(locationId, identifier, 'door')
const userAuth = await authorizeUser(locationId, pin, 'wifi')

Printing is deliberately local. The member portal first tries to discover the location service; away from its network, the print interface is unavailable. On site, it loads the printer’s status and the member’s remaining colour and monochrome pages. The original local interface below runs with a fictional printer and allowances. It cannot send a file or operate a device.

For a real job, the relay checks the allowance before submitting a PDF through IPP. It handles printer compatibility and records the use only when the request succeeds. Sulture’s work connects the member account, the service running at that location and the physical printer, rather than treating printing as a remote upload button.