Oscar Hedaya on Building The Space Safe

Oscar Hedaya on Building The Space Safe

Oscar Hedaya did not set out to put a screen on a metal box. After a theft, he went looking for a safe he wanted to own and came away convinced that the whole category needed a different product.

In episode 105 of Venture Step, Hedaya explains what happened next. The concept was easy to describe: combine a physical safe with cameras, sensors, multiple identities, an app, and software updates. The build was not easy. Every added capability created another interface that had to work with the enclosure, lock, power system, firmware, operating system, network, cloud service, mobile app, factory, and customer.

That systems problem is the real story of The Space Safe.

The founder saw a gap after a theft

Hedaya describes more than 15 years in product development and manufacturing, including earlier work around electric scooters. He was drawn to categories where the product felt older than the rest of a customer's life.

The safe idea became personal after a theft. He wanted a product that could do more than resist entry. He wanted to know when someone approached it, who opened it, what happened around it, and whether the product could improve after it left the factory.

The interview records that origin in Hedaya's own words. It does not prove that a particular safe meets a security standard or fits a buyer's risk. Founder motivation explains why a product exists. It does not replace testing.

Existing parts do not create an integrated product

A camera, fingerprint reader, touchscreen, accelerometer, battery, lock motor, and WiFi module are all mature components. The hard part is making them behave as one dependable product.

Hedaya describes the printed circuit board assembly as the coordinating brain. The device also needs drivers and firmware so every component can report its state and receive the right command. The system must know whether the door is open, whether the lock moved, whether a credential was accepted, whether power failed, and whether a sensor reading deserves an alert.

flowchart TD
    A["Steel enclosure, door, lock, and anchors"] --> G["Connected safe system"]
    B["Power, battery, and charging"] --> G
    C["Sensors, cameras, display, and biometrics"] --> G
    D["Firmware and operating system"] --> G
    E["Mobile app, identity, and cloud services"] --> G
    F["Factory tests, updates, and support"] --> G
    G --> H["Physical delay and access"]
    G --> I["Detection, evidence, and notification"]
    G --> J["Recovery and long-term operation"]

A change to one component can travel through the whole diagram. A larger battery affects heat, enclosure space, charging, firmware, testing, shipping, and service procedures. A new camera affects power, storage, privacy, network load, app behavior, and data retention. A lock change affects mechanics, control logic, fallback access, and factory calibration.

This is why a connected hardware company cannot hand a collection of parts to a factory and expect the factory to resolve product architecture.

The product adds awareness around the enclosure

The current Space Safe product page describes two cameras, a touchscreen, PIN and fingerprint access, tamper sensing, temperature and humidity sensing, a backup battery, a mechanical key, app notifications, and over-the-air updates.

The Space App page describes activity history, camera streaming, shared access, five-minute temporary PINs, lockdown, an alarm, and environmental notifications.

Those features add observation and control. They do not establish burglary resistance, fire resistance, reliable emergency delivery, or cybersecurity. Each property needs its own evidence.

UL Solutions identifies UL 687 as a standard for burglary-resistant safes. Its public material also distinguishes residential security containers and related anti-theft products. The exact standard, class, model, and current listing matter. Weight, steel thickness, cameras, biometrics, price, and an app are not substitutes.

The current commercial state needs a date

As of July 27, 2026, the product page lists The Space Safe at $1,299 and describes it as a preorder. It displays December 2026 for the United States and January 2027 for Europe, with another October 2027 option also visible.

The page also contains internal inconsistencies. One section lists the product around 60 pounds while another says around 55 pounds. The technology section says 180 fingerprints, while the product answer below it says 100. A buyer should confirm the specification for the exact production unit and order.

SPACE's March 2025 update describes years of development, manufacturing-partner problems, financial losses, a price increase, and a search for investment and production support. A January 2026 update says the company built its own update system and was still testing printed circuit board assemblies.

These posts are useful because they show the distance between a working concept and repeatable production. They are company accounts, not independent audits or delivery guarantees.

OTA updates create a responsibility, not permanent security

Hedaya returns to updates throughout the interview. His argument is sensible: customer use reveals bugs and awkward workflows, while software allows the product to improve after shipment.

The ability to update also creates a new trust chain. The vendor needs to protect development systems, authorize releases, sign packages, deliver them safely, verify them on the device, recover from failure, communicate vulnerabilities, and define when support ends.

NIST IR 8425 treats the consumer IoT product as more than the device. It can include companion applications and backend services. NIST IR 8259B adds the nontechnical work, such as documentation, vulnerability intake, update information, and end-of-support communication.

An update mechanism is valuable when those responsibilities are real. It is not proof that every future update will be secure, timely, successful, or available.

A connected safe protects a second asset

A conventional safe reveals something through its location and physical use. A connected safe can create a much richer record.

SPACE's March 2023 privacy policy says the service may process camera footage, location, access time, user identity, device movement, software updates, screen activity, settings, failed PIN attempts, images, connected phones, and recovery answers. It says recordings may be kept locally and in the cloud.

The policy also contains references to wallets and public blockchain analysis that may reflect an older or broader service design. Its age and breadth make direct product questions necessary. The policy should not be treated as a verified architecture diagram.

The central privacy point is durable: the safe is not only protecting valuables. Its system may hold information about where those valuables are, when they are accessed, and who can reach them.

Emergency language needs restraint

The product and app pages describe sending a text to emergency services. They also say the feature is still being tested nationally and place responsibility on the user.

911.gov advises calling 911 when possible and texting when a call cannot be made. Text-to-911 availability varies by community. SPACE's January 2024 terms say features including text 911 and panic PIN are not monitored.

That is not the same service as a monitored alarm center. Public descriptions should not imply automatic dispatch or guaranteed delivery.

The useful founder lesson is integration

Hedaya's story is not a general claim that established companies cannot innovate. It is a concrete account of what changes when a physical category becomes a software-supported service.

The product team owns the interfaces. The company owns the support clock. Security claims need exact evidence. Smart features create new failure modes alongside new capabilities. Privacy becomes part of the storage decision.

That is a more useful way to understand The Space Safe than either dismissing it as a screen on a box or accepting every feature as proof of security.

Before ordering any connected safe, start with the asset, the loss scenario, the exact physical rating, the anchoring plan, recovery under power and network loss, the privacy record, the update commitment, and the vendor-exit plan. The [[How to Evaluate a Smart Safe Before Buying One|smart-safe buyer guide]] provides that framework.

AI assisted with research organization and drafting. Dalton Anderson remains responsible for the analysis, source boundaries, and publication decision.