Inside the operating layer
Every building has a part the people inside actually live in — how they get in, how a guest is received, how fast a problem is answered, whether the building feels the way it promised. No system runs that part. The systems that manage the plant manage the plant; the ones that manage the business manage the business; the experience itself falls between them, run by hand.
Apareé commissions the layer that runs it. It starts from a written standard — the building’s own definition of how it should behave toward its residents, guests, and staff — and holds every system and every piece of hardware in the building to it. The systems keep doing their jobs; the experience they add up to is delivered to the standard, the same way every time.
It starts and ends with the people
Everything the operating layer does starts by reading the building as it is — the residents it serves and their patterns, the guests and couriers passing through, the on-site team, the operator, the owner, along with the entrances, the amenities, and the conditions people live in. It doesn’t design this layer; it reads it, serves it, and — through the intelligence layer — learns from what people experience, so the standard keeps sharpening. The people sit at both ends: the reality it reads, and the ones it serves.
The standard
Before any software is touched, the building’s behavior is written down, in terms specific enough to test — the building’s own definition of good:
- The principles it must express — reliability, clarity, control, harmony, grace, care.
- The domains it covers — access, guests, deliveries, bookings, issues, notifications, house rules, move-in and move-out, emergencies.
- Brand intent — a branded residence and a budget tower are held to different standards, by design.
- The operational model — who does what between residents, staff, and the system, and how each exception escalates.
You promise residents a certain way of being treated — but nothing pins down what that actually means, so “good” comes down to whatever each person, and each system, decides on the day.
The standard is the building’s own written definition of how it should behave, set down plainly enough to hold the building to. Everything below it is built to meet it — so the building runs to one agreed standard, not a dozen private versions of it.
The logic
Each behavior the standard defines is codified here as a flow the building runs — its trigger, the decision at each step, the conditions, and the fallback when a step stalls. A few, simplified:
- Access — request → evaluate → permit → log → notify
- Issues — submit → categorize → route → resolve → close → confirm
- Deliveries — arrived → matched to resident → notified → released by code → collected → logged
Bookings, notifications, move-in, move-out and the rest are built the same way. Exactly which sequences a building runs, and how each one is shaped, follows from its standard — so the set differs by building and brand.
A standard on paper doesn’t run itself — carrying it out still falls to people, by hand, case by case.
The logic closes that gap. It’s the building’s behavior written so it runs: what’s defined is what executes — no gap between how the building is meant to behave and how it does.
The surface
Everything the layers define is presented through three surfaces, each built to the building’s brand — and a resident never sees which system underneath answered them:
- The resident app — access, guest passes, deliveries, requests, house rules, notifications, bookings, and the move-in. One app, every interaction with the building.
- The operations console — request routing, escalations, tickets, resident and unit records, device status, alerts, and logs. The building in a single view for the team that runs it — and, for an owner or operator holding several, the portfolio side by side, each building measured against the standard it was commissioned to.
- The guest portal — visitor access, delivery coordination, and temporary credentials that expire on their own.
Your residents have one app for rent, another for the gym, another for a maintenance request, another for a package — so most give up and just call the front desk.
The surface puts every one of those into one place, in the building’s own name — one for residents, one for the team that runs the building, one for guests — instead of a drawer full of vendor apps.
The engines
Behind the surface are the capabilities that do the work. For each, Apareé makes one decision: use the best system for the job, or build it where nothing on the market is good enough for the brand or the building — then wraps whichever it is so the surface sees one interface, no matter which vendor sits behind it:
- Built by Apareé — the engines that decide what’s allowed and for whom (permissions), run each sequence to completion (workflow), route every message to the right person in the right tone (notifications), confirm identity, and handle bookings and issues — together with any capability where no existing product meets the standard.
- Selected, then wrapped — for every other capability, the best system for the job: kept where the building already runs a good one, chosen where it doesn’t. Choosing is itself the work — the market is crowded with near-identical “solutions,” and Apareé cuts through it so the building doesn’t have to. Property management (Yardi, RealPage, Buildium), payments (Stripe, Adyen), accounting (QuickBooks, Xero), statutory e-invoicing (Saudi Arabia’s ZATCA, EU formats), access control and locks (SALTO, Dormakaba), and the building’s HVAC, intercom, IoT, delivery, ID-verification, and parking systems.
Every part of your building runs on a different vendor’s system, and none of them talk — so your staff spend the day copying information between them and working out which one is right.
The engines do the actual work behind the surface: a few Apareé builds, but most are the systems you already run, wrapped so they finally work as one instead of in isolation. Nothing gets ripped out; your team just stops spending the day moving information between them.
The physical systems
This is where the standard turns into something that happens in the physical world. Hardware that runs on the logic — not on a person or a fixed timer — is what takes manual work off the team, makes the resident moments the standard designed actually occur, and spends energy on the spaces people are using instead of heating and lighting empty ones. The logic drives the hardware directly, the way an operating system drives the devices attached to it; a set of separate, vendor-controlled devices becomes one building that behaves.
- The hardware — door controllers, smart locks, readers, intercoms, parking gates, parcel lockers, sensors, climate systems, lifts, and EV chargers.
- The edge gateway — the on-site runtime that keeps access decisions, critical alerts, and essential workflows running locally when the link drops, then reconciles when it returns. It’s also where the building’s security is enforced on site: the hardware carries out an instruction only when it’s valid and within the building’s rules.
Every piece of hardware runs on its own vendor’s system and its own clock — so your team works the building by hand, and the heat and lights run whether anyone’s in the room or not.
Under the operating layer, the hardware acts on the workflow instead: a guest’s arrival opens the lobby door, brings the lift to their floor, and raises the parking gate as one move; the lounge warms up because it’s booked, not because the clock hit 6pm. The work comes off your team, and the space isn’t conditioned until someone’s using it.
The intelligence
Every interaction the layers run leaves a signal — resolution times and where issues pile up, which entrances fail and when, which amenities sit unused, how the workload concentrates, whether the building is holding its standard. On their own, those signals are a report. What makes them intelligence is the engine they feed:
- Forecasts — where churn is rising, which systems are degrading, and which issues are about to recur, before any of it shows.
- Diagnoses — what is working, what is quietly broken, and what is worth attention now.
- Prescribes — the fix to act on, not just the number that moved.
It learns: every problem Apareé resolves, across every building it runs, becomes a case in a growing library — so the engine catches the next one earlier, and a new building inherits what all the others already learned. What it finds returns to the standard: the patterns it surfaces become the next version of how the building should behave, which closes the loop.
Inside the insights engineYour building’s information is scattered across all those systems, so you only find out something’s wrong — a resident souring, a system failing — after it has already cost you a renewal or a review.
Because every interaction now runs through one layer, the building’s whole picture lands in one place — so you’re acting ahead of problems instead of reading about them after.
Ownership
The whole stack runs on infrastructure the building owns — owner-hosted, owner-controlled, with no lock-in:
- Infrastructure — cloud hosting (Google Cloud Platform, or an equivalent where required), identity and access management, observability, backups, and storage.
- Governance — compliance with GDPR, local data-protection law, and building-specific regulation; segmentation between buildings; policy enforcement.
- Portfolio — a multi-building identity that recognizes a resident across properties, and cross-building comparison for owners of more than one.
Apareé operates through scoped accounts the owner can revoke, and warrants the standard it commissioned for as long as the agreement runs.
The technology your building runs on is usually rented — the vendor holds your data and can change the terms, raise the price, or disappear, and your building loses the system it ran on.
Here, all of it runs on infrastructure your building owns: your cloud, your data, your system — so what runs your building can’t be switched off from the outside, sold out from under you, or taken away when a contract ends.
Security
The operating layer decides who gets through a door and what the building’s hardware does — so it’s secured in four ways:
the whole stack runs on the building’s own infrastructure, so control never rests with an outside vendor who could be breached or change the terms.
the network is segmented so trouble in one part can’t reach the rest; every person and device gets only the access its role needs; credentials require multi-factor authentication; and firmware is kept on a regular patch cycle.
the on-site gateway carries out an instruction to a lock, a lift, or a gate only when it’s valid and within the building’s rules, and keeps the essentials running locally if the connection drops.
the system is monitored for anomalies rather than left to run untouched, so a problem surfaces as it happens rather than after the damage is done.
Frequently asked questions
From the architecture to a building
This is what gets installed. Commissioning is how it gets there — building by building, domain by domain, with the standard warranted afterward.