FareTrace

FareTrace: Intelligence & Tracking of Flight Fares

What I Constructed
We built FareTrace for a friend who frequently travels between Oman and India. They regularly compare fares across airlines and dates, but the difficult part wasn't finding a cheap ticket — it was knowing whether the price they were seeing was actually a good time to book

A flight might look cheap at first, but without knowing its previous prices, baggage allowance, number of stops, or duration, it can be difficult to judge the fare properly.
We wanted FareTrace to address that problem.

Instead of only showing the cheapest flight available at the moment, FareTrace tracks fares and gives users more information to help them understand the price.
The platform brings together:

• Airline and route information
• Current fare
• Fare history and price changes
• Baggage information
• Flight duration and number of stops
• Historical price comparisons
• Fare monitoring and notifications
• Fare insights and deal detection The main idea is simple: don't just look at the price. Look at how that price compares with the rest of the information.

Code
https://github.com/VathsalyaB/Dev-week-1-challenge.git
The repository contains the different parts of FareTrace, including the frontend, backend services, authentication, database integration, fare processing, monitoring, and notification system.

How I Built It
While building FareTrace, we wanted it to work like an actual application instead of just being a static prototype.

The main technologies we used were:

• HTML, CSS, and JavaScript for the application interface
• TypeScript and Node.js for the backend
• Supabase for authentication and database services
• PostgreSQL for storing user and fare-related data
• Open-source AI tools to help with development, debugging, implementation, and experimentation
• Automated workflows for fare monitoring, analysis, deal detection, and notifications

One of the things we focused on was making sure that the application was connected to real application state.

For example, when a user logs in, the application uses an actual Supabase session. Routes and fare information are stored in the database instead of being hardcoded into the frontend. This also allows the monitoring and notification features to work with the user's actual data.

The fare-processing part of the application works in multiple steps. Fare information is first processed and normalized. It can then be compared with previous fare information and the conditions associated with the route. If the fare matches the conditions we use for identifying a deal, it can move to the notification stage.

The basic flow looks like this:
User → Fare Data → Processing → Fare Analysis → Deal Detection → Telegram Notification

We also had to bring the different parts of the application together. The frontend, backend, database, fare processing, monitoring, and notification system all needed to work together instead of functioning as separate demonstrations.

We also use the open-weight Gemma model as part of the fare evaluation process. After deterministic checks such as historical price comparison and constraint filtering, Gemma helps evaluate the overall quality of a potential deal and determine whether it should be treated as a meaningful fare opportunity.

Why Open Innovation Matters
Open innovation was one of the things we wanted to explore while building FareTrace.
We did not want AI to be the product itself. Instead, we used open-source AI tools as part of the development process where they were useful.

They helped us explore ideas, work through implementation problems, debug issues, and try different approaches while building the application.

At the same time, we still had to build and connect the actual application ourselves. The frontend had to communicate with the backend, the backend had to work with the database, fare information had to go through the processing pipeline, and the monitoring system had to eventually trigger notifications.

This gave us a better understanding of where AI-assisted development is useful and where the actual application logic still needs to be handled by the developers.

Another advantage of using open-source tools was that we could experiment with different approaches instead of depending completely on one proprietary system.

For a small team, that flexibility was useful. We could try something, see whether it worked for our use case, and change our approach when it didn't.

For FareTrace, the overall workflow we were trying to build was:
User → Fare Data → Analysis → Decision → Telegram Notification
The AI and open-source tools were part of the development process, but the final goal was to build a working system around that workflow.

Team
FareTrace was built collaboratively by:

• [vathsalyab]
• [gabyee]

What We Wanted to Solve
When booking a flight, there are usually several things to check.
For someone who regularly travels between Oman and India, you might compare airlines, look at different dates, check baggage allowances, compare direct and connecting flights, and look at the current price. But even after doing all of that, there is still one question that is difficult to answer:
Is this actually a good price right now, or should I wait?

That is the problem we wanted to work on with FareTrace.
The application does not look at the current fare alone. It also considers things such as previous prices, flight details, route conditions, and how the fare has changed over time.
The idea is to give the traveler enough information to make the decision instead of simply telling them which flight is cheapest.

Find the fare. Check its history. Track the changes. Decide when to book.