--- title: "Edtripper | Directory & kiosk app | Croissant & Baguette" description: "We built Edtripper's directory of 958 venues and a kiosk-locked Android learning app with venue CMS, fleet cockpit and AI-drafted questions, live in 30 days." url: "https://croissantbaguette.com.au/projects/edtripper/" --- # Edtripper https://croissantbaguette.com.au/projects/edtripper/ We built Edtripper's directory of 958 venues and a kiosk-locked Android learning app with venue CMS, fleet cockpit and AI-drafted questions, live in 30 days. Client: Founder-led education business, Sydney · Industry: Education & attractions · Services: Web Apps, AI & Workflows, Automation · Stack: SvelteKit, Sanity, Cloudflare, Android, Hexnode, Claude · Date: 2026-08 · Live site: https://edtripper.com **Outcomes** - **958 venues listed** — across every state and territory, September 2026 - **30 days first commit to live phones** — app, venue CMS and fleet cockpit in 22 staged releases - **2 days to a working browser demo** — then hardened on real hardware - **107 ms answer acknowledged** — p95 with 30 students answering at once, on the live realtime worker - **0 student names kept** — first name, initial and an avatar for the session, wiped at the end ## A product that never launched, and a site that had to do more. Edtripper began before COVID as a device-based learning product for museums and attractions. The week before its first venue went live, the venues closed. The business pivoted to a website for teachers, and the original app survived only as a sales deck, screenshots and memory. By 2026 the founder had two jobs for us. The website needed to become a real directory that teachers would use and the business could run without a developer. And attractions were asking for the device product again, so it had to be rebuilt from scratch: phones the venue owns, an app that survives museum wifi, and the teacher report that worksheets and guided tours both lack. ## A directory teachers actually use. A SvelteKit site, server-rendered on Cloudflare Workers, with every word in Sanity so the team publishes without a rebuild. Every visitor is resolved to their state (from the URL, then a cookie, then their location), and that state runs through every query: a teacher in Victoria sees Victorian venues, stories and lesson ideas first. The directory lists 958 venues across every state and territory, filtered by subject, year group and attraction type, with verified badges, amenities, booking links and curriculum outcomes on the articles that point to them. Structured data and per-type sitemaps on every page, because teachers find excursions through search. The founder runs content through their own AI assistant: we wrote a Claude skill that knows the content model, so they can draft, edit and publish venues and articles by asking for them. ## One app, three modes, on phones the venue owns. A single Android build, locked in kiosk mode on the venue's own fleet. Students get a trail of up to 30 stops with multiple choice, freeform and photo questions, a map of the floor, a leaderboard and a chat line to their teacher. The teacher gets a live view of every student, a broadcast channel and a check-in before the group leaves so no phone walks out. Venue staff get a guide view. Every live tour runs on its own realtime worker, and the app keeps working when the wifi does not. After the visit, every answer lands with the teacher as a signed web report and a class certificate. Students are a first name, an initial and an avatar for the session, and nothing more is kept. ## The venue CMS and the fleet cockpit. Venues write their own programmes: questions, zones, points, a map builder with floors and pins, a device preview, a test mode and immutable published versions so a live tour never changes under a class. Questions can be drafted by Claude from the venue's own education packs, but they land as drafts for an educator to sign off, never straight onto a device. The cockpit shows every phone's heartbeat, battery, kiosk state and app errors, logs incidents, and gives venue staff the safe actions (re-lock, reboot, rescan) with a pairing code to enrol a new phone. Device management is Hexnode behind an adapter of our own: when Google refused the device quota halfway through the build, the switch changed one file, not the platform. An app update reaches every phone in under 90 seconds. ## Every enquiry read, judged and answered. An enquiry on a venue listing used to be an email somebody had to deal with. Now it is read as it arrives: real enquiry or spam, and if it is real it goes straight to the attraction. When that attraction is not yet a partner, the system looks their details up on their own website, checks that what Edtripper holds is still correct, and builds the outreach itself, with the teacher's enquiry, an introduction to what Edtripper does, and an intro pack written for that venue. It is the same idea as the question drafting in the venue CMS, pointed the other way. The work that never gets done because nobody has time is exactly the work worth handing to a system, with a person still holding the final tap. ## The numbers. Build and load-test figures from August 2026. The first school group is the next number. ## Theirs to keep. Both products live in Edtripper's own Cloudflare and Sanity accounts, in their repositories, with the phones enrolled in their own device-management tenant. Nothing sits with us that they cannot take. - **SvelteKit** the website, the app and the venue CMS - **Sanity** content for the website, published by the team - **Cloudflare** Workers, D1, R2, Durable Objects and Queues - **Android** kiosk-locked app built with Capacitor - **Hexnode** device management, behind our own adapter - **Claude** question drafting and enquiry triage through AI Gateway, human-approved - **Resend** teacher reports, certificates and sign-in links