Who this is for

You don't need a background in physical security, locks, or cloud software. If
a word is jargon, we define it before we use it.

• Residents and everyday users who open doors with a phone
• Property admins who run a site
• Solution architects who fit OpenApp next to hardware and other software
• Investors and stakeholders who need to know what the product is

We stay on access control: who may enter, how, when, and how you see what
happened. Not commerce, commercial packaging, vendor comparisons, or
installer manuals.

A visitor at the lobby

Each side of the call

A resident coming home

A guest for the weekend

What the guest's phone shows

The operator's Tuesday

Four moments, one pattern

Visitor, resident, guest, operator. Same sign, same doors, same rules.

Arrive at a place, prove you belong (or ask someone who does), pass a
barrier, leave a record.

OpenApp starts there, then attaches hardware as modules.

The rest of this deck explains the ideas behind what you just saw.

You already do access control

Five questions every opening must answer

1. Who is asking? A resident, a guest, a courier, a system.
2. Where? Lobby, garage, apartment door, locker.
3. When? Tuesday 14:00 isn't 03:00 Saturday.
4. How do they prove it? Key, fob, phone, invitation link, a call to a resident.
5. What's recorded? If something goes wrong, can you reconstruct it?

A serious system isn't "an app that opens a relay." It answers all five,
consistently.

The five building blocks

OpenApp keeps these five in one model, even when the lock brand, the intercom,
and the guest flow come from different worlds.

Why this is harder than handing out keys

Digital identity isn't standing at a door

Signing into a website proves "this account may see this page."

Opening a door also needs:

• The right opening, not every door on the site
• The right moment, not after checkout or during a curfew
• A reachable actuator: the lock or gate motor actually fires
• Often a human in the loop, like a resident answering a visitor

OpenApp sits where software identity meets physical action.

Two ways to run software

Email, accounting, and booking are already SaaS. Access control followed
slowly, because doors are physical and historically local.

A cloud control plane, and the muscle it drives

Physical Security as a Service

OpenApp is Physical Security as a Service (PSaaS):

• Access control as a hosted platform
• Hardware you choose
• One experience for people: phone, browser, dashboard
• APIs so other systems can drive the same rules

PSaaS isn't a camera company or a lock factory. It's the layer that
orchestrates entry.

The typical site is a pile of partial products

Fragmentation is the default

Vendors optimize for their device: their app, their user list, their idea of
a "guest," their log format.

People don't live that way. One person is a resident here, a member
there, and a guest somewhere else.

A small operator might run a house with a cheap Wi‑Fi opener, a 40-unit
building with a cellular gate, and a coworking floor. The people cross sites.
The hardware doesn't match.

If every door is a different product, offboarding and guests become folklore.

Rip and replace, or stuck with leftovers

A modern control plane should respect working hardware and still give you a
current operator experience.

Guests and deliveries come first

Unlock and call became separate products

For decades, "talk to the apartment" meant a panel on the wall, wired to
handsets. Then phones got good. Visitors and residents both carry a computer.

Yet many sites still buy one product to unlock, another to call the
unit, and glue in the middle that nobody owns.

Entry is one human moment. The software should be allowed to treat it as one.

Weak records, slow revocation

At 02:14 you want to know who presented what, at which opening, allowed or
denied, and whether it was a resident, an invitation, or a visitor call.

Many legacy logs are local, incomplete, or impossible to export. Many consumer
apps show a cute timeline and nothing an auditor can use.

And when someone should lose access today, collecting metal keys isn't a
workflow. Revocation has to be a software action.

The building already has software

• Hotels: a property management system
• Short-term rentals: a booking system
• Campuses: a student information system
• Offices: a workplace or facilities system

Those systems already know who should be here, and until when.

If access control can't be driven by that truth, staff re-type it, and the
door ends up wrong.

Mechanical keys, fobs, and an on-prem controller

Legacy lobby intercom

Enterprise systems and all-in-one bundles

Use these when the site is that office, or that new build. Don't force a
different site into them.

Lock middleware and do-it-yourself

OpenApp can use a hub as a bridge. It shouldn't make you the control plane.

The split stack

Split stacks are rational when each specialist is already sunk cost. They're
expensive as a philosophy.

What all of these share

They each optimize one slice: the cylinder, the reader family, the
lobby panel, the lock API, the hub.

Almost none start from the thing people actually do:

Arrive at a place, prove you belong (or ask someone who does), pass a
barrier, leave a record.

OpenApp starts there.

OpenApp in one paragraph

Control plane versus hardware

