App AI Automation Education & attractions
Edtripper
A directory and resource site for teachers, and an Android learning app for the venues they visit, locked onto phones the venue owns. Two products for one founder, built to run without us.
- Client
- Founder-led education business, Sydney
- Industry
- Education & attractions
- Shipped
- 2026
- Live at
- edtripper.com
Before
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 became a website for teachers, and all that remained of the original app was a sales deck, screenshots and memories.
By 2026 the founder had two jobs for us. First, the website needed to become a real directory that teachers would use and the business could run without a developer. Second, attractions were asking for the device product again, so it had to be rebuilt from scratch. It had to run on phones the venue owns, keep working when the museum wifi drops out, and give the teacher a report, which worksheets and guided tours don't.
What we built · 01
A directory teachers actually use.
The site is built with SvelteKit and runs on Cloudflare Workers. Every word lives in Sanity, the editor the team writes in, so what they publish goes live without a rebuild. Each visitor is matched to their state (from the web address, then a cookie, then their location), and every page uses it: a teacher in Victoria sees Victorian venues, stories and lesson ideas first.
The directory lists more than 950 venues across every state and territory, filtered by subject, year group and type of attraction. Listings show verified badges, amenities and booking links, and articles linking to a venue show their curriculum outcomes. Every page carries structured data for search engines, with a sitemap for each type of page, because teachers find excursions through search.
The founder also runs the content through their own AI assistant. We wrote a Claude skill that teaches it how the site's content is organised, so they can draft, edit and publish venues and articles by asking.
What we built · 02
One app for students, teachers and venue staff.
It is a single Android app, locked onto phones the venue owns. Students follow a trail of up to 30 stops with multiple-choice, written and photo questions, a map of the floor, a leaderboard and a chat with their teacher. The teacher sees every student's progress live, can message the whole group, and checks every phone back in before the group leaves, so none go missing. Venue staff get a guide view. Each live tour runs on its own real-time server, and the app keeps working when the wifi drops out.
After the visit, the teacher gets every answer in a web report on a secure link, and a certificate for the class. Students appear only as a first name, an initial and an avatar for the visit, and nothing more is kept.
Screens from the demo venue programme.
What we built · 03
The venue editor and the device dashboard.
Venues write their own programmes in the editor: questions, zones and points, a map with floors and pins, a phone preview and a test mode. Each published version is locked, so a tour never changes while a class is doing it. Claude can draft questions from the venue's own education packs, but they arrive as drafts for an educator to approve, never straight onto a phone.
The dashboard shows each phone's last check-in, battery level, lock status and any app errors. It logs incidents and gives venue staff the safe fixes (re-lock, restart, refresh), with a pairing code to add a new phone. Hexnode, a device management service, manages the phones through a connector we wrote. When Google refused the number of phones we needed on its own service halfway through the build, switching to Hexnode changed one file, not the whole system. An app update reaches every phone in under 90 seconds.
What we built · 04
Every enquiry read, sorted and passed on.
An enquiry on a venue listing used to be an email somebody had to deal with. Now each one is read as it arrives and sorted into real enquiries and spam. Real ones go straight to the attraction. When that attraction is not yet a partner, the system looks up their details on their own website, checks that what Edtripper has on file is still correct, and puts the outreach together itself: 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 editor, applied to outreach. The work that never gets done because nobody has time is exactly the work worth handing to a system, with a person still giving the final approval.
What changed
The numbers.
950+
venues listed
across every state and territory, September 2026
30 days
to build and launch
app, venue editor and device dashboard in 22 stages
2 days
to a working browser demo
then made robust on real phones
Build figures from August 2026. The first school group will give us the next number.
Runs on
No lock-in.
Both products run in Edtripper's own Cloudflare and Sanity accounts and code repositories, with the phones registered in their own device management account. Nothing sits with us that they cannot take.
- SvelteKit
the website, the app and the venue editor
- Sanity
content for the website, published by the team
- Cloudflare
hosting (Workers), database (D1), file storage (R2), live tours (Durable Objects) and background tasks (Queues)
- Android
the tour app, locked onto the venue's phones, packaged with Capacitor
- Hexnode
manages the phones remotely, through a connector we wrote
- Claude
drafts questions and sorts enquiries through Cloudflare's AI Gateway, with a person approving
- Resend
sends the emails for teacher reports, certificates and sign-in links
Same Oven
More work like this.
Same Oven
