Case studies

The systems behind the booking button.

Each of these is a slice of production travel technology — the problem, the engineering constraints, the decisions I made and what shipped.

Some project details and visuals have been generalized to respect company and client confidentiality.

01Farenexus

nexusKite — Corporate Flight Booking App

Enterprise Mobile · Travel Technology

nexusKite, Farenexus Group's corporate travel booking app — built from an empty repository into a production Flutter application on iPhone, iPad and Android. It puts flights, hotels and vehicles behind one search, with NDC and GDS content, negotiated corporate rates, seat selection, ancillaries and real-time corporate profiles. Rated 4.9 on the App Store.

nexusKite · app profile

Live app · store data
Platforms
iPhone · iPad · Android
Category
Travel
Store rating
4.9 (App Store)
Publisher
Farenexus Group
  • Flights, hotels and vehicles from one search
  • NDC + GDS content with negotiated corporate rates
  • Seat selection and ancillary services
  • Real-time corporate profiles, preferences and policy
  • Booked, ticketed, approved, rejected and cancelled states
  • In-app support for booking issues
  1. Search
  2. Selection
  3. Pricing
  4. Seat
  5. Booking
  6. Confirmation

01 — Context

Farenexus's corporate travel platform had no mobile channel. Business travellers expected to search, book and manage trips from a phone, with negotiated fares, travel policy and approval workflows intact.

02 — Challenge

  • Airline data arrives as large, deeply nested JSON that does not fit a naive UI model.
  • State has to stay coherent across a multi-step flow where any step can invalidate the previous one.
  • Two different supply standards — GDS and NDC — must feel like one product to the user.
  • Corporate bookings carry extra states: booked, ticketed, approved, rejected and cancelled.

03 — My role

Sole architect and builder of the mobile app: architecture, state strategy, GDS/NDC integration, seat map rendering, performance tuning and release management on both stores.

04 — Architecture

Clean architecture with clear separation between the booking domain, data sources and presentation. GetX manages cross-step state so search context, fare selection, corporate profile and passenger data survive the whole journey.

05 — Engineering

  • Chose Flutter for a single codebase across iOS and Android under a small team.
  • Kept booking rules out of widgets so backend contract changes touch one layer.
  • Treated backend failure as an expected state, not an exception path.

06 — Product flow

  • One search across flights, hotels and vehicles
  • NDC + GDS content with negotiated corporate rates surfaced first
  • Interactive seat map and ancillary services
  • Real-time corporate profiles, preferences and travel policy
  • Trip management across booked, ticketed, approved, rejected and cancelled bookings
  • End-to-end booking: search → selection → pricing → seat → booking → confirmation

07 — Production

Live on the App Store (4.9 rating) and Google Play as nexusKite, Farenexus Group's corporate travel booking solution — released through TestFlight and both store consoles, with provisioning managed in-house.

08 — Lessons

Modelling the booking as one transaction rather than four screens removed a whole class of state bugs before they happened.

Outcome

A production mobile booking surface that stays usable when upstream airline systems are inconsistent. Live on the App Store (4.9 rating) and Google Play as nexusKite.

FlutterDartGetXREST APIsGDSNDCiOSAndroid
App Store Google Play Product page
02CodeNomad

RemitAssure — Cross-border Money Transfer App

Fintech · Cross-border Payments

A fintech mobile app for digital peer-to-peer international remittances — built on a purpose-built remittance platform offering competitive live rates for people supporting family overseas, paying international tuition or settling business payments. Shipped on iOS and Android across a long release line, from v1.1 to v1.6.9.

RemitAssure · app profile

Live app · store data
Platforms
iOS · Android
Category
Finance
Store rating
5.0 (App Store)
Releases
v1.1 → v1.6.9
  • Digital peer-to-peer international remittance
  • Bank and recipient search across corridors
  • Competitive live exchange rates at quote time
  • Transfer tracking from payment to payout
  1. Quote
  2. Recipient
  3. Payment
  4. Confirmation

01 — Context

Cross-border money transfer is a trust-sensitive product: users commit real money, so every step of the transfer flow must be clear, secure and reliable — and the rate they are quoted has to hold.

02 — Challenge

  • Financial transaction flows where a failed or duplicated transfer is not an acceptable outcome.
  • Secure handling of payment and identity-related data across the transfer journey.
  • Integrating payment, bank-directory and compliance APIs whose responses must be handled defensively.
  • Sustaining a long, frequently released app without regressions in the money path.

03 — My role

Mobile development on the RemitAssure app during my time at CodeNomad — feature delivery, API integration, performance work across releases and store deployment.

04 — Architecture

A mobile client built around a clearly separated transaction flow — quote, recipient, payment and confirmation — with defensive API integration at every boundary.

05 — Engineering

  • Model the transfer as a single guarded transaction rather than disconnected screens.
  • Treat every payment API response as untrusted until validated.