Software doesn't replace the strike. It decides when the strike may move,
and who asked.

You don't have to rip and replace

Whenever it's practical, reuse what already opens:

• Talk to a vendor cloud or hub you already run
• Bridge older gear through a local automation system
• Put a previously offline controller on a network, in a way that fits safety

If a catalog integration doesn't exist yet, that's a conversation, not an
ultimatum to tear out a working gate.

A portal is the sign at the door

Same portal, different experience

The URL is public. What it does depends on who you are:

One sign. Three honest modes. No separate "guest app" to train the courier on.

Invitations: access without an account

Virtual intercom

A visitor at the sign picks an apartment and can:

• Place a voice or video call
• Message, when you allow it
• After a resident accepts, unlock, if policy says so

Each apartment chooses who rings: admins only, everyone, or a priority
order that falls back to admins. Young children are never rung.

The resident app uses the phone's normal incoming-call experience. The visitor
stays in a mobile browser. The lobby panel is optional.

Organizations and sites

An organization is the operator boundary: a landlord, a hotel company, a
campus department, or a household with its own workspace.

A site is a place you manage in Access: a house, a gated community, a
tower, a campus cluster.

Each site has a directory visitors browse at the sign, doors and the
portals that front them, and people: residents, managers, and staff.

One organization can run many sites. Sites share patterns, not accidental
access.

Virtual Access is the building model

Virtual Access is OpenApp's first-party way to model a site for people:

• A directory of listings, the entries a visitor can call
• Households and groups that feed those listings
• Doors and gates as portal devices
• People linked to listings, public portals, and invitations

It doesn't replace the lock. It orchestrates lock actions through the
openers you linked. Think building operating system, not another hardware
brand.

The directory: entries people can find

Each entry is a listing with a kind: apartment, office, suite, shop,
room, facility, or other.

Type listings by hand, or generate them from groups so a new household
shows up when its group does. Hand edits survive regeneration.

A listing can carry names in more than one language, a floor label, a photo,
and the visitor actions you allow.

Anonymous visitors see a directory, not a dump of private contact data.

Doors, gates, and openers

A door (or gate, barrier, garage) is a portal device in Virtual Access. It
knows:

• Which openers to try, and the fallback if one path fails
• Optional lights on a timer, and auto-close
• Optional cameras for live view during a call
• An opening class and a commissioning attestation from the installer,
  before production opens

The motion is always the same: OpenApp asks an integrated opener to open.
The opener's brand is a plugin, not the product.

Integration, device, entity

Three layers sit under every opening:

Opening a door isn't a magic "door API." It's an action on an entity, such as
open, with OpenApp deciding whether that action is allowed.

One person, many grants

Roles grant. Policies only restrict.

Roles answer who may act? Admin of this site, resident of this
apartment, technician.

Policies answer under what limits? Adding a policy narrows what was
already possible, with one audited exception: emergency free egress.

Example: a resident role may open the lobby. An invitation curfew can
still stop a guest link at 02:00, without changing anyone's role.

Residents and admins aren't "guests." Curfews and invitation limits target
invitation-based access, not the people who live there.

What happens when someone opens

1. They use the portal (scan, tap, link) or an authorized app action.
2. OpenApp resolves the portal to a door and its openers.
3. It checks identity: resident of an allowed listing, valid invitation, or neither.
4. It checks the opening is classified and commissioned, and the door's restrictions.
5. It checks holds (door state) and policies (curfew, rate limits).
6. If allowed, it sends open to the opener, and records the attempt.

Authorization is server-side. A clever URL isn't a master key.

Audit is part of access, not a screenshot

You're not trapped in the dashboard

The dashboard is how humans run a site. The same capabilities are also:

• A public HTTP API and official SDKs
• OpenApp Scripting for repeatable provisioning
• An MCP server for AI agents, and voice assistants through scoped keys

Property, booking, and campus software stay in charge of their records. They
call OpenApp when a stay starts, a student enrolls, or a compartment should
release.

What's different, in one table

Modularity isn't a slogan. It's how a mixed portfolio survives reality.

Three tiers of policy

