SANGGA

The most defining decision is about what does not get built. Sangga is not a navigation app, and that is deliberate. Navigation on a mountain demands tested offline maps, and a navigation app that points the wrong way kills people. That responsibility is a different class from managing permits, and mixing the two produces a product that fails at both.

Mobile signal cannot be relied on along a trail. Any feature that requires the user to be online while on the mountain will fail exactly when it is needed most.

Permit aggregation means depending on third parties: every area authority has its own procedure and its own channel, and not one of them offers a programmatic interface.

Micro-insurance carries its own regulatory constraints, and those are not fully mapped yet.

I modelled a trip as a formal state machine with explicit transitions: DRAFT, BOOKED, READY, ACTIVE, OVERDUE, ALERTED, COMPLETED.

That shape was chosen because the most important question in this system is a question of state: when is a trip considered late, and when does lateness become an alert. With explicit transitions, the move from OVERDUE to ALERTED has a condition that can be read, tested and audited after the fact — instead of being scattered across small conditionals in many places.

Check-in and check-out sit at the trailhead, where signal still exists, not along the hike. The system never asks for a connection at a point that has none.

Clean architecture keeps the trip state rules independent of any permit channel. Each area authority can enter as a separate adapter, including the ones whose process is still manual.

The trade-off I rejected: delaying launch until every area is integrated. One mountain with a correct flow is worth more than twenty with half-finished data.