What we’re building next.

Ask for a town we have never built and we build it — there is no queue and no admission list, and the places built for you stay in the catalogue for the next host in the same area. The quality work runs behind that rather than in front of it: every month we re-check every venue website, try again to place the next batch of map pins that only ever landed on a neighbourhood, and check that the photographs we show straight from another site still load; the ones we keep ourselves are not part of that check. Venues that have shut for good are marked closed and left out of every guide made afterwards — though that audit is still something we run town by town rather than on a clock. A place asked for last week is thinner than Amsterdam; both get better on the same sweep.

This site, the screens you make guides in, and the guide in your guest’s pocket grew up separately and still look it. They now share a single set of colours, type and spacing, and we are partway through repainting each surface onto it. Quieter, more readable, less of the generic app-template feel — and legible in dark mode without a second design.

An automated accessibility check catches only some kinds of problem. It cannot tell whether the guide makes sense to someone moving through it with only a keyboard, or listening to it through a screen reader. So before we make any claim that the guide in your guest’s pocket is accessible, it needs going through by hand, both ways, by someone who did not build it — the check most likely to find what its builder cannot see. That is decided, and it has not started.

A guide can be written in English, Dutch, French, Flemish, German or Spanish, and since September this site is published in the same six. Adding a seventh is not hard technically — it is a commitment to keep every venue description, every interface string, every page of this site and every legal notice correct in it forever. We will add one when there are hosts whose guests need it.

A guide waits quietly on a guest’s phone until they open it. A note the evening before they arrive, or when something in their plan closes, would be genuinely useful — and is also the fastest way to become one more app that pesters people. If it is ever built it is yours to send, not ours: we do not email your guests, and we would rather keep it that way than own the contact with them. Later, and only if we find the version that does not nag.

We maintain a record of what data we process and why, a breach procedure, and a running account of where we stand on accessibility. Two of them now have a public summary, linked from the foot of every page: Security & privacy draws on the record — where the data lives, and which services handle it for what — and Accessibility gives the account’s standard, how we test and what is not right yet. The breach procedure is only named there, not published, and the documents themselves — the full record and the accessibility account with its test counts — still live in our own repository. Later we would like all three published as they are, including the parts that are not finished yet, because a page that only lists the passing checks is marketing, not a trust centre.

Your guides already carry your logo, your colours and your own support address, but the link still says vidiveni.app. Serving them from a domain you control is something we would like to offer, and it is deliberately not part of the pilot: every custom domain brings its own certificate and its own running cost, and that belongs in a pricing conversation we have not had yet. Later, and priced honestly when it comes.

Every guide draws on one shared catalogue, which is what lets a closure one guest reports fix the next guest’s guide as well. What it cannot hold is the bakery you send everyone to, or the terrace too local for any public list. A host’s own places need the same closed-venue and dead-link checks as the shared ones, they have to stay private to the host who wrote them, and they have to be removable on request — which is why they are not a text box we could add in an afternoon. Later, and first for the hosts in the pilot who keep asking.

During the pilot we set every host up by hand: you talk to us, we make your organisation, and we agree what it costs. That is deliberate while there are few enough hosts to talk to each one properly. You can already see what you are on: as the owner, you find your plan and your live guides against its limit on the Organization screen. Choosing a plan or changing it yourself, and paying for it by card, need things we have not built, so for now a change of plan is still a conversation with us. Later, once the pilot has shown us what a plan should contain.

Your booking system already knows who is arriving and when — the booking exists long before anyone opens our screens. A connection to it would let a guide be made from that booking automatically, so your guest has their link before they have packed. It is not scheduled: we would rather build it around what pilot hosts actually run than guess its shape now.

A hotel group with a hundred staff should not be managing a hundred passwords with us. SAML and SSO are the honest answer to that, and they are a long way from a pilot that currently measures its hosts in single digits. Later, when somebody actually has that problem.

A B&B in a village half an hour from the nearest town already gets a guide drawn around its own front door. When you save your address we look it up on the map once, and if the map knows your street, the guide’s places are found within about fifteen kilometres of your door rather than around a city centre — unless a town we already cover is close enough for you to share its catalogue. Your area guide then says how far each place is from your door, wherever we know precisely where it is. What is still to come is what a guide looks like where there is no bar street: the kinds of places it lists, and an evening that does not assume a bar. That is the second wave of the pilot; the first one is deliberately in cities, where the catalogue is already good.