hikesafe

• 

  HikeSafe DM

Inspiration

When someone goes hiking, their family or friends may know only that they went into the mountains—not which route they planned to take, when they expected to return, or where they were last seen.

I created HikeSafe to close this communication gap. Because LINE is one of the most widely used communication platforms in Taiwan, I decided to build the first version as a LINE-based hiking safety companion. My goal is not to replace rescue services or professional equipment, but to help hikers communicate their plans clearly and give guardians reliable information when something does not go as expected.

What it does

HikeSafe lets hikers create structured trip plans, designate guardians, and send explicit check-ins throughout a trip.

Hikers can:

• Create a trip with a route, team members, expected return time, equipment, vehicle, and emergency contact details.
• Start a hike with an explicit location check-in.
• Send progress updates using GPS or text-only status reports.
• Request help and share their latest available information.
• Confirm that the entire team has safely returned.
• Extend the expected return time when plans change.

If a trip runs late, HikeSafe sends staged LINE alerts at the planned finish time, 60 minutes late, and 120 minutes late. Guardians can view the last reported time and location, route, team members, and other relevant details. At the highest alert level, the system can provide a copyable report summary for contacting the appropriate authorities.

HikeSafe does not perform background GPS tracking, interpret silence as an emergency, or automatically contact rescue services.

How I built it

I built HikeSafe with Next.js App Router, TypeScript, PostgreSQL, and Drizzle ORM. The application integrates LINE Login, LIFF, and the LINE Messaging API.

The core system is organized around trips, check-ins, guardians, alerts, and delivery records. I implemented:

• LINE-based authentication and viewer authorization.
• Structured trip and route data.
• Explicit GPS and text-only check-ins.
• Offline check-in queuing for temporary network loss.
• Idempotency keys to prevent duplicate trip actions and notifications.
• Retryable LINE message delivery.
• Staged alert processing at multiple time thresholds.
• Alert cancellation after a confirmed safe return.
• Precise-location retention and deletion rules.
• Automated tests for complete trip flows, alert races, failed deliveries, retries, and retention behavior.

I started with LINE because it is already part of many people’s daily communication habits in Taiwan. The same product concept can later be adapted to WhatsApp and other messaging platforms.

Challenges I ran into

The most difficult part was handling unreliable real-world conditions.

A hiker may lose network access, be unable to obtain GPS, or submit the same action more than once. A guardian may also receive a delayed notification. I had to make sure the interface never presented a pending offline check-in as successfully delivered, and never reused an old GPS location as if it were current.

Another major challenge was the race between safe-return actions and overdue-alert jobs. A trip may be completed at nearly the same moment an alert worker starts processing it. I addressed this with server-side state checks, idempotency, cancellation logic, database locking, and retry-aware delivery records.

LINE delivery also cannot be committed atomically with a PostgreSQL transaction. I therefore designed the delivery flow to remain safe when a message succeeds but the worker fails before recording the result, or when a delivery must be retried.

Accomplishments that I'm proud of

I am proud that HikeSafe is designed around explicit facts instead of dangerous assumptions. A missing update does not automatically mean that a hiker needs rescue, and a lack of GPS is never presented as the hiker’s current location.

I also built a complete trip lifecycle: planning, guardian binding, starting, checking in, extending, requesting help, receiving staged alerts, and confirming a safe return. The system cancels pending alerts immediately after a confirmed finish and protects precise trip information with authorization checks.

Most importantly, I turned a vague message—“they went hiking”—into structured information that guardians can actually use.

What I learned

I learned that safety products must be honest about their limitations. Technology cannot guarantee that a hiker is safe, especially in areas without network coverage. It can, however, help people share plans, record explicit updates, and make better-informed decisions.

I also learned that failure handling is not an optional technical detail. Offline behavior, duplicate requests, delayed notifications, authorization boundaries, retention policies, and race conditions are all part of the product experience.

Finally, starting with a familiar communication platform can reduce friction. By building on LINE first, HikeSafe can meet users where they already communicate instead of asking them to adopt an entirely new channel.

What's next for HikeSafe

My next steps are to deploy the LINE integration with real credentials, complete verification of the route catalog, and test the full experience with hikers and guardians in realistic conditions.

I also plan to improve route-data maintenance, notification observability, and guardian workflows. After validating the LINE version in Taiwan, I want to explore integrations with WhatsApp and other messaging platforms so the same safety model can serve hikers in different regions.

The long-term vision is a communication layer that helps hikers, families, and trusted contacts stay connected before, during, and after a trip—without pretending to be a navigation system or an automated rescue service.

Built With

• api
• drizzle
• indexeddb
• liff
• messaging
• next.js
• node.js
• orm
• postgresql
• react
• typescript
• vercel
• vitest