Road-trip planning app with brand-preference discovery and server-side mapping proxy

General mapping apps answer what is nearby, not where the hotel chain a driver has loyalty points with, or the fuel network on their card, actually sits along the road ahead. That gap gets filled by pulling over to search or by a detour discovered too late.

Matching a driver's stated brand preference against real-world place results is genuinely messy: business names come back as free text from the places provider, a brand can operate under several names, and a portfolio brand's parent name is often the one the customer actually recognises.

A road trip is also not a one-shot query — it is planned days ahead, edited by hand, reordered, started, paused overnight and resumed the next day, which means stop order has to stay consistent across two independently built native clients acting on the same itinerary.

Third-party mapping and places calls are metered, and a natural interaction model — searching as the driver explores the map — makes call volume scale with how much people enjoy the app, so an unbounded credential shipped in the client is both a security and a cost problem. On top of that, subscription entitlement has to be verified against two app stores that expose completely different mechanisms, and reconciled if the same subscription reappears under a different account.

Modelled brand preference as a curated, ranked catalogue rather than free text: users pick a small ranked set of brands per category from a list maintained in the back office, with preference groups so one selection can expand into a family of related brands, and per-platform visibility flags for the two stores.

Put every third-party mapping call behind the API instead of the device. The clients send a relative provider path and parameters to one endpoint; the server attaches the credential, forwards the request, logs it against the user and platform, and returns the response — keeping the mapping credential off the client, giving a usage ledger, and centralising the throttle in one place.

Made itinerary ordering the server's responsibility. Inserting a stop at an occupied position cascades the conflicting order numbers upward, deletion re-indexes the remainder, and both native clients submit a proposed drag-and-drop order for the server to apply as one unit.

Verified subscription purchases server-side against each store's own model — receipt verification with sandbox fallback on one, an OAuth-authenticated purchase lookup on the other — converging on a single entitlement flag, kept current by consuming store lifecycle notifications, and withdrawing entitlement from a previous account when the same subscription identifier reappears under a new one.

Built both mobile clients natively — Kotlin on Android, Swift on iOS — against a single Laravel REST API, so each could use its platform's own mapping, billing and sign-in SDKs directly rather than through a bridging layer.

Route planning answers the question drivers actually ask — where their own brands sit along the road ahead — rather than just what is nearby, with preferred and other results shown as visually distinct map pins and a single toggle to widen the search when a preferred brand is not around.

Itineraries survive real use: stops inserted, deleted and dragged into a new order stay consistent across two independently built clients, and a multi-day trip resumes correctly from wherever it was left off.

Mapping cost became a bounded, observable number instead of an invisible variable that scaled with engagement, and subscription entitlement is verified, current and exclusive to one account at a time across both app stores.

Something holding you back?

New build, rebuild, or adding AI to what you already have — I'll take a look and give you an honest perspective.