TREKLY – case study

TREKLY organises group hikes and treks. Every outing has a limited number of places, a difficulty level and guides: information a participant needs to weigh up before signing on, because a six-hour walk with serious climbing is not the same thing as a two-hour stroll.

The constraint that shaped the project

In a hiking calendar, the available place is the critical variable. It has to update the moment someone signs up, not at the end of the day: a booking accepted on an outing that is already full turns into an apologetic phone call, a refund and a participant who does not come back. The architecture started there, before anything to do with appearance.

How it works

• A calendar of outings with difficulty, distance and elevation stated for each one, so people know what they are signing up for.
• Limited-place booking: the counter falls with every signup and the outing marks itself sold out, without anyone having to remember.
• User registration and membership, with the record staying attached to later signups.
• Guide profiles, because people trust a person before they trust an organisation.
• An archive of past outings, which is both proof that the group really walks and the route by which someone searching for a destination finds the site.
• A newsletter for new dates, so regulars do not have to keep checking back.

The part you do not see

Counting places looks trivial until two people open the same outing at the same moment. Availability has to be checked at confirmation, not when the page loads, or sooner or later the last places get sold twice — and it always happens on the most popular outing, which is where the damage is worst.