This talk assumes very little

You do not need a background in physical security, locks, or cloud software.

It is written for:

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

If a word is jargon, we define it before we use it.

What we will cover

1. What a door really is (a decision, not just a lock)
2. Why buildings still struggle with access
3. How other solutions typically work
4. How OpenApp works, piece by piece
5. What makes that model unusual
6. Use cases across homes, housing, work, hospitality, campus, and lockers

Later talks can go deeper on any one of these. This deck is the map.

What this deck is not

• Not a commerce product tour
• Not commercial packaging or go-to-market material
• Not a vendor bake-off or market-share analysis
• Not an installer manual for wiring, fire code, or certified hardware design

Those topics live elsewhere. Here we stay on access control: who may enter,
how, when, and how you can see what happened.

How to use the slides

• Next: right arrow, space, or Page Down
• Back: left arrow or Page Up
• Fullscreen: F
• Keyboard list: ?

Each major part starts with a colored divider. Skim those if you already know
the basics; slow down where the model is new.

You already do access control

Think about this morning.

• A key to your home
• A badge or fob at work
• A code on a gate keypad
• A staff member buzzing someone in
• A hotel card that stops working at checkout

That is access control: deciding who may pass a physical barrier, and making
that decision happen at the barrier.

Physical security, in plain language

Physical security is how a place protects itself in the real world: walls,
doors, gates, cameras, people at a desk.

Access control is the part that answers:

May this person go through this opening, right now?

OpenApp is about that question—and about running it well across many openings,
many people, and many kinds of hardware.

Five questions every opening must answer

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

A serious system is not “an app that opens a relay.” It is a way to answer
those five questions consistently.

The five building blocks

OpenApp’s job is to keep these five in one coherent model—even when the lock
brand, the intercom, and the guest flow come from different worlds.

Why this is harder than handing out keys

Keys are simple until they are not:

• Someone moves out and you never get the key back
• A contractor needs two hours, not forever
• A delivery driver is at the gate, not the apartment door
• The building has twelve openings, not one
• Two buildings share a parking gate
• You must show who opened what after an incident

Physical access is a people and time problem wearing a hardware costume.

Digital identity is not the same as standing at a door

Signing into a website proves “this account may see this page.”

Opening a door also requires:

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

OpenApp sits at that intersection: software identity plus physical
action.

Two ways to run software

Installed software: you (or your integrator) put a program on a PC in the
electrical room. You keep it updated. If that PC dies, the workflow dies with
it.

Software as a service (SaaS): you use the product over the internet. The
provider runs the servers, the upgrades, and the backups. You sign in and work.

Most modern business tools—email, accounting, booking—are SaaS. Access control
has been slower to follow, because doors are physical and historically local.

Why a building might want a cloud control plane

A control plane is the brain: users, permissions, invitations, directories,
audit. The hardware is the muscle: strikes, gate motors, relays.

Cloud control helps when you have:

• More than one site
• Staff who are not standing next to a basement PC
• Guests who should not install a vendor’s app
• Other software (booking, property, campus) that must talk to doors

The lock can stay on the wall. The policy does not have to live only there.

Physical Security as a Service

OpenApp is Physical Security as a Service (PSaaS).

That means:

• Access control is delivered as a hosted platform
• You connect the hardware you choose
• People use one coherent experience (phone, browser, dashboard)
• Other systems can drive the same rules through APIs

PSaaS is not “a camera company” and not “a lock factory.” It is the layer that
orchestrates entry.

The typical site is a pile of partial products

Walk a mixed building and you often find:

• A legacy lobby panel with a paper directory
• A parking gate with its own app
• Fobs programmed on a desktop in a closet
• A Wi‑Fi relay someone installed for the side door
• A spreadsheet of guest codes
• No single picture of who can do what

Each piece may work. The system does not.

Fragmentation is the default

Vendors optimize for their device:

• Their app
• Their user list
• Their notion of a “guest”
• Their log format, if they have one

People do not live that way. One person is a resident here, a member
there, and a guest somewhere else—this week.

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

Hardware lock-in versus hardware reuse

Two failure modes, opposite directions:

1. Rip and replace: a new software product that only speaks its readers
   and its panels. Yesterday’s working gate is declared obsolete.
2. Stuck with leftovers: you keep old hardware, but the only software is a
   2008 desktop app and a landline intercom.

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

Guests and deliveries are first-class, not an afterthought

Most systems are designed around employees or residents.

