Problem
A transport operation ran across separate systems — a legacy fleet system and the new platform. Passengers, captains, agents and companies each needed a different view, and nobody could carry their identity between systems.
Business Context
The platform connects four actor types: passengers booking rides and trips, drivers/captains accepting trips and managing earnings, travel agents, and transport companies. It ships as a business backend, mobile app, realtime services, web app and landing page.
Constraints
- Role-based signup: Captain → Captain Profile, Passenger → simple User, Company flow for admins/customers.
- Phone-based login as the entry point for captains.
- Existing captains from the legacy system had to arrive as full identities — users and employees — not loose records.
- Play Store distribution requires verified internal testing before release.
Analysis
The hard problems were identity and matching, not features. Bringing ten captains across from the legacy system meant creating Captain Profiles that cascade into Users and Employees under the right company. Trip matching and trip groups only make sense when identity is correct first.
Architecture
A business application backend owns the business engine: companies, captain profiles, trip groups, matching and phone login. Mobile and web interfaces consume the same APIs, while realtime services support the mobile layer.
Solution
Role-based onboarding, phone login, a captain profile → user + employee cascade, trip matching and trip groups, and a release pipeline that reached internal testing on Play Console (v20 verified healthy).
Technology
- Business application backend on dev/production servers
- mobile app (com.galaxylabs.ftms)
- realtime services
- modern web frontend
- Play Console internal testing
- private access and secure web routing infrastructure
Implementation
The captain import ran company-scoped, creating employee identities for each captain and fixing the mandatory-company gating that blocked the cascade. Each step was deployed to the production server and verified before the mobile release was built.
Challenges
Identity cascade rules, mandatory-company gating, guest-profile migration, nonce handling in phone login, and a two-session lifecycle test still outstanding before store release.
Outcome
The platform now has a real operating company, captains with full identity records, role-based signup, trip matching and groups, and a mobile app verified through Play internal testing.
Lessons
Multi-actor platforms succeed on identity. Import a captain as a record and the matching, earnings and permissions all wobble; import them as an identity — user, employee, company — and the platform holds.
Future Improvements
Store release, the two-session lifecycle test, guest-profile migration, and trip-earnings analytics per captain.