Commute Lens | Devpost

Commute Lens - Landing Page Mobile View

Inspiration

For many Filipino workers, a job offer starts with one number: salary.

But salary alone does not show the full cost of taking a job.

Transportation expenses, traffic, transfers, and hours spent commuting can significantly change the real value of an opportunity. A higher-paying job may still leave someone with less disposable income, less rest, and less time with family.

That led us to a simple question:

What if job seekers could compare opportunities based not only on what they earn, but also on what it costs them—in money and time—to get to work?

We built CommuteLens for the CUTC Transform Hackathon 2026 to make those hidden costs visible and help workers evaluate opportunities with better context.

Our goal is not to tell someone which job to choose. It is to help them see the trade-offs clearly enough to make that decision for themselves.

What it does

CommuteLens is a job-offer and commute comparison tool that evaluates the financial and time-related impact of getting to work.

Instead of comparing offers using salary alone, CommuteLens considers:

Estimated take-home value after transportation costs
Monthly commute expenses
Monthly commute hours
Commute burden as a percentage of income
Effective hourly value after work and travel time
Remote, hybrid, and fully onsite arrangements
Two independent job offers with different locations and work setups

Users can also explore scenarios from 0 to 5 onsite days per week and immediately see how a change in work arrangement affects transportation expenses, commute time, and effective hourly value.

For example, a job with a higher salary may initially look better. But if it requires five days of expensive, multi-hour commuting every week, another offer with a slightly lower salary and fewer onsite days may provide more usable income and personal time.

CommuteLens makes that trade-off visible.

The core idea

We calculate an effective hourly value that accounts for both transportation expenses and unpaid commute time

Commute time does not literally reduce a worker's paycheck, so we do not present it as a monetary deduction. Instead, it increases the total amount of time required by the job, giving users another way to understand the opportunity's real time-to-income trade-off.

CommuteLens remains a decision-support tool, not a decision-maker. Different people value salary, flexibility, career growth, family time, and commute convenience differently.

How we built it

CommuteLens is a full-stack Next.js application built with a layered architecture that separates routing, financial calculations, data provenance, validation, and presentation.

Our stack includes:

Next.js, React, and TypeScript — full-stack web application
Geoapify — address search, reverse geocoding, and map tiles
BusMaps — live route timing when available and configured
GTFS and Mobility Database data — archival public-transit fallback
MapLibre GL — interactive route visualization
Zod — runtime validation for requests and external data
OpenAI — guarded, fact-based explanations of calculated results
Vitest — automated testing of calculations and application behavior

Data provenance

One of our most important architectural decisions was to avoid treating every data source as equally reliable.

CommuteLens classifies information using explicit provenance labels:

Live — obtained from a currently available external provider
Estimated — calculated using documented assumptions
Archival — derived from historical or non-current datasets
Curated Demo — controlled data used to demonstrate application behavior

This prevents estimated fares or archival transit information from being presented as if they were official, current values.

Grounded AI explanations

AI is used as an explanation layer, not as the calculation engine.

The application calculates and validates the underlying metrics first. The AI receives structured, validated facts and is instructed to explain those results without inventing additional information.

If AI is unavailable or its output fails our safety and accuracy checks, CommuteLens falls back to deterministic explanations generated directly from the calculated data.

The calculations therefore remain usable independently of the AI layer.

Challenges we ran into

Incomplete transit coverage

Public transportation data in the Philippines is fragmented, and coverage varies significantly by location. Some available GTFS datasets are also archival rather than current.

Instead of hiding this limitation, we designed CommuteLens around multiple data paths and explicit provenance labels.

When live information is unavailable, the application can use archival or estimated information while clearly communicating its limitations.

Estimating fares responsibly

Routing providers can return useful route and travel-time information without providing current fare data.

We needed fare estimates for planning while avoiding the impression that those estimates were official transportation fares.

Our solution was to separate the calculation from its confidence level and clearly label estimates as planning assumptions.

Measuring the cost of time

Commute time is different from a direct financial expense.

A two-hour commute does not deduct two hours' worth of money from someone's salary, but those two hours are still unavailable for rest, family, learning, or other activities.

We therefore include commute time in the denominator of our effective hourly value rather than pretending it is a direct monetary deduction.

Keeping AI grounded

Generative AI can make calculated results easier to understand, but it can also introduce unsupported conclusions.

We addressed this by making AI downstream of deterministic calculations. It receives validated facts instead of independently deciding what the numbers mean, and deterministic explanations remain available as a fallback.

Presenting complex information simply

CommuteLens combines salary calculations, route information, transportation estimates, uncertainty, provenance, and scenario planning.

Showing everything simultaneously would overwhelm users.

We designed the interface to progressively reveal detail while keeping the most decision-relevant metrics visible first.

Accomplishments that we're proud of

We're proud that CommuteLens became more than a commute calculator.

During the hackathon, we:

Built a working end-to-end job and commute comparison experience
Made transportation costs and unpaid commute time visible during job evaluation
Created a 0–5 onsite-day scenario explorer
Added independent comparison of two job offers
Supported live, archival, estimated, and curated-demo data paths
Added explicit data provenance and uncertainty labels
Reused route previews so analyses do not unnecessarily reroute or consume external API quota twice
Added guarded AI explanations with deterministic fallbacks
Avoided presenting estimated fares and archival transit information as official current data
Built the experience around a practical problem faced by Filipino workers

Most importantly, we built the product around a principle we want to preserve:

CommuteLens should explain the trade-off, not make the decision for the user.

What we learned

The biggest lesson from CommuteLens was that a trustworthy decision-support tool needs more than a correct-looking number.

Users should also understand:

Where did this number come from?

What assumptions were made?

How current is the underlying information?

What should I—and shouldn't I—conclude from it?

Building CommuteLens taught us to:

Separate live, archival, estimated, and demo data
Make uncertainty visible instead of hiding it
Treat time as an important component of economic value
Keep AI grounded in validated, deterministic facts
Design graceful fallbacks for unavailable external services
Make calculations understandable to non-technical users
Optimize external API usage instead of unnecessarily repeating route requests
Build tools that support human decisions rather than replacing them

The project changed how we think about "accuracy." A useful system does not simply output a number—it communicates how trustworthy that number is.

What's next for CommuteLens

CommuteLens currently demonstrates the idea, but there is significantly more we want to build.

Our next priorities include:

Integrating validated agency-specific GTFS and fare datasets
Improving transit coverage outside Metro Manila
Supporting additional transportation modes and routing providers
Improving fare and travel-time accuracy
Adding saved comparisons with strong privacy protections
Supporting fuel, parking, tolls, motorcycles, and private vehicles
Allowing users to adjust assumptions such as work hours and transportation costs
Expanding localized support to more Philippine cities
Improving uncertainty visualization and explanation
Continuing to validate our calculations against real commuting scenarios

Long term, we want CommuteLens to become a trusted planning tool for evaluating work opportunities based on the full cost of working—not just the number printed on a job offer.

Salary tells you what a job pays. CommuteLens helps you understand what that job really costs.