Megan Erway
Case study 02

Weekender

A community-sourced cost database for college trips: real itemized spend, contributed by the students who paid it.

Role
Product, design, build
Timeline
2026
Live
Weekender recent trips grid

Background

Weekend getaways are a constant in college. Between away games, formals, spring break, and 21st birthday celebrations. For students, the decision often comes down to one question: “How much will this actually cost?”

Booking platforms show individual prices, but they don’t answer the question that matters most: what will this trip actually cost for my group? For example, six friends booking two hotel rooms, splitting gas, and planning a few activities could easily spend more than the listed hotel price suggests

The input a student needs is not a nightly rate. It is the realized cost of the last comparable trip.

Understanding the problem

I asked my friends what they wished they had known when planning our trips in the past. Three things came up every time:

  • Students compare trips by cost per person, not by nightly rate or total.
  • Nobody knew how much booking lead time was costing them until after the fact.
  • The most useful advice was never the price. It was whether the trip was worth it, and what the group would change.

Product vision and solution

A contribution model where students share their actual trip costs, including lodging, group size, booking timing, and per-person spending by category. Instead of helping users find available options, the product helps them compare real trip costs. Keeping the city and hotel consistent while changing the booking window shows how much booking earlier or later can affect the final price.

Because the data comes from users, the product is only as good as the submission rate, shaping my next decisions 

Weekender trip detail: itemized per-person receipt and a was-it-worth-it verdict

Defining the MVP

  • Cost per person: The most prominent number on every card, since it is the figure students need to make a decision
  • Two required fields: City and cost per person. Everything else is optional to keep submission simple and avoid losing users to a long form.
  • Tagged by occasion: Away game, Formal, 21st birthday, rather than by destination. That is how the search actually starts.
  • A verdict, not just a total: Every trip ends with "was-it-worth-it", summarized in the poster's words
Weekender booking-window chart and city price list Weekender trip submission form

What I would do next

The main challenge is building enough data. A cost database only becomes useful with enough contributions, so the next step is making sharing part of the normal post-trip experience. That could mean prompting students to submit their trip right after they return and giving them an incentive to complete the optional fields