myestateaccess

Legal

Privacy policy.

This describes what the platform records about residents, guards, estate admins and the people who visit an estate — and, just as importantly, what it does not record. It is written to be read rather than to be survived.

Last updated 22 August 2026

Who is responsible for your data

Two different relationships sit behind this platform, and which one applies changes who you should approach about your data.

For an estate's own records — its residents, houses, guards, codes and gate log — the estate is the responsible party under the Protection of Personal Information Act 4 of 2013 (POPIA). The estate decides who lives there, who may be approved, and who guards the boom. We act as its operator: we hold and process that information on the estate's instructions and for no purpose of our own. If you are a resident or a guard, your first port of call is your estate's management.

For our own dealings with you — a demo request, a support email, an account you open with us directly — we are the responsible party, and this policy is the whole of it.

Our details, and those of our Information Officer, are in section 15.

What we collect

Nothing on this platform is gathered in the background. Every item below is either typed in by the person it belongs to, entered by an estate admin who is approving them, or produced by the act of verifying a code at a gate.

Collected per role.
Residents Name, email address, and a phone number if you choose to give one — the phone field is optional and the app works without it. Your estate and house, once an admin approves your join request. The codes you generate, when they expire, and whether each one was used. Any delivery instructions you type.
Guards Name, email address, and which estate you are posted to. A record of each verification you perform, and whether your phone was online or working from its offline list at the time.
Estate admins Name, email address, the estate you administer, and a record of administrative actions such as approving a resident or revoking a code.
Visitors No account, and no name. A visitor is given a code by the resident expecting them, through whatever messaging app the resident already uses — that message never passes through us. What the gate records is the code, the time, and whether it was accepted.

Passwords

We never see or store your password. Authentication is handled by Supabase Auth, which stores a one-way hash — a value that can confirm the right password but cannot be turned back into it. Nobody at myestateaccess can read your password, and nobody can recover it for you; it can only be reset.

Delivery instructions

If you mark a code as a delivery, you can attach a short note for the rider — where to leave a parcel, which gate to use. That note is free text you write, it is passed on with the code, and it is visible to the guard on duty. Treat it as you would a message to a stranger at your gate: it is a good place for "the blue gate on the left" and a poor one for anything you would not want read aloud.

What we never collect

These are design decisions, not settings, and they are the reason several features you might expect are absent:

  • No location tracking. Not for residents, not for visitors, and not for guards. The app never asks for your location and would have nothing to do with it.
  • No number plates, faces or fingerprints. There is no automatic number-plate recognition and no biometrics anywhere in the platform. A code read down a phone line covers the overwhelming majority of visits, and the alternatives fail in ways a guard cannot work around.
  • No access to your contacts, photos or messages. You forward a code using your own messaging app; we are not in that conversation and cannot see it.
  • No advertising, no tracking pixels, no profiling. There are no third-party advertising or analytics scripts on this website or in either mobile app.
  • We do not sell personal information, and we never will. There is no arrangement under which anyone's data is shared with a third party for marketing, credit scoring, or any other commercial purpose.

Why we process it

Under POPIA every use of personal information needs a lawful ground. Ours are:

  • To perform the contract between an estate and its residents and staff — issuing codes, verifying them at the gate, and keeping the estate's access records. Without this the product does not function.
  • The legitimate interests of the estate and its residents in knowing who entered, who was refused, and when. This is the ordinary purpose of a gate register, and it is what the log in section 6 exists to serve.
  • Your consent, for the things that are genuinely optional and are asked for separately: your phone number, and push notifications on your device. Both can be withdrawn without losing access to the rest.
  • Compliance with the law, where we are obliged to retain or produce records.

Who can see what

The most common question residents ask is what the guard at the boom can see about them. The answer is deliberately very little.

A guard sees a code and whether it is valid. Your name and house number are not shown to a guard until you issue a code — and after that code is used or expires, that view goes with it.

More completely:

  • Your estate's admins can see the residents of their estate, which house each belongs to, the codes issued, and the gate log. This is what lets them approve a new resident and investigate a refused entry.
  • Guards can verify codes for the estate they are posted to and see the record of verifications they perform. They cannot browse the resident list.
  • Other residents cannot see your codes, your visitors or your history. Residents who share a house each hold their own account.
  • Other estates see nothing at all. Separation between estates is enforced in the database itself rather than by application code, so a request for another estate's records returns nothing regardless of which part of the system asks.
  • We access estate data only to keep the service running or to resolve a support request an estate has raised with us.

The gate log

Every verification attempt is recorded, and that deliberately includes the ones that fail. A code that had already been used, one that expired last week, one that was never issued — each produces a record with the reason it was refused. A register that only lists successful entries cannot answer the question that actually matters after an incident.

Each record holds the code, the outcome, the guard who performed the check, and two timestamps: the time claimed by the guard's phone, and the time the record reached our servers. Both are kept because phone clocks drift, and a device set to the wrong date would otherwise corrupt the order of the whole trail. Anything that depends on sequence uses the server's time; the phone's time is shown to people reading the log, and labelled as coming from the device.