1. Organization: a floor for a company or landlord tree ("guest invitations
   can't be used 22:00–06:00").
2. Integration: one connection ("on this gate connection, only admins may
   share").
3. Device: the physical box, set by the verified hardware owner, binding
   every organization pointed at that gate.

Inside an organization tree, most restrictive wins. Device policy is
stronger still, and restrict-only.

The one exception sits at the organization tier: emergency free egress
stops OpenApp from denying inbound opens during an emergency. Every application
is audited. It isn't a fire-alarm release.

Shared hardware needs a steward

Networked gates have a failure mode keys never had: anyone who can reach the
device can integrate it.

Several residents might each connect the same community gate to their own
workspace and hand out invitations. Each looks valid. The person responsible
for the gate has lost the plot.

Where the hardware exposes a verifiable admin (see each integration page),
device-level policy lets that admin clamp sharing or curfew across every
organization using that box, without their cooperation.

Holds: keep it open, or keep it closed

An authorized admin can hold a door:

• Open: skip auto-close, for a window or a repeating schedule
• Closed: ignore open commands, with a reason guests can see

Policies can cap how long a hold lasts, forbid permanent holds, or forbid
hold-open entirely. Holds are refused on means of egress and fire door
openings.

If two doors share an opener, they share the hold. Reality is electrical.

One model, seven shapes

The platform is the same for a private home, a shared apartment building, an
office, a short-term rental, a hotel, a campus, and a locker or parcel matrix.
Shared community and vehicle gates cut across several of them.

What changes: who is in charge, how long access lasts, and which
external system is the source of truth. Not a different product per brochure.

Each next slide names who suffers if access is wrong, what good looks
like, and which OpenApp pieces carry the weight. Hardware stays generic on
purpose. The integrations catalog covers specific connectors.

Private home

Shared community and vehicle gates

Shared apartment building

Delegation, in human terms

The building manager shouldn't be the roommate database.

An apartment admin adds or removes people for that apartment, chooses who
receives visitor calls, and invites guests to the doors that apartment may
use. Households manage themselves: residents invite, accept, and hand over
management without the building admin.

The building admin still owns portals, policies, and the openings themselves.

That split is how a 60-unit building stays operable without a full-time access
clerk.

Office and flexible workspace

Short-term rental

Hotel, including boutique

Campus

Locker and parcel matrix

Mixed-use is the test

A podium with shops, apartments above, a hotel wing, and shared parking is
usually several of the previous slides at once.

OpenApp's bet: don't invent an eighth product. Compose it:

• Directories per building, portals per opening
• Organizations per operator
• Invitations per stay or visit
• Device policy on the shared gate, where the hardware exposes a verifiable
  admin

If the model only worked for one brochure, mixed-use would break it.

What a solution architect is choosing

Not "which pretty app." These constraints:

• What already opens, and what must stay as fallback
• Phone-only intercom versus a wired panel you'll keep
• Who is the source of truth for people: PMS, campus, spreadsheet
• Where delegation must live: front desk or each apartment
• How shared gates are governed, and how you'll prove access later

OpenApp fits when those constraints are mixed. It's optional when a single
vendor already owns the whole site and you like that.

Phones and networks fail

The weakest parallel path wins

If you add a keypad with 1234 next to a strong phone flow, attackers will
use the keypad.

Extra methods are parallel choices for the person you don't want.
Convenience can lower the real security of the opening.

Keep legacy fobs if you must, but treat them as part of the threat model, not
as harmless nostalgia.

Compliance is yours

OpenApp orchestrates. It doesn't certify your fire egress, accessibility,
or local access-control code.

Fail-safe versus fail-secure, power, and the mechanical lock are installer and
operator responsibilities. Software can't substitute for a listed exit device.

Read that as respect for the physical world, not a shrug.

Every opening has a life-safety class

Before OpenApp opens a door in production, someone says what the door is:

• Class: not a door, ingress only, vehicle gate, means of egress, fire
  door, or a listed local system
• Attestation: the installer confirms independent exit, power-fail
  behaviour, and that OpenApp isn't the fire-alarm interface

The server refuses open and toggle until both are recorded, and refuses
holds on egress and fire doors. People must always be able to leave without a
phone.

What OpenApp is not

• Not a lock manufacturer
• Not a video management platform that replaces a camera system
• Not a drop-in encoder for every hotel card ecosystem
• Not a substitute for life-safety design, or a listed fire, escape-door, or
  UL / EN access-control system
• Not "only a relay app" without people, policy, and record

It's the access control plane: identity, openings, invitations, intercom,
policy, audit, over hardware you select.

If you remember six things

1. A door is a decision with a record.
2. Most pain is fragmentation, not a shortage of locks.
3. OpenApp is a control plane. Openers are plugins.
4. The portal is the stable object at the door.
5. Roles grant, policies narrow, with one audited exception, emergency
   free egress. One person holds many grants.
6. The same model covers home through campus and lockers, mixed-use
   included.

Where to go next

This deck is the orientation. Those pages are the manuals.