Raúl Rincón

[raˈuhl]

(Sr) Product Designer

Case Study / Product Design / PARAPAPAN

ParapanApp

An internal delivery tool I built for Parapapan to simplify delivery operations and route planning.

Project Snapshot

ParapanApp is an internal delivery tool I built for Parapapan, my family’s bakery business. The goal was simple: stop spending hours manually organizing deliveries and give drivers a faster, easier way to know where to go next.

The app takes delivery data, automatically sorts deliveries by proximity, and provides drivers with everything they need to complete their route from a single screen.

Client / Employer

Parapapan

My Role

Product Designer, Developer, Product Owner

I designed, built, shipped, and continue to maintain the application. Because I was also the person managing deliveries, I was able to identify problems firsthand and quickly iterate on solutions based on real-world usage.

RESPONSIBILITIES
  1. Product definition and prioritization
  2. UX and UI design
  3. Development, deployment, maintenance, and feature improvements
Hypothesis

If delivery drivers only saw the information they needed and deliveries were automatically organized by proximity, the entire delivery process would become faster, easier, and more reliable.

Proposed Solution

Build a lightweight mobile-first delivery tool that automatically sorts deliveries based on location, provides drivers with customer information when needed, and removes the manual effort of organizing routes.

Wins

The app is actively used during every delivery cycle and has become the primary tool drivers use to complete their routes.

HIGHLIGHTS
  1. Reduced delivery preparation from hours of manual organization to roughly 10 minutes.
  2. Currently used by five delivery drivers.
  3. Eliminated manual route sorting by automatically organizing deliveries based on proximity.
Steps / Jobs Done
  1. When I start my delivery route,
  2. I want to immediately know which delivery I should make next,
  3. So that I can complete my route efficiently without having to manually organize addresses or plan the route myself.

Context

Before ParapanApp existed, deliveries were managed through a spreadsheet. Orders would come in, I would manually organize them, sort addresses, assign deliveries, and prepare everything the drivers needed before they could leave.

The process worked, but it wasn’t scalable. Every delivery day required a significant amount of manual work just to answer a simple question:

Which delivery should happen next?

The more orders we received, the more time it took to organize everything. The actual delivery process wasn’t the problem. Preparing for the delivery process was.

Understanding the Workflow

At the time, I was responsible for organizing deliveries myself.

That gave me a unique advantage when designing the solution because I wasn’t working from assumptions or second-hand feedback. I was living the problem every week.

The workflow looked something like this:

  1. Orders come in.
  2. Organize everything manually.
  3. Sort deliveries by address.
  4. Prepare customer information.
  5. Hand information to drivers.
  6. Hope nothing changes during the route.

The process was repetitive and time-consuming. I realized most of the work wasn’t actually making decisions. It was organizing information. For more context, we had production days where we had 25+ deliveries and each delivery of them had to go through this process.

Building The First Version

The first version of the app focused on one thing:

Helping drivers understand which delivery should happen next.

Drivers would open the app and immediately see a list of deliveries assigned to them. Those deliveries were automatically organized by proximity, removing the need to manually sort addresses before every route.

The experience was intentionally simple. I didn’t want drivers navigating complicated interfaces while they were on the road. The goal was to reduce decisions, not create new ones.

First version of the app, just the basic things and not many improvements.

Even in the earliest version, the app immediately reduced the amount of preparation required before deliveries.

Improving The System

As the app started being used during real delivery days, new opportunities became obvious. One of the earliest improvements involved how addresses were handled.

Originally, addresses were stored and processed in a more basic format. Over time, I added support for Google Maps location-based addresses, which improved accuracy and simplified the experience for both customers and drivers.

This change also improved the quality of the route ordering logic because location data became much more reliable.

Some improvements and layout breaks here. I was building and getting used to Flutter, but I found my rythm and started to develop faster.

Another important improvement was adding customer contact information directly into the delivery details. Drivers wanted immediate access to phone numbers and addresses so they could quickly contact customers if something changed during delivery.

Instead of forcing drivers to look elsewhere, the information became part of the delivery experience itself.

The Delivery Details screen became one of the central focus of the app, since it is one of the most “high traffic” screens, where the delivery driver gets the most context on a single delivery.

The Most Valuable Feature

The most valuable feature in the app is also the simplest: Automatic delivery sorting.

Whenever a driver opens the application, the app compares their location against every delivery address and automatically organizes deliveries so the closest one appears first.

  • The route constantly adapts based on location.
  • Drivers don’t have to think about optimization.
  • They don’t have to manually sort addresses.
  • They don’t have to plan the route themselves.
  • The next delivery is simply waiting for them at the top of the list.

It’s one of those features that becomes immediately useful the moment you use the product.

Features That Didn’t Survive

Not every idea worked. At one point, I built a dedicated “Delivery Mode” that simplified the interface and restricted most interactions while a driver was actively making deliveries.

On paper, it sounded useful. In practice, drivers preferred the normal delivery screen.

The additional mode created complexity without providing enough value, so it was eventually removed. That decision reinforced an important lesson:

Adding features is easy. Removing features is harder. Sometimes the best improvement is deciding not to ship something.

Building For Reality

One thing I’ve learned while working on this project is that real-world usage will always reveal edge cases. Early on, I encountered a scenario where the app could fail if delivery information was incomplete.

Rather than treating it as a one-off issue, I added safeguards throughout the system to ensure missing data wouldn’t break the delivery workflow.

Since then, the app has continued to support delivery operations without major failures.

The goal isn’t perfection. The goal is reliability of the app and have it be the single source of truth for every delivery in the business. If it fails, then multiple things have failed before.

When drivers open the app on delivery day, it needs to work. This is non-negotiable.

Outcome

Today, ParapanApp is the primary tool used for delivery operations. Orders are added to a CSV file, the app imports the information, builds the delivery list, and automatically organizes routes for drivers.

What previously required hours of manual preparation now takes roughly ten minutes. The app currently supports five active delivery drivers and continues to evolve as new needs emerge.

Current state of the app, as of June 2026

What I Learned

This project reinforced something I strongly believe about product design. The best products don’t always come from brainstorming sessions.

Sometimes they come from living with a problem long enough that the solution becomes obvious. Because I was both the person organizing deliveries and the person building the product, I had direct access to the problem every week. I didn’t need assumptions, personas, or research sessions to understand what was frustrating.

I could see it. The biggest lesson from this project is that simplicity scales surprisingly well. The app doesn’t do a lot. It just does the right things. And that’s exactly why it works.

What the future looks like…

I’m probably going to keep working on this app for the foreseeable future. It has taught a lot of things that remain the core and center of my approach to design: understand what you’re trying to build, before you build it. The way the design is really the answer and not just a pretty solution.

Over the next few weeks, I’ll start working on the companion app (probably another mode within the same app) that helps me and the team working on the packages pack orders properly and have a track record of:

  • Things we packaced
  • When we marked them as packaged
  • Which ones are meant to be deliverable
  • Which others are pickup (production centre).

Smells like exciting times ahead.

Icon Menu Icon Close