BidSight

Median Bid Training
Minimum Bid Training
Course and Bidding Results Search
Bid Progress and Improvement Tracking
Leaderboards
Live Rounds

Inspiration

At SMU, BOSS bidding can feel opaque and stressful. Most students rely on scattered advice, outdated screenshots, or gut feel when deciding how much to bid, even though a small difference in judgment can mean overpaying or missing a class entirely. BidSight was inspired by the idea that bidding is a skill that can be trained. Instead of guessing blindly, students should be able to practice against real historical data, learn how close they were, and build sharper intuition before real credits are on the line.

What it does

BidSight is a web app that helps students train for module bidding using historical BOSS data. In Training Mode, users are shown a real course section with its context such as section, instructor, schedule, vacancy, and historical trends, but the winning bid is hidden. They make a prediction for the minimum or median bid, submit it, and immediately see the real answer with a score based on how close they were. The app also includes progress tracking, leaderboards, profile and friends features, course search, and a Live Mode where users can participate in simulated auction rounds and compare outcomes in real time.

How we built it

We built BidSight as a full-stack application with a React frontend powered by Vite and a FastAPI backend. Supabase handles authentication and acts as our primary Postgres database, while the backend uses service-role access to keep sensitive bid-answer logic server-side. We also built a Python-based data ingestion pipeline to clean and structure historical BOSS bidding data, then exposed it through training, leaderboard, profile, search, and live-round APIs. On the frontend, we focused on a clean, responsive experience with charts, filters, authentication flows, progress views, and leaderboard interactions.

Challenges we ran into

One major challenge was designing a training flow that felt useful without leaking the answer too early. We had to carefully separate what data the frontend could see from what only the backend should compute. Another challenge was leaderboard fairness: if users could replay the same course repeatedly, they could artificially inflate their ranking, so we had to implement counted first-attempt logic. We also spent time dealing with messy historical data, term filtering, school-level categorization, and building live auction behavior without depending on full realtime infrastructure.

Another challenge was data completeness. BOSS's historical bidding records had the bid outcomes but not the actual class timings for each section — and we reasoned that timing is a major factor in how students bid (an 8am section bids very differently from a 3:30 one), so leaving it out would make the training data misleading. Since there were thousands of sections to cover, manually pulling timings wasn't feasible, so we wrote a web scraper to pull section timings directly from BOSS and link them back to their corresponding historical bid records.

One of the biggest challenges was designing a fair scoring system. It wasn't obvious how to translate "how close was this guess" into a single number — should a $3 miss on a $60 course count the same as a $3 miss on a $12 course? How much should bigger misses be punished versus small ones, and where should the curve flatten out so wild guesses don't all score zero? We iterated through several approaches before landing on a percentage-error model with a tunable decay curve (score = 1 / (1 + K × error%)), which scales misses relative to the course's price and rewards near-bullseyes far more than "just being in the ballpark."

Scope creep was a common issue we faced as we thought of new features to implement on top of our original proposal clean UIUX was an issue we faced and we took some time to settle on our UI theme (IBM + notion style).

Accomplishments that we’re proud of

We’re proud that BidSight is more than just a data viewer. We turned historical bidding records into an interactive training experience with instant feedback, scoring, and measurable progress. We’re also proud of the live leaderboard system, friends features, school-based filtering, and the Live Mode auction rounds, which make the app feel competitive and social rather than purely informational. On top of that, we shipped a responsive interface with charts, dark/light mode, and a polished user flow that makes a fairly dense dataset feel approachable.

What we learned

We learned that product focus matters a lot in a hackathon setting. The strongest version of BidSight was not “everything related to course bidding,” but a sharp core loop: predict, reveal, score, improve. We also learned the importance of backend authority for anything involving fairness, especially scoring and leaderboard eligibility. On the teamwork side, we learned how to divide work across frontend, backend, data, and product decisions while keeping the experience coherent end to end.

We learnt that 90% of effort should be spent on ideation, 10% on code. This allowed us to save a lot of time and struggle which we initially faced due to code hallucinating because we were vague. Through trial and error, we learnt how to tap one one another's newfound strengths. UI handled by one, Backend logic handled by another and this helped us to streamline our workflow.

We picked up Playwright for web scraping, and learned scraping at scale is as much about failure-handling as extraction — BOSS would rate-limit or silently log us out after too many requests in a short window, so we had to checkpoint progress and save scraped records every few hundred entries, letting the scraper resume instead of losing everything on a timeout.

We also learned a lot about schema design, particularly around write-time integrity: rather than computing which predictions "count" toward the leaderboard after the fact, we decided fairness at the moment of submission — checking whether a user had already made a counted attempt on that course and permanently flagging replays right then. This closed a gaming exploit (resubmitting the revealed answer for a free perfect score) and let the UI show replay status instantly instead of waiting on a separate leaderboard computation.

What’s next for BidSight

Next, we want to make BidSight more adaptive and more predictive. That includes features like accuracy breakdowns by course area, an AI coach that explains why a bid may have gone higher or lower, and better validation of whether training on BidSight actually improves real bidding outcomes. We also want to expand Live Mode, add richer analytics, and continue refining the dataset so BidSight can become a practical decision-support tool for students before every bidding window.