8 TRANSLADO - APP
8 TRANSLADO - APP
Two apps for one private transfer service: one to request a trip, one to carry the work. I designed both and shipped both.
Client
8 TRANSLADO LTDA.
Year
2025
Category
CODE DEVELOPMENT - UX/UI DESIGN
THE PROBLEM
THE PROBLEM
Before the apps, a trip lived in three places at once: a spreadsheet, an email thread and WhatsApp.
A request arrived as a message, and the details got settled in conversation — route, date, time, price. Someone then carried those details into the spreadsheet and found a driver over WhatsApp. Nothing was structured, so nothing could be checked, and the same trip existed in three versions that all had to agree with each other.
Before the apps, a trip lived in three places at once: a spreadsheet, an email thread and WhatsApp.
A request arrived as a message, and the details got settled in conversation — route, date, time, price. Someone then carried those details into the spreadsheet and found a driver over WhatsApp. Nothing was structured, so nothing could be checked, and the same trip existed in three versions that all had to agree with each other.
THE PROBLEM
Before the apps, a trip lived in three places at once: a spreadsheet, an email thread and WhatsApp.
A request arrived as a message, and the details got settled in conversation — route, date, time, price. Someone then carried those details into the spreadsheet and found a driver over WhatsApp. Nothing was structured, so nothing could be checked, and the same trip existed in three versions that all had to agree with each other.
THE CONSTRAINTS
THE CONSTRAINTS
Two products, one designer, one developer — the same person. I designed both apps and built the mobile front end. That removed handoff friction, and removed the second opinion with it.
Four days' notice, minimum. A trip can't be requested for tomorrow. The company needs that window to allocate a driver and a vehicle, and it takes the product out of the dispatch category entirely: nobody accepts a job while driving, and nothing has to happen in seconds.
The category's patterns only half applied. I studied ride-hailing apps to see which conventions were worth reusing, and plenty were. But those products are built for immediacy, and this one isn't — so the parts built around urgency had to be left behind.
The risk lives in the gap. Between booking and pickup there are four days or more, and that is where flights get delayed, passengers change and plans fall through. Reliability over days, not speed in the moment.
React Native and Expo. Native calendar permissions, Google Places, iOS and Android differences — every interaction I proposed had to exist inside what Expo would actually let me build.
Two products, one designer, one developer — the same person. I designed both apps and built the mobile front end. That removed handoff friction, and removed the second opinion with it.
Four days' notice, minimum. A trip can't be requested for tomorrow. The company needs that window to allocate a driver and a vehicle, and it takes the product out of the dispatch category entirely: nobody accepts a job while driving, and nothing has to happen in seconds.
The category's patterns only half applied. I studied ride-hailing apps to see which conventions were worth reusing, and plenty were. But those products are built for immediacy, and this one isn't — so the parts built around urgency had to be left behind.
The risk lives in the gap. Between booking and pickup there are four days or more, and that is where flights get delayed, passengers change and plans fall through. Reliability over days, not speed in the moment.
React Native and Expo. Native calendar permissions, Google Places, iOS and Android differences — every interaction I proposed had to exist inside what Expo would actually let me build.
THE CONSTRAINTS
Two products, one designer, one developer — the same person. I designed both apps and built the mobile front end. That removed handoff friction, and removed the second opinion with it.
Four days' notice, minimum. A trip can't be requested for tomorrow. The company needs that window to allocate a driver and a vehicle, and it takes the product out of the dispatch category entirely: nobody accepts a job while driving, and nothing has to happen in seconds.
The category's patterns only half applied. I studied ride-hailing apps to see which conventions were worth reusing, and plenty were. But those products are built for immediacy, and this one isn't — so the parts built around urgency had to be left behind.
The risk lives in the gap. Between booking and pickup there are four days or more, and that is where flights get delayed, passengers change and plans fall through. Reliability over days, not speed in the moment.
React Native and Expo. Native calendar permissions, Google Places, iOS and Android differences — every interaction I proposed had to exist inside what Expo would actually let me build.
TWO APPS, TWO CONTEXTS
TWO APPS, TWO CONTEXTS
The passenger app takes the request. Bookings come from companies arranging travel for someone and from individuals arranging their own; the private case is almost always an airport transfer, which is why the form asks for a flight number. A trip is requested at least four days out, and the passenger receives a confirmation instead of a reply.
The driver app carries the work. A trip is offered to one driver at a time — he can take it or decline, and a declined trip passes to the next driver. He sees his accepted trips, the passenger's profile and contact details, and the pickup address, which opens straight into Google Maps or Waze.
Offering trips one at a time only works because nothing is urgent. An on-demand service has to broadcast a job to every driver nearby and let the fastest tap win. With four days' notice a queue is enough — and drivers aren't competing against each other for work.
Navigation stayed outside the product. Every driver already has a maps app configured the way he likes it, and building a worse one inside mine would have been a way of asking him to trust me over a tool he uses daily.
The passenger app takes the request. Bookings come from companies arranging travel for someone and from individuals arranging their own; the private case is almost always an airport transfer, which is why the form asks for a flight number. A trip is requested at least four days out, and the passenger receives a confirmation instead of a reply.
The driver app carries the work. A trip is offered to one driver at a time — he can take it or decline, and a declined trip passes to the next driver. He sees his accepted trips, the passenger's profile and contact details, and the pickup address, which opens straight into Google Maps or Waze.
Offering trips one at a time only works because nothing is urgent. An on-demand service has to broadcast a job to every driver nearby and let the fastest tap win. With four days' notice a queue is enough — and drivers aren't competing against each other for work.
Navigation stayed outside the product. Every driver already has a maps app configured the way he likes it, and building a worse one inside mine would have been a way of asking him to trust me over a tool he uses daily.
TWO APPS, TWO CONTEXTS
The passenger app takes the request. Bookings come from companies arranging travel for someone and from individuals arranging their own; the private case is almost always an airport transfer, which is why the form asks for a flight number. A trip is requested at least four days out, and the passenger receives a confirmation instead of a reply.
The driver app carries the work. A trip is offered to one driver at a time — he can take it or decline, and a declined trip passes to the next driver. He sees his accepted trips, the passenger's profile and contact details, and the pickup address, which opens straight into Google Maps or Waze.
Offering trips one at a time only works because nothing is urgent. An on-demand service has to broadcast a job to every driver nearby and let the fastest tap win. With four days' notice a queue is enough — and drivers aren't competing against each other for work.
Navigation stayed outside the product. Every driver already has a maps app configured the way he likes it, and building a worse one inside mine would have been a way of asking him to trust me over a tool he uses daily.
LANGUAGE
LANGUAGE
The app ships in Portuguese and English. It reads the device language and serves Portuguese to Portuguese speakers; everyone else gets English, whatever their phone says.
Two languages for an international audience is a deliberate limit. A passenger landing from Tokyo or Frankfurt gets English rather than their own language — but English is the language this audience is most likely to share, and every language added is a language to maintain. The product's first contact with a user happens when that user is furthest from home and least able to guess what a Portuguese label means. Getting them out of Portuguese mattered more than getting them into their own.
The app ships in Portuguese and English. It reads the device language and serves Portuguese to Portuguese speakers; everyone else gets English, whatever their phone says.
Two languages for an international audience is a deliberate limit. A passenger landing from Tokyo or Frankfurt gets English rather than their own language — but English is the language this audience is most likely to share, and every language added is a language to maintain. The product's first contact with a user happens when that user is furthest from home and least able to guess what a Portuguese label means. Getting them out of Portuguese mattered more than getting them into their own.
LANGUAGE
The app ships in Portuguese and English. It reads the device language and serves Portuguese to Portuguese speakers; everyone else gets English, whatever their phone says.
Two languages for an international audience is a deliberate limit. A passenger landing from Tokyo or Frankfurt gets English rather than their own language — but English is the language this audience is most likely to share, and every language added is a language to maintain. The product's first contact with a user happens when that user is furthest from home and least able to guess what a Portuguese label means. Getting them out of Portuguese mattered more than getting them into their own.
RELIABILITY ACROSS THE GAP
RELIABILITY ACROSS THE GAP
A trip is agreed at least four days before it happens, and almost everything that can go wrong happens in between. Flights move. Passengers change. Plans fall through.
The booking form captures the flight number, so the driver can track the flight himself and see a delay before the passenger thinks to mention it. Driver and passenger each receive the other's contact details, so a change of plan is a phone call rather than a support ticket.
A trip is agreed at least four days before it happens, and almost everything that can go wrong happens in between. Flights move. Passengers change. Plans fall through.
The booking form captures the flight number, so the driver can track the flight himself and see a delay before the passenger thinks to mention it. Driver and passenger each receive the other's contact details, so a change of plan is a phone call rather than a support ticket.
RELIABILITY ACROSS THE GAP
A trip is agreed at least four days before it happens, and almost everything that can go wrong happens in between. Flights move. Passengers change. Plans fall through.
The booking form captures the flight number, so the driver can track the flight himself and see a delay before the passenger thinks to mention it. Driver and passenger each receive the other's contact details, so a change of plan is a phone call rather than a support ticket.
THE DECISION THAT MATTERED
THE DECISION THAT MATTERED
The problem. A pre-booked airport transfer depends on one piece of information the product doesn't control: when the plane actually lands.
Option 1 — the system owns it. Integrate a flight data provider, watch every booked flight, shift the pickup automatically, notify both sides.
Option 2 — the people own it. Capture the flight number at booking, show it to the driver, and give driver and passenger each other's contact details.
I took the second. For an operation this size, with four days of notice and a service that competes on reliability rather than volume, a driver who can check a flight and make a phone call is faster and more dependable than logic I would have had to specify, build and maintain on my own.
What it cost. The company lost sight of it. When a pickup shifts, nothing records that it shifted, why, or who decided. The coordination happens by phone, outside the product — so the operator can't see how often flights disrupt trips, can't tell whether drivers are checking, and has no record to fall back on when a passenger complains. I traded a system that knows things for people who handle things.
The problem. A pre-booked airport transfer depends on one piece of information the product doesn't control: when the plane actually lands.
Option 1 — the system owns it. Integrate a flight data provider, watch every booked flight, shift the pickup automatically, notify both sides.
Option 2 — the people own it. Capture the flight number at booking, show it to the driver, and give driver and passenger each other's contact details.
I took the second. For an operation this size, with four days of notice and a service that competes on reliability rather than volume, a driver who can check a flight and make a phone call is faster and more dependable than logic I would have had to specify, build and maintain on my own.
What it cost. The company lost sight of it. When a pickup shifts, nothing records that it shifted, why, or who decided. The coordination happens by phone, outside the product — so the operator can't see how often flights disrupt trips, can't tell whether drivers are checking, and has no record to fall back on when a passenger complains. I traded a system that knows things for people who handle things.
THE DECISION THAT MATTERED
The problem. A pre-booked airport transfer depends on one piece of information the product doesn't control: when the plane actually lands.
Option 1 — the system owns it. Integrate a flight data provider, watch every booked flight, shift the pickup automatically, notify both sides.
Option 2 — the people own it. Capture the flight number at booking, show it to the driver, and give driver and passenger each other's contact details.
I took the second. For an operation this size, with four days of notice and a service that competes on reliability rather than volume, a driver who can check a flight and make a phone call is faster and more dependable than logic I would have had to specify, build and maintain on my own.
What it cost. The company lost sight of it. When a pickup shifts, nothing records that it shifted, why, or who decided. The coordination happens by phone, outside the product — so the operator can't see how often flights disrupt trips, can't tell whether drivers are checking, and has no record to fall back on when a passenger complains. I traded a system that knows things for people who handle things.
OUTCOME
OUTCOME
Both apps designed, built and published to the App Store and Google Play. Around 180 bookings placed through the product.
The spreadsheet, the email thread and the WhatsApp messages are gone. A request now arrives structured — route, date, time, flight, passengers — which means it can be checked before anyone is dispatched.
Both apps designed, built and published to the App Store and Google Play. Around 180 bookings placed through the product.
The spreadsheet, the email thread and the WhatsApp messages are gone. A request now arrives structured — route, date, time, flight, passengers — which means it can be checked before anyone is dispatched.
OUTCOME
Both apps designed, built and published to the App Store and Google Play. Around 180 bookings placed through the product.
The spreadsheet, the email thread and the WhatsApp messages are gone. A request now arrives structured — route, date, time, flight, passengers — which means it can be checked before anyone is dispatched.
DEFERRED BY DESIGN
DEFERRED BY DESIGN
Two things I wanted and didn't build: a flight-tracking integration, so the system would know about a delay instead of relying on a driver to look it up, and in-app chat, so coordination would stay inside the product and leave a record behind.
Both were cut on purpose. I scoped them out of the MVP and the client agreed. They are exactly the two things that would close the gap described above, and they're the right first additions to a second version — but shipping without them was a decision, not an oversight.
Two things I wanted and didn't build: a flight-tracking integration, so the system would know about a delay instead of relying on a driver to look it up, and in-app chat, so coordination would stay inside the product and leave a record behind.
Both were cut on purpose. I scoped them out of the MVP and the client agreed. They are exactly the two things that would close the gap described above, and they're the right first additions to a second version — but shipping without them was a decision, not an oversight.
DEFERRED BY DESIGN
Two things I wanted and didn't build: a flight-tracking integration, so the system would know about a delay instead of relying on a driver to look it up, and in-app chat, so coordination would stay inside the product and leave a record behind.
Both were cut on purpose. I scoped them out of the MVP and the client agreed. They are exactly the two things that would close the gap described above, and they're the right first additions to a second version — but shipping without them was a decision, not an oversight.
More Works More Works
More Works More Works
