Effective date: 13 September 2026
Shvila is a mobile trip-planning app. It is single-tenant: each deployment of Shvila runs entirely in the Amazon Web Services (AWS) account of the person or organisation that deployed it. There is no shared, central Shvila service, and no company operates one on your behalf. Your trip data is held in that AWS account and nowhere else.
The app contains no analytics SDK, no advertising network, and no third-party tracking or attribution library. It does not send device identifiers to third parties. Four narrow exceptions where data does leave the deployment's AWS account are listed in Requests that leave the deployment below; please read that section, because it is where the qualifications live.
[CONTROLLER NAME], [POSTAL ADDRESS],
[CONTACT EMAIL]), and the governing jurisdiction
([JURISDICTION]).
Whoever deployed the copy of Shvila you use controls the AWS account that stores your data. They decide who is invited, who has which role, how long data is kept, and when it is deleted. If you were invited to a trip, that is the person to contact about your data. The app's publisher does not have access to your deployment's AWS account or the data in it.
Shvila is invite-only. There is no self sign-up. A trip owner invites you by email address, and the deployment's Amazon Cognito user pool creates your user and emails you a temporary password. To create an account, the following is processed:
Authentication tokens are stored on your device in the operating system's secure storage (Keychain on iOS, Keystore-backed storage on Android).
Everything below is written to the deployment's Amazon DynamoDB table and Amazon S3 buckets in the operator's AWS account. All of it is encrypted at rest with AWS Key Management Service (KMS) keys belonging to that account, and every request is served over TLS.
| Data | Why | Where |
|---|---|---|
| Trips: name, dates, description, members and their roles | The trip itself | DynamoDB |
| Points of interest: name, type, address, coordinates, times, itinerary day, notes | The itinerary and the map | DynamoDB |
| Documents you upload: PDFs, images, emails and text files, plus their file names and kind | Vouchers, bookings and personal trip documents | S3 (bytes), DynamoDB (metadata) |
| Photos you attach, and their captions | Photos of a place | S3 (bytes), DynamoDB (metadata) |
| Check-ins: which point of interest, when, and your device location at that moment if you have granted location permission | Recording that you were there | DynamoDB |
| Ratings you give a point of interest | Your own rating, visible to the trip's members | DynamoDB |
| Place information text, fetched or written by hand | Background on a place | DynamoDB |
A copy of your trips is also cached on your device in a local database, so that the app works without a network connection. Edits you make offline are queued on the device until it can reach the deployment.
Location permission is requested only when you first use a feature that needs it. When granted, your position is used on the device to centre the map, to place a new point of interest where you are standing, and to suggest the nearest next stop. Your position is not uploaded unless you check in, and a check-in stores a single point at that moment, not a continuing track. If location permission is refused, check-ins are recorded without a location and the rest of the app works normally.
Camera, photo library and document-picker permissions are requested only when you use the matching feature: taking or attaching a photo, saving an exported photo back to your library, or uploading a document. The app reads only the items you select.
These are the exceptions to the statement that data stays in the operator's AWS account. Each one is a network request to a service outside it.
The map is drawn from vector tiles served by OpenFreeMap, built from OpenStreetMap data. Your device requests tiles directly, so the tile server receives the tile coordinates you are looking at (which reveals the map area, and so approximately where you are looking) and your device's IP address. The tile server is configurable by the operator and can be self-hosted; no request is made until you open a map.
Address search, address lookup and reverse geocoding are relayed through the deployment's own backend to a geocoding provider - Photon by default, with Nominatim and Google Places Autocomplete as configurable alternatives. The provider receives the text you typed or the coordinates being looked up, together with the backend's server IP address. Because the request is relayed, your device's IP address is not sent to the provider. Where Google Places Autocomplete is enabled, only address strings are stored; place coordinates, ratings and photos from Google are neither stored nor displayed.
When you ask the app to fetch background information for a place, the deployment's backend queries the public Wikipedia REST API with the place title or coordinates. Wikipedia receives that query and the backend's server IP address.
On start-up and when returning to the foreground, the app asks a shared version-check service operated by the app's publisher whether a newer version exists. The request carries the app identifier, the platform (iOS or Android) and the installed version number. It carries no account identifier, no device identifier and no trip data, and the response is only a version verdict. This service is shared across the publisher's apps. If the request fails, the app carries on silently.
A future version of Shvila will offer to read booking details out of documents you upload, using Amazon Bedrock inside the operator's own AWS account and region. When that feature ships, document contents will be sent to Bedrock within that account; AWS does not use content submitted to Bedrock to train its models. This feature is disabled in the current release.
Data is kept until it is deleted. There is no automatic expiry, and no scheduled deletion of inactive accounts. Deleting a trip removes its points of interest, documents, photos, check-ins and ratings. Superseded versions of a stored file are retained for a limited window by the deployment's storage configuration before being removed, so a deletion may take a short time to become irreversible. Retention beyond that is at the discretion of the deployment's operator.
Depending on where you live, you may have additional statutory rights over your personal data. Requests of that kind are handled by the deployment's operator, identified at the top of this policy.
Shvila is not directed at children. Accounts can only be created by invitation from a trip owner, so the app never collects information from anyone who has not been invited by someone who knows them.
This policy may be updated. The effective date at the top changes when it is, and the current version is always the one published at this address.
Questions about the app itself: support-shvila@beetee.ai. Questions about the data held in a specific deployment go to that deployment's operator.