Denver, Colorado + Remotehello@houseofgiants.com

Case Study — PropTech Platform

2025–2026

PebbleSpaces

Stabilizing a Physical-Space Platform

PebbleSpaces looked close to launch: a smart-workspace product for booking, paying for, unlocking, and operating private spaces. The hard part was making the software dependable when payments, locks, sensors, devices, vendors, and support all had to agree.

≈200ms

Door Unlock Response

≈100ms

Occupancy Signal Response

6+ Hours

Longest Booking

Launch StabilizationPlatform ArchitectureHardware/Software IntegrationEngineering Execution
PebbleSpaces
Dom worked flawlessly with the other vendors, even when they made it more difficult than it needed to be.

Joe

Founder, PebbleSpaces

The Challenge

Defining the Problem

The prototype looked like a booking app. The business needed something more demanding: customers had to scan, book, pay, unlock, use a space, and leave while the system kept track of real-world state. If it failed, the problem was not a cosmetic bug. It could mean a locked door, a stale occupancy state, a failed payment, or an operator with no clear recovery path.

Our Approach

We sequenced the work around launch risk. First, protect the path customers and operators would touch: booking, payment, admin setup, access control, occupancy, live sessions, deployment, and QA. Once that path could carry real usage, the work expanded into the operating architecture for a hardware/software business.

The Solution

House of Giants helped PebbleSpaces move from prototype stabilization to platform architecture. We connected the core customer and operator workflows across booking, payment, access, session state, support, and multi-location operations. The product had to stay useful when real people, real spaces, and real devices were involved.

Project Info

Client

PebbleSpaces

Smart-workspace platform for booking and operating private physical spaces

Role

Launch StabilizationPlatform ArchitectureHardware/Software IntegrationEngineering Execution

Tech Stack

Next.jsTypeScriptNode.jsPostgreSQLPayment ProcessingAccess ControlOccupancy SignalsAnalytics

The Problem

The booking flow was only the visible part.

PebbleSpaces came to House of Giants with a product that created real opportunity and real launch risk.

The founder had a working-looking prototype for booking private physical spaces. Customers would scan, book, pay, unlock, use the space, and leave. On paper, that sounds like a booking app. In practice, it was a hardware/software product with payments, physical locks, occupancy signals, timers, QR codes, locations, events, admin tools, support fallbacks, device failures, and vendor dependencies.

If an unlock failed, someone could be standing outside a space they paid to use. A stale occupancy state could make the product lie about availability. A router failure could turn into a support problem. A QR code could become an operating decision when pods move between locations.

The first engagement had to protect that launch path before the team could make the larger platform calls.

What We Did

Stabilize first. Rebuild second.

We did not treat the inherited prototype like a blank page. That would have been easier for us and worse for the business.

The launch-critical path came first: booking, payment, admin operations, access control, occupancy state, live sessions, deployment, and QA. The point was not architecture purity. It was giving PebbleSpaces enough production confidence to launch, learn, and avoid turning every real-world failure into a customer incident.

After the launch path stabilized, the question changed from "can this launch?" to "what operating system does this business need?" The larger rebuild moved the product away from a fragile app shape and toward an operating layer for locations, pods, events, devices, and support.

Deliverables

What We Built

01

Admin Operations

Tools for managing the day-to-day work behind each space, location, and session.

02

Booking and Payment Flow

A customer path for finding a space, booking time, paying, starting a session, and ending it cleanly.

03

Access-System Integration

Coordination between the app and physical access systems so the experience worked in live spaces.

04

Occupancy and Session State

Operational state that helped the platform understand when a space was in use, available, or needed attention.

05

Event and Location Tooling

Tooling for running spaces across locations, events, reservations, and changing physical setups.

06

Support and Recovery Workflows

Clear customer and operator paths when something needed attention before, during, or after a booking.

Proof

When software opens doors, mostly working is not enough.

In a normal SaaS product, a bug might mean a confused user or a failed form submit. That is bad enough.

PebbleSpaces had a different failure mode. The product touched doors, spaces, payments, devices, and people standing in real locations.

The use cases stretched quickly: business travelers taking 5 AM meetings, late-night voice recording sessions, and bookings lasting more than six hours. One 11 PM session came from a Comic-Con YouTuber with more than 250K subscribers. Different people were using the same product for very different reasons, but the thing they kept coming back to was privacy on demand.

That made reliability part of the product experience. If access, availability, or support drifted from reality, the promise of a private space broke. The platform had to be built for recovery, not only for the happy path.

How We Did It

From stabilization to platform

The work moved in phases: protect launch, rebuild the operating layer, support rollout pressure, then stay close as the product kept changing.
Stabilize the launch path
01Phase 1

Stabilize the launch path

The initial engagement focused on the smallest set of things that had to work for real customers and operators: booking, payment, admin setup, access control, occupancy, live sessions, deployment, and QA.

  • Six-week launch window
  • Inherited prototype stabilization
  • Booking/payment hardening
  • Access-system coordination
  • Production QA and deployment
Rebuild the operating architecture
02Phase 2

Rebuild the operating architecture

After the launch path was stable, the platform needed to support the real operating model: locations, events, sessions, device state, background work, live updates, and admin recovery.

  • Platform rebuild
  • Database and state-model cleanup
  • Queue-backed background work
  • Real-time operational state
  • Unified booking/admin workflows
Support multi-location and event operations
03Rollout

Support multi-location and event operations

As the business moved beyond the first launch, the questions became operational: how to add locations, move pods, manage reserved usage, recover from offline devices, and make the product usable for the people running it.

  • Multi-location operating model
  • Event deployment workflows
  • Pod identity and QR-code decisions
  • Support and fallback paths
  • Remote device-state awareness
Stay useful as the product changed
04Advisory

Stay useful as the product changed

The relationship did not end when the app shipped. HoG stayed close enough to advise on hardening, security posture, replacement-system context, and the next version of the operating model.

  • Architecture review
  • Security and hardening posture
  • Replacement-system context
  • Pragmatic founder support

Real Usage

Fast access feedback, low-latency occupancy updates, and long private sessions all had to feel like one simple experience. Users ranged from business travelers taking 5 AM meetings to 11 PM voice recording sessions for a Comic-Con YouTuber with more than 250K subscribers.

Door Unlock Response
≈200ms
Occupancy Signal Response
≈100ms
Longest Booking
6+ Hours

Why It Worked

The product lived in real locations. The architecture had to be operational.

Launch risk and platform risk were different problems.

Booking, payment, access control, occupancy state, live sessions, deployment, and QA needed immediate hardening because customers and operators would touch them first. Pod identity, maintenance state, event usage, manual fallbacks, vendor coordination, support workflows, and security posture needed enough architecture attention to avoid painting the product into a corner.

We stabilized before we rebuilt. We treated hardware as part of the product. We kept business reality close to engineering decisions. We built for recovery because spaces, hardware, networks, and vendors do not behave perfectly.

PebbleSpaces did not need a generic SaaS team. It needed product engineers who understood that software, hardware, operations, vendor dependencies, and founder judgment were all part of one system.

Ready to build your product the right way?

Bring the product, the roadmap, or the mess. We'll help you figure out what it needs and ship it.