05 · Mobile · Flutter · Production

Trip Portal, one product, two apps

A travel product split into an admin app that runs the business and a customer app that sells the trips. Two Flutter apps, released together.

Role
Flutter developer, Cipher Craft
Platform
iOS & Android, two apps
Year
2025
Stack
Flutter, Dart, REST APIs, Bloc, iOS, Android
A tablet with a trip admin dashboard next to a phone with a customer travel app

Client apps under NDA. Screens are illustrative recreations with sample data.

2 appsAdmin and customer, both live
1 APIShared backend contract
On timeShipped alongside other client work
01 · Context

Where this started

A travel company needed staff to manage trips, bookings and customers, while travellers needed a simple way to browse and book. One app for both would have served neither.

02 · Challenge

What made it hard

  1. 01Two audiences with opposite needs: dense control for staff, calm browsing for travellers.
  2. 02Both apps had to stay in sync with the same bookings, on a tight timeline.
  3. 03Delivered while other client apps were also due.
03 · Process

How it came together

  1. 01

    Split by role, share the contract

    Two separate Flutter apps on one REST API, so changes in one never break the other.

  2. 02

    Admin: everything at a glance

    Trips, seats and bookings in dense, scannable lists built for daily operations.

  3. 03

    Customer: one trip at a time

    Big imagery, clear prices and a short path from browsing to booking.

04 · Decisions

Choices that shaped it

  • Two apps, not one with modes

    Separate apps keep each one small, fast and easy to review in the stores.

  • Shared models, separate UI

    Data models stay in step across both apps while each UI is free to fit its user.

05 · Reflection
Splitting the product was the most important design decision, and it was made before any UI. Sometimes the best interface is two interfaces.
Next case study · 01

Reading seizures from a single EEG channel

All work