Real sites also have:

• Cleaners on a Tuesday window
• Furniture deliveries
• Short stays
• Event visitors
• Parents picking up children
• Couriers who should open one compartment, not the building

If “add a guest” means cutting a fob, you will either be slow or unsafe.

Intercom became a separate product

For decades, “talk to the apartment” meant a panel on the wall, wired to
handsets.

Then phones got good. Visitors already carry a computer. Residents already
carry a computer.

Yet many sites still buy:

• One product to unlock
• Another product to call the unit
• Glue in the middle that nobody owns

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

Multi-site, mixed hardware, mixed orgs

A small operator might have:

• A house with a cheap Wi‑Fi opener
• A 40-unit building with a cellular gate
• A coworking floor with many inner doors
• A hotel wing that still uses a specialist room lock

The people cross those sites. The hardware does not match. The admin
model usually assumes one vendor and one tenant.

That mismatch is the job.

Weak records, slow revocation

When something happens at 02:14, you want:

• Who presented what
• Which opening
• Whether it was allowed or denied
• 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 is not a
workflow. Revocation has to be a software action.

The rest of the building already has software

Hotels have a property management system.
Short-term rentals have a booking / vacation-rental system.
Campuses have a student information system.
Offices often have a workplace / facilities system.

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

If access control cannot be driven by that truth, staff will re-type it, and
the door will be wrong.

Mechanical keys

How it works: a physical key matches a cylinder. Copies are metal.

Strengths: no network, no battery in the credential, everyone understands it.

Limits: copies you cannot see; lost keys; painful guests; no useful record;
one cylinder per change of mind.

Keys remain an excellent fallback. They are a poor primary system the
moment the population turns over.

Fobs, cards, and an on-prem controller

How it works: each person gets a token. A box in the building decides.
Software often lives on a local PC.

Strengths: familiar to security vendors; can be robust on a local network.

Limits: that PC is a single point of failure; remote management is awkward;
guest access is a programming chore; multi-site means many islands.

This is the backbone of a huge amount of existing housing and office stock.

Legacy lobby intercom

How it works: a wall panel lists units. A visitor taps a number. A phone or
handset rings in the apartment. The resident buzzes the door.

Strengths: visitors need no account; it can work when a resident’s mobile
does not; installers know it.

Limits: directories go stale; no guest link for a cleaner; no API for a
booking system; another vendor beside the lock vendor.

OpenApp’s view: keep it as fallback when phones or networks fail. Do not
pretend a phone-only path is the same as a wired panel.

Enterprise access control systems

How it works: standardized readers and controllers, central software,
schedules, and audit aimed at corporate offices.

Strengths: mature for “IT owns every door”; strong at uniform campuses of
the same hardware family.

Limits: often a poor fit for per-apartment delegation, short-stay
invitations, and mixed IoT openers. Hardware choice is frequently the
vendor’s catalog, not yours.

Use this pattern when the site is that office. Do not force housing into it.

All-in-one property bundles

How it works: one company sells the lock, the app, and the operator tools
as a package.

Strengths: one throat to choke; a polished resident app if you accept the
bundle.

Limits: retrofit is painful; mixed existing gates are second-class; you
inherit their roadmap for intercom, guests, and APIs.

Fine for a new-build that wants that ecosystem. Awkward for “we already have
a working gate.”

Lock middleware

How it works: a hosted API that speaks to many smart lock brands. You
build the rest: your dashboard, your invitations, your intercom, your audit UX.

Strengths: fast if your world is supported locks and you are a software team.

Limits: gates, relays, field-bus openers, and lobby calling are your
problem. Middleware is not a full access product.

If you only needed lock tokens, this can be enough. If you needed a building,
it is a component.

Do-it-yourself automation

How it works: a home-automation hub, some relays, scripts, maybe a custom
mini-app.

Strengths: enormous hardware reach; great for a technically confident home
or lab.

Limits: you just became the vendor for identity, invitations, audit,
delegation, and uptime. That is a product, not a weekend project.

OpenApp can use a hub as a bridge. It should not force you to become the
control plane.

The split stack

Common in hotels and larger housing:

Split stacks are rational when each specialist is already sunk cost. They are
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, then attaches hardware as modules.

OpenApp in one paragraph

OpenApp is a cloud control plane for physical access.

It connects to openers you already have or will buy, models a site
(directory, doors, people, policies), and lets residents, guests, and visitors
act through portals—usually a sign at the door with a QR code, NFC tap, or
short link.

