Pokoyo is made by Mateusz Olczyk, an independent developer based in Poland. Contact: matt.olczyk@gmail.com.
The short version. Pokoyo is a work tool for small lodging properties: it organises housekeeping, the sauna/jacuzzi schedule and a simple information page for guests. There are no ads, we never sell data, and we profile nobody.
Yes, we do process guest data — exactly what a guest types into the booking request form (first name, chosen room, an optional note) plus technical markers that protect the form against spam. Section 5 describes this in detail. We do not handle check-in records, identity documents, card numbers or payments at all.
The database, photos and server functions are stored in the European Union, in the
europe-central2 (Warsaw) region. Three things Google runs outside that region,
and we say so plainly in section 10: push notifications, panel sign-in and technical server
logs. The Android app also collects basic telemetry (usage statistics and crash reports) —
it is enabled by default, which we state plainly in section 8.
Pokoyo has three separate surfaces and this policy describes all three:
com.tr0lczyk.pensjonat) —
cleaning tasks, checklists, room photos, issue reports./g/{property-name} — a page with no
sign-in that a guest opens from a QR code or a link given by the property. This is the only place
where data is entered by a guest rather than by staff.Pokoyo is a B2B tool: we supply the software, while the lodging property decides what data enters the system and why. Therefore:
We do not determine the legal basis for guest and staff data — the property owner does, as the controller, because the owner knows the context (contract with the guest, the property's obligations, legitimate interests). We process that data only on the owner's instructions and within the scope described in this policy.
Are you a guest or a staff member who wants access to, correction of, or deletion of your data? Contact the property where you are staying or working first — it is the controller. You may also write to us and we will pass the request on and carry it out technically.
| Category | What exactly | Why |
|---|---|---|
| Property data | Property name, rooms and spaces (sauna, jacuzzi, bikes), cleaning tasks, checklist templates and states, issue reports, invite codes, guest portal content written by the owner. | The core function: organising and verifying housekeeping, plus the wellness schedule. |
| Staff roster | Staff member's display name, link to the technical account, task assignments, a record of who ticked which checklist item and when, the owner's rework comment. | So it is clear who cleans which room and whose phone to notify. |
| Room photos | Photos taken by staff as part of a checklist or an issue report (Firebase Storage). We ask staff to photograph the room, not people. | Proof that cleaning was done and documentation of issues for the owner. |
| Wellness bookings entered in the panel | A guest label typed by hand by the owner (usually a room number or a surname), time, price, settlement status. | The sauna/jacuzzi schedule and settling up with the guest. Visible to the owner only. |
| Push notifications | Device tokens (Firebase Cloud Messaging) stored in the user profile; stale tokens are removed automatically. | Notifications about new tasks, rework, issues and guest requests. |
| Settings | User role, link to the property, chosen language, notification preferences. On the staff phone additionally: the display name and theme, in the app's own storage. | Correct permissions and interface. |
Who sees what. A housekeeper sees only the tasks, checklists, issues and photos of their own property, plus their own roster record. They do not see the rest of the roster, booking calendars, the wellness schedule or any guest data. Access disappears immediately once the owner deactivates them in the panel.
The guest portal is a public page with no sign-in. The owner can switch it on or leave it off;
it is off by default. The page carries a noindex marker, so it does not appear in
search engines — it is reachable by anyone who knows its address.
In exactly one place: the booking request form for the sauna, jacuzzi or a bike. The guest provides:
Alongside that we store the request's context: which space it concerns, the date and time, the status (pending / approved / rejected / expired) and when it was sent. We do not ask for a surname, e-mail, phone number, address, document number or payment and there are no fields in which those could be entered.
This data does not stay forever: 90 days after the slot the request was for, the first name, the note and both technical markers from 5.2 are cleared automatically and permanently (details in section 11).
The form is public, so without safeguards it would flood the owner with junk. Along with the request we store two things the guest does not type:
pokoyo-portal-device. It contains
nothing about the guest or the phone; it serves the same daily limit. It is not created in the
browser's private mode.In the guest browser's local storage we also record which requests have already been sent (key
pokoyo-portal-sent-…, cleared after two days) and the chosen language
(pokoyo-portal-lang). These are not tracking cookies, they never leave the guest's
browser other than in the request itself, and they are not used for advertising.
The portal displays: the property name, the reception phone number, texts and photos entered by the owner, a map of the area, the list of room names (needed for the form's room picker) and the sauna/jacuzzi/bike schedule as free or taken.
The portal never shows: other guests' names or notes, who occupies which room, cleaning statuses, prices, checklist room photos or anything from the internal side. A guest cannot even read back their own submitted request — it goes to the owner only.
Photos the owner adds to the portal (e.g. a view of the terrace, a menu) are by their nature publicly accessible at their address — like any image on a website.
The property owner only, in their panel. Housekeeping staff have no access at the database security-rule level — this is not a hidden screen but an absence of permission. The content of a request (first name and time) also travels inside a push notification sent to the owner, so it passes through Google's / the browser's notification infrastructure, like any web push message.
If the owner adds a map section to the portal, the map tiles are fetched by the guest's browser directly from OpenStreetMap servers. That means the guest's IP address and which part of the map they are viewing reach the OpenStreetMap Foundation — we neither proxy nor record this. Without a map section no request goes there.
The owner may enter an iCal calendar address from a booking service so that a guest's departure turns itself into a cleaning task. From such a calendar we fetch and store only: the event's technical identifier and the arrival and departure dates.
We do not store guest names from those calendars. The event summary is read (to tell a reservation from a blocked date), but it never reaches the database. The calendar address is treated as a secret: only the owner sees it, and we never put it into notifications or alert e-mails.
The guest portal works in four languages: Polish, English, Ukrainian and Russian. Content written by the owner is translated automatically through Google Cloud Translation. We send for translation only the texts written by the owner (section titles, descriptions of attractions), and only those that have changed. A guest's first name and note are never sent to anyone for translation. Staff checklist items are not translated either.
Since 19 August 2026 translation runs on Google Cloud Translation's European
(regional) endpoint, in the europe-west1 region. Previously we used the
global endpoint, where Google could serve the request from any region in the world — it was
the only place in our entire backend that was not pinned to Europe. The texts we send for
translation now stay inside the Union.
The Android app uses Google Firebase Analytics (usage statistics) and Firebase Crashlytics (crash reports). What is collected is Firebase's automatic events (app open, screens viewed), the device model, the OS and app version and — on a crash — the state of the app at the moment of the error. We send no custom events containing task content, room names, personal names or guest data.
Important: telemetry is enabled by default. The app is a B2B tool with no ads — telemetry serves only error diagnosis and product development, never advertising or marketing profiling. The app shows no telemetry consent dialog; the basis for processing is our legitimate interest (Article 6(1)(f) GDPR), and we are the controller of that data. If you do not accept telemetry, write to us — until then the only complete alternative is not to use the app.
The Firebase Analytics library adds the system permission to read the
advertising identifier (AD_ID) to the app. We say so plainly, because it
is visible in the store: the app shows no ads, works with no ad network, and does not use
that identifier for advertising or profiling. The web panel and the guest portal have
no analytics at all — neither Google Analytics nor anything else.
| Service | What for | What reaches it |
|---|---|---|
| Google Firebase / Google Cloud (Authentication, Firestore, Storage, Cloud Functions, Hosting) |
The whole backend: database, files, sign-in, server functions. | Everything described above. Region europe-central2 (Warsaw). |
| Firebase Cloud Messaging and browser push systems | Push notifications to the owner and staff. | The notification content — including a guest's first name on a new booking request and the owner's comment on a rework request. |
| Google Cloud Translation | Translating portal content into EN/UK/RU. | Only texts written by the owner (section 7). European endpoint,
europe-west1 region. |
| Google Cloud Logging | Technical server logs — for finding failures. | Diagnostic messages written by us: property, request, room and task identifiers, dates, counters and error text. No guest first name, no guest note, no IP address and no User-Agent (section 10). Retained for 30 days. |
| Resend (Ireland region, EU) | One e-mail: an alert to the owner when a booking calendar has stopped syncing. | The owner's e-mail address, property name, calendar name, the error text, a link to the panel. No calendar address and no guest data. |
| The owner's booking service (Booking, Airbnb, Google Calendar) | Fetching the iCal calendar. | The request goes out from us to the address the owner supplied; we send no Pokoyo data there. |
| OpenStreetMap | Map tiles on the guest portal, if the owner adds a map section. | The guest browser's IP address (section 5.5). |
That is the complete list. Beyond these services we pass data to nobody — no ad networks, no data brokers, no marketing or third-party analytics tools.
The backend is Google Firebase within Google Cloud. Property data, photos and server functions
run in the europe-central2 region (Warsaw). Portal translations go through the
European Cloud Translation endpoint (europe-west1). Alert e-mails go out through
Resend from the Ireland region (eu-west-1). Google LLC and Resend act as our sub-processors;
data transfers are governed by those providers' standard contractual clauses.
What Google does not let us pin to Europe — we say this plainly rather than promising more than we can keep:
global — Google guarantees no region for it. We keep them for 30 days
and use them only to find failures. Since 19 August 2026 there is no guest data in
them at all: the portal's request log (the only place holding a raw IP address and
User-Agent) is no longer produced, and we reviewed our own messages line by line and removed
what could carry personal data — among others the quoted malformed line of the calendar feed
pulled from a booking service, which could contain a guest's name or phone number.| Data | How long |
|---|---|
| Room photos from checklists and issues | 12 months from upload — after that the file is deleted automatically (once a day). In the panel the photo's place reads "photo deleted after a year"; the work history stays. |
| Guest booking requests (first name, note, IP hash, device identifier) | 90 days after the slot the request was for — then an automated job (the same one, once a day) permanently clears the first name, the note, the IP hash and the device identifier. The record itself stays without that data: the owner still sees that someone asked for that slot, from which room and how it ended, but no longer who it was. This happens automatically, regardless of the request's status (pending, approved, rejected, expired) and without any action from the owner. |
| Wellness bookings entered in the panel | The guest's name or note attached to a booking: 90 days after the session date — then the same automated job clears it (this also covers a name copied over from an approved guest request). The booking itself (space, room, time, price, settlement) stays until the owner deletes it; cancelling changes the status, it does not delete the record. |
| Events from booking calendars | Until they disappear from the source calendar — we then remove them at the next sync. |
| Property data (rooms, tasks, checklists, staff roster) | For as long as the property uses the app; deleted at the owner's request. |
| Staff technical accounts | Until unlinked from the roster (e.g. on a phone change) or removed from the roster. |
| Push notification tokens | Stale ones are removed automatically after a failed delivery. |
| Photos queued for upload on a staff phone | Once uploaded the file leaves the phone immediately; failed and completed queue entries are cleaned up after 7 days. |
| The guest browser's local storage | The list of sent requests — 2 days. The device identifier and chosen language remain until the guest clears their browser data. |
| Telemetry (Analytics, Crashlytics) | According to Firebase's retention periods (up to somewhat over a year). |
| Permission | What for |
|---|---|
INTERNET, ACCESS_NETWORK_STATE | Syncing tasks, checklists and photos with the backend. |
POST_NOTIFICATIONS | Notifications about new tasks and rework (Android 13+; we ask for the system permission, refusing it does not block work). |
FOREGROUND_SERVICE, WAKE_LOCK, RECEIVE_BOOT_COMPLETED, VIBRATE | Finishing photo uploads in the background and signalling notifications. Added by Google's libraries (WorkManager, FCM). |
AD_ID and related | Added by the Firebase Analytics library. We do not use the advertising identifier — see section 8. |
The app has no camera and no location permission. Photos are taken with the system camera app; a photo first lands in the app's private directory and, once uploaded successfully, is linked to the task and deleted from the phone.
Access to data is limited by server-side rules, not merely by hiding screens: a guest can read only the portal's public content, a housekeeper only their own property's tasks and their own roster record, and guest requests and the wellness schedule — the owner only. Connections use HTTPS. As the developer we hold technical administrative access to the backend; we use it solely for maintenance and diagnostics.
Under the GDPR you have the right to access your data, to have it corrected or deleted, to restrict processing, to data portability and to object to processing based on legitimate interests. For guest and staff data the right addressee is the property owner (the controller) — we will carry out whatever they ask. For the owner's account and telemetry the addressee is us. You also have the right to lodge a complaint with a supervisory authority (in Poland: the President of the Personal Data Protection Office, PUODO).
The app and the panel are work tools and are not intended for children under 16. We do not knowingly collect children's data. The guest portal does not ask for age — we ask that booking requests be sent by an adult from the reservation.
We will announce material changes in the app or on this page by updating the "effective" date.
The current version always lives at
https://tr0lczyk.github.io/pensjonat/privacy/.