Guard phones and offline data

A gate loses signal, so a guard's phone keeps a local copy of the currently valid codes for that estate — enough to verify a visitor with no connection at all. That local copy holds codes and expiry times. It does not hold resident names, addresses, phone numbers or history.

Verifications made while offline are stored on the phone and sent up when the connection returns, at which point they join the same log as everything else and are marked as having been made offline. One consequence is worth stating plainly, because it is a real limitation rather than a bug: if a code is revoked while a guard's phone is offline, that phone will not know until it reconnects. The gap can never outlast the code's own six-hour life, and is usually a matter of minutes.

Sessions on mobile devices are held in the device's hardware-backed secure storage, encrypted. On the web dashboard, your sign-in session is kept in your browser's local storage so that you are not signed out on every page load; signing out clears it.

How long we keep it

  • Visitor codes expire six hours after they are generated and can be used only once. Expiry is automatic — nobody has to remember to clean anything up, which is exactly why it was built that way.
  • Gate log records are retained for [RETENTION PERIOD — to be confirmed], then permanently deleted. An estate may ask for a shorter period for its own records.
  • Account details are kept while your membership of an estate is active. When you move out, an admin deactivates your membership and your codes stop working immediately.
  • After an account is closed we delete or anonymise personal details within [PERIOD — to be confirmed], except where we are required by law to keep a record for longer. Entries already written to a gate log are part of the estate's access record and are retained on the schedule above, rather than being removed retrospectively.

Where it lives, and who else touches it

We keep the list of third parties short, and each one is here because the product cannot work without it:

Supabase The database, authentication and server-side functions. This is where estate data is stored, hosted in the [REGION — to be confirmed] region.
Expo Delivers push notifications to the mobile apps — for example, telling a resident their visitor has arrived. It receives a device token and the notification text, not your account details.
Vercel Hosts this website and the estate dashboard, and keeps standard server logs including IP addresses.

Some of these providers process data outside South Africa. Where that happens, we rely on the transfer conditions in section 72 of POPIA — the recipient is bound by contractual terms providing an adequate level of protection.

How it is protected

  • The rules live in the database. Who may read what is enforced by the database itself, not by the app in front of it. An interface can be bypassed; a database constraint cannot, which means the rule holds even for code we have not written yet.
  • Codes are single-use and burnt atomically. A code is marked used in the same indivisible operation that accepts it, so the same code cannot be spent twice by two requests arriving together.
  • Everything is encrypted in transit, and the database is encrypted at rest.
  • Administrative keys never leave our servers. The credential that could bypass the access rules exists only in server-side configuration and is never included in anything a phone or browser downloads.
  • Sessions on devices are stored encrypted, with the encryption key held in the phone's hardware-backed keystore.

No system is perfectly secure. If a breach affects your personal information, POPIA requires us to notify both the Information Regulator and you, and we will do so as soon as we reasonably can.

This website

This site sets no cookies and runs no analytics, no tracking pixels and no advertising scripts. We do not know who you are while you read this page.

Two things are worth mentioning because your browser fetches them from elsewhere, and those services will therefore see your IP address: our typeface is served by Google Fonts, and the photographs are served by Unsplash. Neither is used to identify you, and we receive nothing from either about your visit.

The contact form does not send anything to us over the internet. It opens a message in your own email program, already filled in, which you then choose to send or discard — so what reaches us is an ordinary email, and only if you send it.

Your rights

Under POPIA you may:

  • Ask what we hold about you and get a copy of it.
  • Have it corrected if it is wrong, or completed if it is missing something.
  • Ask for it to be deleted where we no longer have grounds to keep it.
  • Object to processing based on legitimate interests, on grounds relating to your situation.
  • Withdraw a consent you previously gave — a phone number, or push notifications — without affecting anything done before you withdrew it.
  • Complain, either to us or directly to the Information Regulator.

Write to our Information Officer at the address in section 15 and we will respond within 30 days. If your request concerns records held for your estate, we may need to refer it to that estate as the responsible party — we will tell you if that happens rather than leaving the request unanswered.

The Information Regulator

You may complain to the Regulator at any time, and you do not have to come to us first:

Children

Accounts are for adults. We do not knowingly create accounts for anyone under 18, and a child living in an estate does not need one — a resident issues codes on behalf of their household. If you believe a child has an account, tell us and we will remove it.

Changes to this policy

When this policy changes we update the date at the top of the page. If a change materially affects how your information is used, we will tell you in the app or by email before it takes effect, rather than relying on you to re-read this page.

How to reach us

For anything in this policy, including a request to see, correct or delete your information:

  • Information Officer: [NAME — to be confirmed]
  • Email: privacy@myestateaccess.com
  • Company: [REGISTERED COMPANY NAME AND REGISTRATION NUMBER — to be confirmed]
  • Address: [REGISTERED ADDRESS — to be confirmed]

If you are a resident or a guard, your estate's management can usually resolve a question about your own record faster than we can, because it is their record to correct. For anything they cannot answer, write to us.

Ask us something How the product works