The same platform is also an API, so booking and property software can
drive invitations and unlocks without a second access product.

Control plane versus hardware

Software does not replace the strike. It decides when the strike is allowed
to move, and who asked.

You do not have to rip and replace

Whenever it is practical, reuse what already opens.

Paths people use:

• Talk to a vendor cloud or hub you already operate
• 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 does not exist yet, that is a conversation—not an
ultimatum to tear out a working gate.

Organizations, sites, and buildings

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

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

A building, in OpenApp language, is especially the directory + virtual
intercom shape: floors, apartments, who receives a visitor call.

One organization can run many sites. Sites can share patterns without sharing
accidental access.

One person, many grants

OpenApp does not treat a human as property of a single customer org.

You are one user. Access is additive:

• Resident in one building
• Desk member in another organization
• Guest with a time-bound invitation from a third

Privileges come from assignments and grants, not from a badge that says
“this is your only home in the database.”

That matches real life. Most systems fight it.

Integrations, devices, and entities

Three layers sit under every opening:

1. Integration — a connection to a provider (cloud, hub, protocol, or
   OpenApp’s own Virtual Access).
2. Device — one physical or virtual box on that connection.
3. Entity — a controllable thing on the device: a relay channel, a light, a
   compartment.

Opening a door is not a magic “door API.” It is an action on an entity, such as
open, with OpenApp deciding whether that action is allowed.

Virtual Access is the building model

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

• A directory of apartments / units
• Doors and gates as portal devices
• People linked to units
• Public portals (the signs)
• Invitations

It does not replace the lock. It orchestrates lock actions through the
openers you linked.

Think of it as the building operating system, not another hardware brand.

The directory (units people can find)

Each unit is an apartment in the data model—even if in real life it is an
office, a hotel room, or a studio.

The directory can hold:

• Display names in more than one language
• Floor labels
• Photos
• Which visitor actions are allowed (call, message, and so on)

Anonymous visitors see a directory, not a dump of private contact data.
Policy decides how much is visible and what they may do.

Doors, gates, and openers

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

• Which openers to try (and fallback if one path fails)
• Optional lights on a timer
• Auto-close so a strike is not left energized
• Optional cameras for live view during a call or an operator check

The physical motion is always: OpenApp asks an integrated opener to open.
The brand of that opener is a plugin, not the product.

A portal is the sign at the door

In the field, a portal is what you mount: a plaque, a sticker, a post at a
lane.

Behind it is a stable public identity—a URL of the form /p/{id}—exposed as:

• A QR code
• An NFC tap (phone or watch)
• A printed short link
• A link in a message for a guest who is not on site yet

Operators think “the lobby sign.” Software thinks “the durable entry point.”
If you replace the lock, you retarget the portal. You do not reprint the
building.

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

An invitation is a time-bound grant: this portal, this window, this many
uses, optionally branded.

The guest opens a link. OpenApp can keep a minimal session on that device
so the next scan of the same sign is a one-tap open—until the invitation
ends.

Residents and admins are not “guests.” Curfews and invitation limits target
invitation-based access, not the people who live there.

Virtual intercom

A visitor at the sign can pick a unit and:

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

Routing uses the people linked to that apartment—especially those marked to
receive calls.

The resident app uses the phone’s normal incoming-call experience. The visitor
can stay in a mobile browser. The lobby panel is optional, not the center of
the universe.

Roles grant. Policies only restrict.

Roles answer: who may act?
(admin of this site, resident of this apartment, technician, …)

Policies answer: under what limits?
They never give extra power. Adding a policy can only narrow what was
already possible.

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.

Three tiers of policy

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