06 — Product flow

  • Peer-to-peer international transfers at live, competitive rates
  • Recipient and bank search across corridors
  • Secure payment and transaction handling
  • Transfer status, tracking and history

07 — Production

Published on the App Store and Google Play, handling live international money transfers across a long release line from v1.1 to v1.6.9.

08 — Lessons

In fintech, clarity is safety — every ambiguous state in a transfer flow is a support ticket or a lost customer.

Outcome

Live on the App Store and Google Play, serving real cross-border transfers through a steady release cadence.

AndroidiOSFintechREST APIsPayments
App Store Google Play remitassure.com
03CodeNomad

Cleaner Network — Local Services Marketplace

Marketplace · Local Services

A marketplace app that connects customers with vetted, independent local cleaners. Customers find and book trusted help at home; cleaners manage their own schedule, set their own hourly rate and accept jobs within a chosen distance. Live on the App Store and Google Play.

01 — Context

Finding a reliable local cleaner is usually reduced to word of mouth, flyers or social posts — a slow, inconsistent process for customers and a barrier for independent cleaners trying to grow a business.

02 — Challenge

  • Two-sided marketplace: the product must serve distinct customer and cleaner journeys.
  • Trust and transparency: verified profiles, reviews and secure payments before a cleaner enters someone's home.
  • Booking and scheduling logic that handles availability, distance and preferred rates.
  • Secure payment processing and payout handling in a services marketplace.

03 — My role

Mobile development work on the Cleaner Network app during my time at CodeNomad — feature delivery, API integration and marketplace UI implementation.

04 — Architecture

A mobile client built around separated customer and cleaner experiences, with REST API integration for search, booking, scheduling, payments and reviews.

05 — Engineering

  • Design distinct flows for each side of the marketplace while sharing core services.
  • Treat scheduling, payment and review state as part of one transaction to avoid mismatched bookings.

06 — Product flow

  • Customer search and booking flow
  • Cleaner diary, rate control and job acceptance
  • Verified profiles, reviews and badges
  • Secure in-app payments
  • Support and trust tooling

07 — Production

Published on the App Store and Google Play as Cleaner Network, connecting customers with local independent cleaners through a two-sided marketplace.

08 — Lessons

A two-sided marketplace has two UX products in one codebase; solving one side's flow while ignoring the other creates an imbalance that shows up in bookings.

Outcome

Published on the App Store and Google Play as Cleaner Network, connecting local cleaners with customers.

AndroidiOSREST APIsMarketplacePayments
App Store Google Play cleaner.network
04Farenexus

Flight Search Engine

Search · Performance · APIs

The mobile search experience over airline supply — the highest-traffic and heaviest surface in the product.

Search results

Conceptual representation
DEL → YYZ
1 stop₹64,210
DEL → YYZ
1 stop₹58,940
DEL → YYZ
2 stops₹51,300
loading next page…

01 — Context

A single search can return an enormous payload of itineraries, fare families and rules. Rendered naively, the list stutters and the app runs out of memory.

02 — Challenge

  • Large API responses that must be parsed without blocking the UI.
  • Pagination that keeps scroll position and filter context intact.
  • Result rendering fast enough to feel native on mid-tier hardware.

03 — My role

Built the search flow end to end and owned the rendering and memory optimisation work behind it.

04 — Architecture

Paginated fetching layered over a normalised result model, with rendering optimised for long lists and memory reuse.

05 — Engineering

  • Paginate at the data layer rather than trimming results in the UI.
  • Optimise rendering and memory usage instead of capping result counts.

06 — Product flow

  • Paginated flight search
  • Large-payload handling
  • Smooth long-list scrolling

07 — Production

Shipped as the entry point of the production booking app on both stores.

08 — Lessons

Paginating at the data layer, not the UI, is what keeps memory flat as a result set grows.

Outcome

Smooth scrolling through large flight search result sets.

FlutterDartREST APIsPagination
05Farenexus

Pricing Validation System

Travel Technology · State Management

The safeguard that keeps the price a traveller sees consistent with the price the airline will honour.

State across steps

Conceptual representation
  1. Flight selectionvalidated
  2. Pricing validationchecking
  3. Passenger detailspending
  4. Bookingpending
  5. Confirmationpending

01 — Context

Fares can shift or disagree between booking steps. Any inconsistency reaching confirmation becomes a failed booking and a lost customer.

02 — Challenge

  • Detecting price inconsistencies across sequential booking steps.
  • Debugging pricing issues from the mobile side with limited backend visibility.

03 — My role

Designed and implemented the validation logic and led debugging of pricing and booking issues from the client side.

04 — Architecture

Validation checkpoints between booking steps, with pricing state carried through the flow rather than re-derived per screen.

05 — Engineering

  • Validate before commitment rather than after failure.
  • Instrument the flow so pricing bugs are diagnosable from mobile logs.

