Privacy
If our servers were broken into, what was taken would be useless.
That is not a promise about how careful we are. It is a statement about how the thing is built: your customers' details are not on our servers to begin with, so there is nothing there for anyone to take. This page explains exactly what we do hold, what we cannot hold even if we wanted to, and how you can check.
The two lists
Two lists, and nothing ever moves from one to the other.
Most companies would publish the left-hand list and call it transparency. The right-hand one is the list that actually matters, because a court order, a break-in, or us being bought by somebody else still cannot turn any of it into data we have.
Our servers may hold
The business side, which is ours to run
- Your account — the person who pays for the subscription, and nobody else.
- Your plan, how many seats you bought, your invoices, your own settings.
- Past rounds, but scrambled, alongside harmless details: a reference number, times, and how many stops went which way.
- Doorstep photos, scrambled, if you want them to outlast the driver's phone.
- "Something changed" nudges: a meaningless reference and one word from a short fixed list.
- Crash reports and overall usage counts.
Our servers can never hold
The parts that would make a break-in matter
- A customer's address in readable form. Not ever.
- A customer's name or phone number.
- Where a vehicle is — there is nowhere for that to be stored.
- The key inside a tracking link.
- The private key that lives on a driver's phone.
- What was in the order.
Drivers never sign in — their phone is set up once and that is that. Customers never sign in — they just have a link. You are the only person here with an account, and that is the whole reason there is no list of people for anyone to leak.
The link
The secret part of a tracking link never leaves the browser.
A tracking link does exactly one thing: it lets one person watch one vehicle until a set time. It works like a key rather than an account — and where in the web address that key sits is a genuine safety feature, not a design quirk.
https://wayfind.link/#7Qk2…tR9v~aM4pX1c
└─ sent to the server ─┘ └─ never leaves the browser ─┘
This part gets sent, the same way it does for any website you open. All it says is which page to show. It gives away nothing about which round, which stop, or which person.
This is the key, and web browsers are built never to send this part to anyone. Not to us, not to whoever delivers the page, not to any site the person visits next. There is no server anywhere that could receive it, including ours.
One thing is allowed in the part that does get sent: a hint about which machine a phone should call first, so a device opening the page cold can find the van at all. That is a phone-number-for-computers, not a key — it unlocks nothing. The app carries a check that refuses to run if a key ever ends up in the sent half by mistake, and that check runs for real customers, not just in testing.
The arrival time
Worked out on the phone of the person waiting.
This sounds like a small detail and is really the whole design. A normal tracker works out your arrival time on its own computers — which means it has to be told which doorstep you are standing behind. That one fact, this person is waiting at this address, is the most sensitive thing in the whole system, and an ordinary tracker creates it just by answering the question.
What the van gives off
Where it is, how far down its list it has got, and a scrambled fingerprint of the round — never the round itself. Everyone holding a link receives the same thing, and it tells them nothing about anybody else's stop.
What the waiting phone does with it
It works out the driving time from the van to your door, using a map it already has, and puts a number on the screen. The question is asked and answered without ever leaving the phone, so there is no server that could overhear the answer.
Notifications
A notification is a doorbell, never a letter.
This is the one place the promise is genuinely hard to keep. Phones talking directly to each other cannot wake a phone that is asleep in a pocket — only Apple's and Google's notification services can do that, and those are somebody else's computers. So a Wayfind notification only ever says something changed. Once you tap it, the phone goes and gets the real thing the usual private way.
The obvious way to guarantee that does not work. You cannot reliably scan a message for addresses — 15 Rue de la Gare looks like any other short phrase, and a filter that misses things is worse than no filter, because it looks like protection. So the wording is not written when the notification is sent. There are seven possible notifications, the words are fixed in the app, and this is all of them:
That is the whole list. There is no box anywhere for anyone to type something else into, which is a much stronger thing to be able to say than "we check the messages". And when a notification comes back through Apple's or Google's servers, the phone re-creates the wording from that list and throws away whatever actually arrived — otherwise the fixed list would be decoration. The wording is also deliberately vague about whose delivery it is, because a notification lands on a lock screen, and lock screens get read over people's shoulders on the bus.
Proof of delivery
We store the photo. We are not the reason you can trust it.
A doorstep photo counts as evidence because the driver's phone signed a fingerprint of it at the moment it was taken — not because of where the file ended up. So the file itself can sit anywhere, including with us, scrambled so that we cannot open it. The key that would unscramble it belongs to the round, and it is not in the tracking link and cannot be worked out from one.
A customer's page will tell them a photo exists, because that fingerprint is public and signed. It will not try to show them the photo, because that would only fail. A screen that sat there loading would be hinting at a permission the person does not have.
Maps and routing
An ordinary map file, not a service that bills you per lookup.
In most dispatch tools, typing an address sends it away to a search service. Here there is nowhere to send it. The list of places is a public map file, and your device reads just the few pages it needs out of it — the way you would open a phone book at the right letter rather than posting your question to someone. The address is worked out on the machine that typed it.
There is no photographic map behind it
That is deliberate, not a shortcut. Every supplier of those map backgrounds wants an account and a bill per view, and an account is the one thing this product refuses to have. Instead it draws the actual roads the van will drive, from the map file already on the device.
The picture and the time always agree
Because both come from the same map file. When the drawing comes from one source and the arrival time from another, the two can disagree — and when they do, the screen is lying in at least one of those two places.
There is no map of the whole world here, and out of the box there is no map at all — you load the region you work in. Somewhere with no map loaded still shows everything the van reports, and simply refuses to invent an arrival time. That is the honest way to fail, and a considerably less profitable one than guessing.
Honesty you cannot switch off
The screen cannot promise more than it knows.
Every product in this category promises not to show a confident time it cannot back up. Promises like that quietly rot. Here the app is simply built so that the misleading version cannot be produced — not discouraged, not flagged in a review, genuinely not possible.
| The tempting thing to show | Why it cannot appear |
|---|---|
| An arrival time for a stop the driver already skipped | A skipped stop has no arrival time attached to it. There is nothing for the screen to print, so nothing gets printed. |
| A moving dot for a driver whose position is deliberately vague | When an operator chooses not to share exact positions, there is no position for the map to draw — not a blank one it might fill in with a guess. |
| Calling an old position "live" | After ninety seconds with nothing new, the app has to stop calling it live. It says the position was taken down rather than leaving a dot that still looks current. |
| An estimated time for a parcel that already arrived | What actually happened to a stop is checked before any estimate is allowed to say anything at all. |
There is a version of this written for engineers further down, if you want to know exactly how it is guaranteed rather than promised.
Children
We do not build a live map of a bus full of other people's children.
Every competitor in school transport sells exactly that and calls it peace of mind. A parent using Wayfind hears about their own stop and nothing else: "the bus has left stop 7 — yours is next, about six minutes". Children's names never reach the driver's phone at all. As far as the app is concerned a stop is a place with a number of children at it, and the school office keeps the rest.
Stops-only is how school transport arrives out of the box, and it is the one setting an operator has to go out of their way to change — with the app explaining, in plain words, what they are about to give up. It works this way because of how the system is built, not because of a policy we promise to keep, and that is the only kind of promise worth anything.
For the technical reader
Everything above, stated the way an engineer would want to check it.
The rest of this page is written for the person buying it. This last part is for whoever they hand it to. Nothing here contradicts anything above — it is the same claims with the mechanism left in, so you can verify them instead of believing them.
The engine underneath Wayfind, including the routing and the mesh protocol, is a separate open library: rangefind.dev. The claims on this page are properties of that protocol, which means you do not have to take them from us.
The engine
rangefind.dev
Search and routing served straight from static files by HTTP range request — no search server, no per-query bill. Wayfind is the product; this is the thing it is built out of.
The place index
osm.rangefind.dev
The published OpenStreetMap build an address is resolved against. It is a static artifact you can read byte ranges out of yourself, which is the whole reason no address has to be sent anywhere.
The fragment never leaves. Open a tracking link with your
browser's network panel recording. The request line and the referrer
both stop at the /. Nothing you can do to that page will
make the capability appear in a request.
The engine really is read by byte range. Measured against a
280,909-byte bundle on a live deploy — a host that ignores
Range turns a 4 KB query into a 76 MB download, so this
is worth checking against any host:
GET -> 200, 280909 bytes GET Range: bytes=0-99 -> 206, 100 bytes accept-ranges: bytes
The apps run with no cloud project at all. Every service sits behind a narrow port, and the apps are required to work with that port absent — no account, no network beyond the static index. That is the configuration a fleet running its own infrastructure will actually use, and it is also the one you can evaluate without talking to us.
The honesty rules are types, not review comments. A claim's
weaker variants do not carry the field a stronger claim would need:
a skipped stop has no arrivalMillis to render, and a
coarse run has no position field rather than a null one
— because a nullable field in an otherwise-live shape is a hole some
component eventually fills with a placeholder. Making the misleading
state unrepresentable is the only version of this that survives a
deadline.
A wake-up has no free-text field. Callers name a
kind from a closed set and the copy is chosen in
packages/core/src/services.ts; the subject must match
/^[0-9a-f]{8,64}$/, a constraint that admits no street
names, and anything else throws rather than being sanitised. The only
caller-supplied variable is a 0–255 integer the protocol already
broadcasts to every link-holder. "There is no parameter through which
an address could travel" is a stronger claim than "we filter for
one", and it is the one that is true here.
What we will not build
The list is as much a part of the product as the features.
A live map of children
Covered above. It is the single clearest case where the commercially obvious feature is the wrong one.
Accounts for your customers
A link works like a key. There is nobody to sign in as, which is exactly why there is no list of people to steal.
Watching drivers
No behaviour score, no idle-time report, no alert when a break runs long. A dispatcher can see the work, because the job needs that. They do not get to see the person.
A switch that turns the honesty off
There is no setting, anywhere, that lets an operator show a confident arrival time the system cannot actually back up.
This page explains how the product is built and what it is capable of holding. It is not the legal privacy notice. If you need the formal document — who the data controller is, how long things are kept, how to exercise your rights — ask us for it rather than reading it into this page.