Why a Verification-First Approach?

Commute Matcher is designed for people sharing private vehicles with commuters they may not already know personally.

Unlike public transport or traditional ride-hailing services, the platform depends on both drivers and passengers feeling comfortable enough to share a daily commute. This makes identity, accountability, and safety central to the product experience.

The platform is also intended for early-morning and evening commuters, when people may feel more vulnerable and have fewer alternative transport options.

In this environment, successful route matching alone is not enough. Users also need reasonable confidence that the people they meet through the platform are genuine and accountable.

Commute Matcher must therefore do more than connect people travelling in the same direction. It must build trust into the way users access and participate in the platform.

Commute Matcher will follow a verification-first approach.

Users may be allowed to register and explore limited parts of the platform, but they must meet the required verification level before carrying out sensitive actions such as:

• creating a route;
• offering seats as a driver;
• booking a seat;
• joining a confirmed commute; and
• participating in payment or review processes.

Verification is therefore treated as part of the core product flow rather than as an optional feature added after the matching system.

One alternative was to allow users to register, create routes, and book seats immediately, with verification introduced after the platform gained more users.

This could reduce onboarding friction and increase early sign-ups. However, it would expose users to unverified participants and make it more difficult to establish a strong trust culture from the beginning.

Another alternative was to make verification optional and allow users to decide whether they wanted to interact only with verified participants.

Although this would provide more flexibility, it could create an inconsistent trust experience and weaken the platform's safety-focused value proposition.

A third alternative was to verify only drivers. However, this would create an unequal trust model. Drivers are opening their private vehicles to other people and also need confidence that passengers are genuine and accountable.

Trust is not a secondary feature in Commute Matcher. It is one of the product's core requirements.

A route match based on origin, destination, and departure time is useful only when both participants feel reasonably comfortable proceeding with the commute.

A verification-first model helps the platform establish:

• that users are connected to genuine accounts;
• that participants can be linked to their platform activity;
• that drivers meet additional requirements before offering seats;
• that route and booking activity can be audited; and
• that misconduct can be investigated through identifiable records.

The approach also supports mutual trust. Drivers are not treated as the only possible source of risk, and passengers are not allowed to participate anonymously.

This is particularly important because Commute Matcher drivers are commuters first, not professional transport operators. They are allowing other people into their private vehicles and need confidence that the platform has taken reasonable steps to identify those passengers.

Passengers also need confidence that a route is connected to a genuine driver whose identity and eligibility to offer seats have been reviewed.

This decision reflects a human-centred design approach because it considers the concerns, responsibilities, and expectations of both sides of the commute.

A verification-first approach introduces additional onboarding effort.

Users may need to provide information, submit documents, or wait for approval before gaining full access to the platform.

This can result in:

• slower account activation;
• lower onboarding completion rates;
• additional operational work;
• more complex data handling;
• longer development time; and
• frustration for users who expect immediate access.

Verification may also create accessibility concerns for people who do not have corporate email addresses, strong digital profiles, or easily accessible identity documents.

There is also a privacy trade-off. The platform must collect enough information to support trust without collecting more personal data than necessary.

The chosen trade-off is additional onboarding friction in exchange for stronger accountability, trust, and safety.

Verification information must be handled carefully.

The platform should:

• collect only information necessary for verification;
• restrict access to sensitive documents;
• store verification records securely;
• avoid exposing private documents to other users;
• show verification status rather than raw identification documents;
• define how long verification information will be retained; and
• keep appropriate records of verification decisions.

Users should be able to see that another participant has met the platform's verification requirements without gaining access to that person's private documents.