Elevon in ForbesA Visitor Books the Bike, the Operator Never Waits for a Developer
The brief was two systems at once: a mobile app for visitors to a region and a back office for the operator who maintains its content. We built both as one interactive prototype and attached it to the offer: ten app screens, nine back-office sections, four languages, offline-first, so the client could click through the whole thing before deciding anything.
Client
Tourism organisation
Industry
Travel & tourism
Solution
Visitor app and operator back office (prototype)
Deployment
Interactive prototype
Part of an offer, not a delivered project. Every screen below is clickable and runs on sample data.
The Brief
The brief covered two systems with two completely different audiences. A visitor app is judged by how it feels in the hand: how quickly you find a place worth visiting, how a route reads, how many taps a booking takes. A back office is judged by whether the operator's daily work fits into it: adding a point of interest, importing a GPX track, checking which language is still missing translations. Neither of those questions can be answered from a feature list in a document.
The second complication was the offline requirement. A regional guide is used where the signal is weakest: on a trail, in a valley, on a bike. Maps and GPX tracks have to work without a connection, which changes what gets packaged, when it downloads and what the app is allowed to promise while it is offline. Those are architectural decisions, and they are far easier to review on a screen than in a paragraph.
On top of that, four languages across both systems, including the back office. Translations that arrive as an afterthought at the end of a project are the usual reason a multilingual guide ships with two languages half-finished. And the operator wanted to know not only what the system would contain, but in what order the parts would arrive.
How We Designed It
So we did not describe the system, we built the parts nobody can evaluate from prose: the screens, the order they come in, and the label saying which milestone delivers which one.
Offline-first, shown on screen
The map screen shows the region package downloaded and ready, the point-of-interest detail is marked as available offline, the route detail has its GPX prepared, and turn-by-turn navigation runs without a connection. The prototype shows what "offline" concretely means here instead of leaving it as a bullet point.
Four languages, back office included
SK, CZ, EN and DE. The language is chosen during onboarding and switchable later from the profile. The back office has its own languages and translations section with coverage per language, so the operator can see what is still missing before a visitor does.
Screens labelled by milestone
Screens carry M1, M2 and M4 badges, so the client sees which part arrives when. That turns the conversation about scope into a conversation about sequence: what is worth having first, and what can wait for a later milestone.
How Delivery Would Run
Delivery would follow the milestones already marked in the prototype. M1 covers the foundation of the visitor app: onboarding with language selection, discovery with category filters, the point-of-interest detail and the map with the offline region package. M2 adds the six themed cycling routes, the route detail with its elevation profile and points along the way, and the booking flow: vehicle type, a calendar with blocked days, quantity, a live total and the confirmation screen. M4 covers the profile: language switching, the visitor's own reservations and offline map management.
The back office is the second half of the same delivery, and the prototype contains all nine of its sections: the dashboard with KPIs and charts, points of interest, cycling routes with GPX import, CMS pages, media, reservations, languages and translations with coverage per language, users with roles, and settings for the map module and integrations. Because each section exists as a screen, a scope discussion can point at a screen rather than at a paragraph.
Nothing here is deployed. This is a prototype built as part of an offer, running on sample data: sample points of interest, a sample user, an invented reservation number. If the client decides to go ahead, the prototype becomes the specification we build against, because the screens, states and flows have already been agreed on something everyone could see.
What this looks like in practice
The client clicks the visitor path end to end: pick a language, filter the region by category, download the offline package, open a cycling route with its elevation profile and the points along it, book two e-bikes on a date the calendar keeps free, and land on the confirmation. Then the same content from the operator's side: where that route was imported from GPX, where the reservation appears, and where the translations for it are maintained.
Visitor app and back office
Anonymized preview, running on blind sample data.
What the Prototype Proves
This is a prototype, so there is nothing deployed to report on. What the client can check by clicking is this.
Ten app screens clickable end to end, from onboarding to a confirmed reservation
Nine back-office sections as real screens, including GPX import and translation coverage
Offline behaviour made concrete: region map package, prepared GPX, navigation without a connection
Four languages across both systems, switchable in onboarding and in the profile
A booking flow with vehicle type, blocked days in the calendar, quantity and a live total
Milestone badges on the screens, so the delivery order is visible before anything is agreed
Why We Send a Prototype, Not a Deck
A tourism app is judged in the hand, not on paper. Whether a visitor finds something worth doing in the first ten seconds, whether a route reads clearly, whether a booking takes three taps or eight: those are the questions that decide whether the app gets used at all, and a document cannot answer any of them. A prototype answers all three in a minute.
On the operator's side the question is not which features exist but whether the daily work fits: adding a point of interest, importing a GPX track, seeing today's reservations, checking which language is behind on translations. Nine sections you can open answer that in minutes. A list of nine section names does not.
It also protects both sides. What the client clicked through is what we would build, and anything that turns out to be wrong is cheap to change now: while it is still a screen in a prototype, not a decision baked into a delivered system.
Want a similar transformation in your organization?
Let's talk about how Elevon can help your team too.
Book consultationRelated case studies