06 — Product flow

  • Cross-step price validation
  • Inconsistency detection
  • Clear user-facing recovery

07 — Production

Runs inside every production booking made through the mobile app.

08 — Lessons

Validating before commitment turns a failed booking into a recoverable moment for the user.

Outcome

Pricing inconsistencies surface early instead of at confirmation.

FlutterDartGetXREST APIs
06Farenexus

Interactive Seat Map

Rendering · Booking · Mobile UX

A touch-first seat map rendering real aircraft layouts with live availability and selection.

Seat map

Conceptual representation
26ABCDEF
27ABCDEF
28ABCDEF
29ABCDEF
selected occupied available

01 — Context

Seat maps are dense, aircraft-specific and heavy. Off-the-shelf list widgets cannot express a cabin layout.

02 — Challenge

  • Custom rendering logic for varying cabin configurations.
  • Keeping interaction responsive while the map is heavy.

03 — My role

Built the seat map rendering and selection logic and tuned its performance.

04 — Architecture

Custom rendering layer driven by airline seat-map data, with selection state held in the shared booking state.

05 — Engineering

  • Build custom rendering rather than force seat data into generic components.

06 — Product flow

  • Aircraft layout rendering
  • Seat availability and selection
  • Optimised redraw

07 — Production

Delivered as part of the production booking flow on iOS and Android.

08 — Lessons

When the data has its own geometry, generic components cost more than custom rendering does.

Outcome

Heavy seat maps remain smooth and selectable on real devices.

FlutterDartCustom RenderingGDSNDC
07Farenexus

End-to-End Booking Flow

Travel Technology · State Management

The complete transactional journey, where every step depends on state established by the last one.

State across steps

Conceptual representation
  1. Flight selectionvalidated
  2. Pricing validationchecking
  3. Passenger detailspending
  4. Bookingpending
  5. Confirmationpending

01 — Context

A booking is a long transaction across unreliable networks and changing upstream data. Losing state mid-way loses the sale.

02 — Challenge

  • Complex state across multiple steps.
  • Inconsistent or changing API responses mid-flow.
  • Preserving a stable user experience during backend failures.

03 — My role

Designed and implemented the full flow and its failure behaviour.

04 — Architecture

GetX-managed flow state over a clean-architecture domain layer, with defensive handling of upstream responses at every boundary.

05 — Engineering

  • Model the booking as one transaction rather than four disconnected screens.

06 — Product flow

  • Multi-step flow state
  • Resilient error handling
  • Confirmation and recovery paths

07 — Production

Live in the production app across both stores.

08 — Lessons

Failure handling is a feature; users forgive a clear message, not a dead screen.

Outcome

Users keep a coherent experience even when backend systems misbehave.

FlutterDartGetXREST APIs
08Farenexus

Release & Deployment Ownership

Release Engineering · iOS & Android

The path from a merged commit to an app on a traveller's phone, owned end to end.

01 — Context

Release friction slows shipping and makes hotfixes risky in a transactional product.

02 — Challenge

  • Provisioning profiles and certificate management on iOS.
  • Staged distribution and production rollout across two stores.

03 — My role

Managed the complete deployment lifecycle for the mobile platform.

04 — Architecture

TestFlight for internal and beta distribution, with production rollouts managed through App Store Connect and Google Play Console.

05 — Engineering

  • Keep release ownership on the engineering side for fast, safe hotfixes.

06 — Product flow

  • Provisioning management
  • TestFlight distribution
  • Production rollouts

07 — Production

TestFlight distribution and production rollouts on both stores.

08 — Lessons

Keeping release ownership on the engineering side makes hotfixes safe instead of scary.

Outcome

Predictable, repeatable releases on both stores.

App Store ConnectTestFlightGoogle Play Console
09Govt. College Kullu

Student Examination Seat Plan App

Android · First Product

An Android app that let students check their exam seating plan online instead of hunting for a roll number on a crowded noticeboard.

Exam seating lookup

Conceptual representation

Roll number

15-BCA-0421

Room

Block B · 204

Seat

Row 4 · Seat 12

01 — Context

During exams students crowded around noticeboards, waited for the crush to clear, and arrived late to the examination hall.

02 — Challenge

  • Making seating data findable in seconds on a phone.
  • Shipping a real app as a student.

03 — My role

Conceived, built and published the app, funded by the college.

04 — Architecture

A focused native Android app over college seating data.

05 — Engineering

  • Solve one observed problem completely rather than build a general portal.

06 — Product flow

  • Roll-number seat lookup
  • Exam-hall information

07 — Production

Published on the Google Play Store, supported through college funding.

08 — Lessons

Watching the problem happen in person beats any requirements document I've read since.

Outcome

Published on the Google Play Store and used by students during exam periods.

AndroidJavaGoogle Play Store

Want a deeper walkthrough of any of these systems?

Let's talk