Journora | Flutter AI Travel Planner App Template

Journora is a complete Flutter app template for planning a trip — 22 screens covering the brief, a day-by-day itinerary, a document wallet, a split budget, a packing list, onboarding, auth and settings, in light and dark. It runs on your own API key, and it also runs on no key at all: Demo mode ships switched on and answers from bundled sample itineraries, so every screen works the moment you press run.

Name a city and a number of days, and a full day-by-day itinerary comes back — morning, afternoon and evening, with a theme for each day and a per-person cost on every stop. Then it stops being a plan and becomes the trip: the documents you need at the desk, the money the group owes each other, and the list of things still to pack. There is nothing to deploy and nothing to host: no server, no Firebase, no vendor SDK, and the buyer’s API keys go to the iOS keychain and to encrypted storage on Android.

What’s in the package

• Full Flutter app source code — 22 screens and sheets, null-safe, and flutter analyze comes back with zero issues
• Light and dark themes, declared side by side in a single app_colors.dart file, with the switch in the app on the You tab
• A bundled library of 12 destinations and 6 full sample itineraries — real places, day themes, per-stop costs and practical notes, written out rather than generated
• Four runtime dependencies only — get, http, flutter_secure_storage and cupertino_icons. No vendor AI SDK is used anywhere, so no provider package update can break your build
• Schibsted Grotesk, Albert Sans and Caveat bundled as variable font assets with their SIL Open Font License files, plus 15 photographs under the Pexels License with a credits file; nothing is fetched at runtime
• Clean GetX architecture — view to controller to service to data. No screen ever reads the mock layer, so replacing a service method body is all it takes to go live
• A deterministic demo data layer — no wall-clock dependency in the seed data, so every screen renders the same on every run
• Offline HTML documentation, 16 sections — setup with and without the terminal, a terminal glossary, a screen tour, a provider key walkthrough, request headers and error handling per provider, what to do when a model name is retired, re-skinning, the project structure, connecting your own backend and troubleshooting
• 74 widget and service tests, including the settlement arithmetic and the document expiry maths, plus an integration walkthrough that drives every screen

Who is this for

• Flutter developers shipping a travel planner who want the parts nobody else finishes — the document wallet, the group settlement, the packing rules — already solved
• Freelancers and agencies with a travel or tourism client: re-skin one theme file, paste the client’s key and hand it over
• Founders validating a travel app who need something real in front of users this week, without paying for a server first
• Product teams at tour operators, destination brands and travel agencies who want a modern reference app to build on

Say where and how long — get a day-by-day plan

The brief is four controls and a row of chips: how long, how many of you, how soon, then pace, budget and interests. A day stepper, not a calendar range picker — “how long” is the question a planner actually asks, and “which dates” is the question a booking engine asks. Those answers are turned into one plain-words prompt, sent once, and parsed back into dated days. Pace and budget each get their own row, because those two change a plan more than anything else.

A day that reads like a day

Not a flat list of times. Each day is three labelled stretches — morning, afternoon and evening — and every stop is a folder card with its own type, cost, duration and neighbourhood. A generated plan’s times are suggestions, and grouping them says so honestly instead of dressing a guess up as a schedule. Long-press a card and drag it into a different part of the day.

Travel documents that work with no signal

Passports, insurance, cards and bookings live on the device. Nothing here needs a network, which is exactly when you need a policy number read out to you. Anything inside thirty days counts down, then shouts: it gets a raspberry Renew now chip with the days left and is lifted into its own Needs attention slot at the top of the tab. Sensitive fields stay masked until you ask — a passport number reads as ••• 2270 until the eye reveals it, the copy icon puts it on the clipboard, and a value too short to mask safely stays hidden whole.

One tap tells the group who owes whom

Everyone logs what they paid and who it was for, and the screen answers the only question a group actually argues about. Journora nets the balances down to the fewest transfers that clear the trip — $815 spent, $272 each — 2 transfers settle it — and phrases the result as an instruction rather than a balance sheet. No spreadsheet, no arguing at the airport. Spending reads as five categories in one bar, and every slice of it is a logged expense you can tap.

Three AI providers, or none at all

Every call is a plain REST request written by hand — no vendor SDK, so no provider package can break the build. Nothing is proxied through a server of ours.

