How We Built CampAlpha, an Adventure Sports Marketplace

The problem

Pakistan's adventure community was scattered across Facebook groups and WhatsApp. Gear sellers had no storefront. Trip organisers posted in groups that vanished into the feed within hours. Nobody had a home.

The brief was to give that community one place that felt as good as the outdoors it served, and that worked on the phones people actually carry, on the connections they actually have.

The decisions that mattered

Three calls shaped the whole build:

• Photo-first design. Adventure sells on imagery. We built the layout around large photography from the start rather than fitting images into a text layout later.
• Firebase over a custom backend. The client needed to launch fast and iterate. Firebase gave real-time data and auth without us building or maintaining servers. For a marketplace at this stage, that was the right trade.
• Mobile-first, genuinely. Not "responsive as an afterthought." The primary user is on a mid-range Android on a patchy connection, so that was the target we designed and tested against.

What we got wrong

The first version of the browse experience was too clever. We built rich filtering: by activity, region, difficulty, season. Users ignored almost all of it and just scrolled.

We cut the filter panel down to two options and the engagement went up. That is a lesson we keep relearning: build the thing people asked for, not the thing that is interesting to build.

Every feature you add is a feature you maintain. The filters we removed were not a waste because we removed them. They were a waste because we built them before watching anyone use the site.

The stack

Deliberately boring where it could be, so the interesting parts had room:

• React for the interface, because the component model suited a catalogue of repeating cards
• Firebase for data, auth, and hosting, so no servers to maintain
• Aggressive image optimisation, because photo-first design on a slow connection is a contradiction unless you handle it

What we would do differently

Two things:

• Ship the browse page alone and watch people use it before building anything else. We would have found the filter problem in week one instead of week six.
• Plan for the community earlier. The stories section turned out to be what people came back for, and it was scoped as a nice-to-have. The thing you think is secondary is sometimes the product.