Inside an org tree, most-restrictive wins. Device policy is stronger still,
and still restrict-only—except emergency free egress, which only stops
OpenApp from denying inbound opens (not 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 org looks “valid.” The person
responsible for the gate has lost the plot.

Device-level policy lets a verified hardware admin clamp sharing or curfew
across every org using that box—without needing 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

Holds are operational, not a secret backdoor. Policies can cap how long a hold
may last, forbid permanent holds, or forbid hold-open entirely.

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

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 unit, valid invitation, or not.
4. It checks door restrictions (all residents vs a whitelist of units).
5. It checks policies (curfew, holds, rate limits).
6. If allowed, it sends open to the opener—and records the attempt.

Authorization is server-side. A clever URL is not a master key.

Audit is part of access, not a screenshot

You should be able to answer “who opened what, when,” including denials.

OpenApp keeps an append-only audit log: operators review it in the
dashboard, systems can pull recent events, export history, or receive signed
webhooks.

That is how a hotel, an office, or a campus treats entry as an accountable
act—not a vibe.

You are not trapped in the dashboard

The dashboard is how humans run a site.

The same capabilities are available as:

• A public HTTP API
• Official SDKs
• OpenApp Scripting for repeatable provisioning

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

Hardware and software are decoupled on purpose

You pick openers per opening and per budget: from very low-cost controllers to
commercial gear with a vendor cloud of its own.

OpenApp stays the consistent control plane, APIs, and experience.

That is the opposite of “buy our reader family, then you may have software.”

Modularity is not a slogan here. It is how a mixed portfolio survives contact
with reality.

One product for unlock, call, and guest

Most stacks split:

• Access
• Intercom
• Guest credentials

OpenApp treats them as one arrival:

• The sign is the start
• The directory is how strangers find a human
• The invitation is how you skip the human when you already trust the visit
• The opener is the last centimeter

Fewer consoles. One policy surface. One audit story.

Privilege-centric identity

Identity is global. Authorization is local and additive.

That enables:

• Multi-org people without duplicate humans
• Delegation per apartment without making every resident a building admin
• Invitations that are not fake “users” you forget to delete

Most access products still start from “this person belongs to this tenant.”
Buildings do not.

The portal is a stable object

Doors fail. Relays get swapped. Integrations get re-created.

The portal id on the plaque is the thing staff can name: “scan Lobby.”

Many portals may point at one door (pedestrian vs vehicle lane, languages,
campaigns). One door is not forced to be one sticker.

Stable public identity is an operations feature disguised as a URL.

Device stewardship for the real world

Shared networked hardware is not a corner case. It is gated communities, mixed
lots, and “my cousin connected the gate.”

A restrict-only device tier, owned by a verified hardware admin, is how
OpenApp models physics and politics—not only org charts.

One model, seven deployment shapes

The platform is the same for:

1. Private home
2. Shared apartment building
3. Office (including flexible workspace)
4. Short-term rental
5. Hotel
6. Campus
7. Locker / parcel matrix

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

How to read a use case

For each shape we will name:

• Who suffers if access is wrong
• What “good” looks like
• Which OpenApp pieces carry the weight

Hardware examples stay generic on purpose. The integrations catalog is the
place for specific connectors—not this story.

Private home

Who: a household, maybe a rental unit you live in.

Pain: vendor apps, guest codes on a notepad, a gate that does not talk to
the door.

Good: a handful of people, occasional guests, a portal on the gate or
front door, invitations that expire.

Virtual Access still helps: one directory entry can be “House,” and the garage
can be a second portal. Small does not mean chaotic.

Shared community and vehicle gates

Who: a street, a compound, a parking association.

Pain: one gate, many households, everyone inventing their own guest list.

Good: a lane portal (QR, NFC, in-car bookmark), invitations with curfew,
and a hardware steward so the gate cannot be silently re-shared forever.

Pedestrian signs and vehicle signs can be different portals onto the same
opener. The car does not need a unique philosophy of access.

Shared apartment building

Who: residents, building staff, visitors, deliveries.

Pain: stale lobby panel, fobs for every change, no per-apartment control.

Good:

• Virtual intercom at the lobby sign
• Each apartment can manage its own people
• Building admins still see the whole site
• Parking gate and pedestrian door in one place

This is the shape where delegation is not a nice-to-have. It is the product.

Delegation, in human terms

The building manager should not be the roommate database.

An apartment admin can add or remove people for that unit, choose who
receives visitor calls, and invite guests to the doors that unit may use.

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

Who: staff, members, visiting clients, cleaners.

Pain: many inner doors; audit; members who churn weekly; a reception that
cannot be a bottleneck.

Good: central administration, less per-unit politics, strong records,
portals at the street door and the suite door.

If you already run a workplace system, OpenApp should receive “this member
is valid until Thursday,” not become a second HR database.

Short-term rental

Who: guests who have never been to the building; a remote operator.

Pain: lock brands that assume identical deadbolts; parking gates; check-in
at 16:00 in another timezone.

Good: the booking system stays the source of truth. On confirmation,
automation creates an invitation for the stay window. On checkout, it ends.
The guest uses a link—no resident app required.

Mixed openers per listing are normal. The invitation does not care.

Hotel (including boutique)

Who: guests, front desk, housekeeping, visitors in the lobby.

Pain: PMS knows the stay; the lobby is a different vendor; the car park is
a third.

Good: check-in creates time-bound access to the openings you choose; the
lobby directory calls the desk or a room; gates use the same invitation story.

Honest limit: specialist in-room lock credential ecosystems can remain in
place. OpenApp complements lobby, perimeter, and guest links. It does not have
to pretend to be a magstripe encoder.

Campus

Who: staff, faculty, students, parents, event visitors, many buildings.

Pain: nested organizations; mixed populations; a student system that
already knows enrollment.

Good: sub-organizations, delegated admins, guest flows for the people who
are not in the directory every day.

The student information system remains authoritative for “is this person
enrolled.” OpenApp is authoritative for “may they open this door tonight.”

Locker and parcel matrix

Who: a recipient, a courier, a mailroom operator.

Pain: a wall of boxes that must open one at a time, tied to a pickup
workflow—not a lobby directory.

Good: each compartment is an entity. Your workflow validates a code,
then OpenApp opens that entity.

Same action model as a door. Different human ritual. No separate “locker
product” required for the control plane.

Mixed-use is not a special case

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

OpenApp’s bet: do not invent a eighth product. Compose:

• Directories per building
• Portals per opening
• Organizations per operator
• Invitations per stay or visit
• Device policy on the shared gate

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

Story: a visitor at the lobby

1. They walk up. There is a sign, not a dead panel.
2. They scan. They see units, not a phone book of private numbers.
3. They call apartment 12. Maya’s phone rings like a phone call.
4. She sees who is asking. She can speak, then open—or refuse.
5. The attempt is recorded.

Nobody printed a fob for a one-time guest. Nobody buzzed the whole building.

Story: a resident coming home

1. They signed in once.
2. They tap the same lobby sign (or NFC on a watch).
3. They get Open, not the directory.
4. Optional auto-open: the session can fire the opener as it loads, where they
   opted into that convenience.

The sign did not change. The authorization did.

Story: a guest for a stay

1. Booking confirms. Automation creates an invitation for the garage and the
   unit door, valid Friday 16:00 to Monday 11:00.
2. The guest gets a link. They never create an account.
3. After first use, scanning the garage sign is a tap on Open.
4. Monday 11:01 it stops. Nobody collects a card from a lockbox.

If they arrive at 02:00 and a curfew policy forbids invitation entry, the
link is still “valid”—and still correctly refused until morning.

Story: the operator’s Tuesday

• Add a resident who just signed a lease
• Hold the loading dock open for a delivery window
• See last night’s denials
• Rotate a failed opener without changing the lobby plaque
• Invite a cleaner for Thursday 09:00–12:00

The dashboard is built for this. The API is built for when Tuesday happens
two thousand times.

What a solution architect is actually choosing

Not “which pretty app.” These constraints:

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

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

Phones and networks fail

Design for dead batteries, no signal, and “I do not have the app.”

Typical mitigations:

• Mechanical keys for named people
• Rated exit hardware and push-to-exit
• Reception or a legacy intercom kept in service
• Vendor-cloud or on-device schedules that do not depend on OpenApp

OpenApp should be a strong modern path, not the only path, until the
building explicitly accepts phone-only life.

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 do not 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 does not 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 cannot be a substitute for a listed exit
device.

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

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
• Not a listed fire, escape-door, or UL / EN access-control system
• Not “only a relay app” without people, policy, and record

It is 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 restrict; identity is one person with many grants.
6. The same model covers home through campus and lockers—including mixed-use.

Written docs, by job

• See it work: Getting started, and Set up access control
• Day to day: User guide (portals, mobile intercom)
• Design the site: Access control architecture, policies, fallback
• Sector playbooks: apartment, short-term rental, hotel, lockers
• Connect hardware: Integrations catalog
• Automate: API reference, SDKs, OpenApp Scripting

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

Topics we can go deeper on later

Each of these can be its own talk:

• Portals, NFC, vehicles, and auto-open
• Virtual intercom and the native phone app
• Policies, curfews, holds, and device stewardship
• Delegation in multi-unit housing
• Driving OpenApp from PMS / booking / campus systems
• Audit, exports, and webhooks
• Architecture trade-offs: connectivity, cost per door, fallback

The map is here so those talks have a place to hang.