Crew layover support
You land somewhere you do not know, in a language you may not read, with a fixed window before the next duty.
CREW Downtime is a working web app for crew on a layover. Tell AlbertAI who you are once, and it pulls real places around wherever you actually are — food, things to do, shopping, wellness, groceries, medical — ranked against that profile with nothing hidden. When the language is the problem, a two-way interpreter and a camera translator for signs and menus are one tap away. The public demonstration runs on real device location and live places data, and it says so on screen.
Status Pilot-ready, with a public demo on real device location and live places data. Before a pilot puts it in front of real crew, three items close: a consent flow, open security hardening, and time-based filtering, which is not yet built.
The problem
A crew member lands late in a city they may not know. A search for things to do answers none of the questions they actually have: what is near the hotel, what matches what they personally like, and whether they can read the menu or ask for directions in the local language. So the default becomes the hotel restaurant, and a layover that could have been a break is not one.
The answer
The app captures an About You profile once — language, age band, interests, food budget — and uses the device position, or a typed city or hotel, to pull real places from a live places provider with an open-map fallback. Every result is returned and grouped; profile matches rise to the top and nothing is hidden, so a crew member who likes barbecue still sees the vegan place, just lower down. Alongside it sit a two-way interpreter and an on-device camera translator, and the whole interface can switch language, including right-to-left scripts.
What it does · 5 capabilities
Each capability below exists in the build described on this page. Anything planned rather than present appears under status, not here.
Reads device position — or a city or hotel you type — and pulls live places grouped into food and drink, things to do, shopping, wellness, groceries and medical. Profile matches float to the top and every result stays visible. In our last check the public demo returned 98 real places around a live position.
Language, age band, likes grouped by type, and food budget are captured once and shape every search after that. The profile drives the ranking; it never removes a result.
Speak or type, and AlbertAI translates and speaks it back in the other language — and the other way round for the person you are talking to. Verified in the public demo with a typed English question returning the correct French.
Photograph or upload a sign, menu or label and the text is read on the device and translated. The whole interface can also switch language, including right-to-left scripts, so the app itself is not the language barrier.
Look up a destination before you land and save the plan as a trip on the device. Crew ratings and notes on places are switched off until crew identity and moderation exist.
Boundaries
Three questions any operator should ask before an evaluation, answered before you have to ask them.
CREW Downtime is advisory throughout: it finds, ranks and translates, and the crew member decides. Nothing in it touches flight duty, rest requirements, crew scheduling or any operational system, and it sits deliberately outside the safety-critical boundary the rest of this portfolio operates inside. An interpreter output is an aid, not an authority — a translation is offered for a person to judge, never as a decision the software has made.
This product handles real personal data, so the boundary is stated exactly. Device position is read only with browser permission, or typed by the crew member, and is sent to the demo’s server-side places proxy to find what is nearby; results may be cached there. The About You profile and saved trips stay in the browser on the device. Text and speech sent for translation go to a translation engine; camera text recognition runs on the device. No visitor-analytics beacon runs on this app. There is no consent flow yet for location, microphone and camera — that must exist before any crew pilot, and whether an employer could ever see a crew member’s position has to be answered in writing first. Our starting position is that it could not.
If position cannot be read, the crew member can type a city or hotel or plan ahead; failing that, a sample layover is shown and labelled as a sample. If the primary places provider fails, an open-map source is raced with timeouts before falling back to that labelled sample, so a search never hangs silently. Translation uses a primary engine with a fallback. One known weakness is named here rather than hidden: a failed translation can currently render as though it succeeded, which matters for an interpreter and is on the open list below.
The same questions answered across the whole portfolio, with dates: trust & safety
Honest status · Pilot-ready
Pilot-ready, with a public demo on real device location and live places data. Before a pilot puts it in front of real crew, three items close: a consent flow, open security hardening, and time-based filtering, which is not yet built.
Claims and evidence
If a claim below is worded more strongly than its basis justifies, it is a defect and we want to hear about it.
| Claim | Tier | Basis |
|---|---|---|
| Returns real places around the device’s actual position, ranked against the crew member’s profile with nothing hidden. | Evidence tier:Demonstrated | Public demo exercised September 2026 — live position, 98 places returned and ranked. |
| Translates a phrase two ways between the crew member’s language and the local one. | Evidence tier:Demonstrated | Public demo exercised September 2026 — typed English question returned correct French. |
| Reads text from a photographed sign or menu on the device and translates it. | Evidence tier:Demonstrated | Built and present in the public demo. Requires camera access or an uploaded photo to exercise. |
| Filters and ranks suggestions by arrival time and remaining layover. | Evidence tier:Concept | Inputs are captured and saved but not yet applied to results. Named as not built above. |
Fair questions
These are the objections this product actually gets. None of them has a clever answer, which is why they are worth printing.
On the current build they should not be asked to, because the consent flow does not exist yet — and we say so rather than burying it. The combination is the most sensitive in this portfolio. Before any crew pilot it needs explicit, granular permission for each sensor, a stated retention position, and a written answer to whether an employer can ever see a crew member’s location. Our starting position is that they cannot. We would rather have that argument before a pilot than after one.
Not yet, and the status section says so plainly. Arrival time, layover length and budget are captured and saved with a trip, but they do not yet filter or rank results. That is the next piece of work, and until it lands a crew member can still see somewhere that closes before they get there. We would rather print that than let the input fields imply something the app does not do.
Three things, and they are the first work in any pilot rather than footnotes to it. A consent flow for location, microphone and camera, with a written answer on whether an employer can ever see a crew member’s position. The rest of the security hardening from an internal adversarial review. And fixing a failed translation that can currently look like a real one. Time-based filtering is not yet built either, and we say so rather than letting the arrival-time field imply it. The demo shows what the product does; a pilot starts by closing that list.
Who buys this
The operators whose problem this product is actually shaped around. Each has its own path from first contact to a decision.
The people the rest of this portfolio is ultimately about — pilots and cabin crew, whether flying a scheduled regional line, an on-demand charter leg, or a light aircraft on a private flight.
Scheduled carriers running turboprop and regional-jet fleets, often on capacity-purchase agreements, with a real operations control centre and no eight-figure software budget.
Next step
The fastest way to judge it is on your own position: open the demo, set a profile, and search. Then tell us what a crew member at your airline would need before they would actually use it on a layover.