• Google Gemini — the default. A key from AI Studio is free and needs no credit card, so your users are never sent to a billing form on their first run.
• OpenAI — strong, predictable writing. The key needs a payment method, which suits an app with paying users.
• Anthropic Claude — long, careful plans; it holds a multi-day brief together. Also pay-as-you-go.
• Demo mode — bundled sample itineraries. No key, no network, no cost, and every screen fully populated.

Model names expire, and this template is built for that: every model id is an editable field in Settings rather than a constant in the source, so when a provider retires one the fix is typed into the app instead of recompiled into it. The app says so in a sentence a user can act on and offers a button straight to the field. Adding a fourth provider is one class and one catalog entry — no screen changes.

One palette, two themes

Both themes are declared side by side in app_colors.dart and the switch is in the app, on the You tab. The dark side lifts the ochre to amber so it still reads on brown. Re-skinning is an afternoon, not a rewrite: every color is a token in app_colors.dart, every typeface is a family constant in app_text_theme.dart, and every corner radius and margin lives in app_spacing.dart. Swap the photography by dropping files into one folder — a missing image falls back to a drawn glyph instead of crashing the screen.

22 screens, all built

Twenty of them are on this page. The other two are the paywall’s upgrade sheet and the add-expense sheet, both modal. 12 destinations and 6 sample itineraries ship inside, so nothing on this page is a placeholder — every screenshot here is the app running in Demo mode with no key and no network.

Built to be handed over

A template a buyer can run on the first try, re-skin from one file, and point at their own API key without opening a single screen file. Views never reach into the mock layer, all three typefaces are bundled so the interface renders identically on a cold first launch and on a plane, and the documentation says where every seam is.

Get it running in five minutes

Unzip, run flutter pub get, run flutter run. That is the whole setup — there is no server to start, no database to create, no key to register and no account to sign up for. The first thing you see is a working app in Demo mode, and you add a provider key later only if you want live generation.

Try it before you buy

The Live Preview runs the real app in your browser, in Demo mode. Generate a plan from the brief, open a day and drag a stop into the evening, reveal a masked passport number in the wallet and settle a group budget — the four screens this template is built around are all clickable before you spend anything.

Requirements

Flutter SDK 3.29 or newer, Dart 3.7 or newer, and Android Studio or VS Code. Android and iOS. No server, no Firebase, no database.

Third-party costs and honest limits

• Third-party API costs are yours. Journora ships no keys and no included quota. Connecting it to Gemini, OpenAI or Claude will involve those third-party services, which will incur their own separate costs not included in this item. Gemini has a free tier that needs no credit card; the other two require a payment method. Demo mode is free forever and needs no key at all.
• A generated itinerary can be wrong. Opening hours, prices and whether a place is open at all are the model’s best guess, not live data. Journora says so on the screens that show them. Check with the operator before relying on any of it, and do not treat a generated plan as a booking.

What’s not included

• No backend and no bundled planning engine. Generation runs against a provider you choose with your own key. Demo mode is a set of bundled sample itineraries, not an offline model.
• Demo mode ships six hand-written itineraries — Kyoto, Lisbon, Iceland, Mexico City, Bangkok and Copenhagen — plus a generic fallback for anywhere else. It is enough to walk every screen end to end, and it never pretends to know a city it was not given.
• Trips, documents, expenses and packing lists live in memory for the demo. They reset to the sample data on restart; only the API keys are persisted, in the iOS keychain and in encrypted storage on Android. Every service method returns a Future and touches the mock layer in exactly one place, so writing them to disk or to your API is a body swap with no screen changes.
• If secure storage is unavailable the app says so and keeps keys in memory for that session only, rather than failing silently or writing them to plain preferences.
• Document attachments are recorded, not opened. The wallet stores a file record on the device; opening it needs whichever file-viewer package you prefer. The documentation covers where to add it.
• The paywall is a mock. Plans, a daily generation quota and an upgrade flow are all wired up, but no payment code ships — real purchases need your own store products and receipt validation.
• English only. No localization files or RTL layouts are included.

Support and updates

Questions about setup, providers or re-skinning get an answer through the item’s comments, normally within one to two business days on weekdays. Item support covers the template itself; it does not cover a provider’s own account, quota or billing.

Changelog

1.0.0 — Initial release.