the-404-found

Northstar: Navigation with Nuance.

Comment

Inspiration

We kept coming back to a broader issue. Many of the tools people rely on every day are built with an assumed “default” user in mind. Navigation apps are a clear example. They depend heavily on visual cues, maps, and screens that many take for granted, while blind and low-vision users are expected to adapt to systems that were never truly designed for them.

Our inspiration was to start leveling that playing field. Instead of treating accessibility as an add-on, we wanted to approach navigation as a core systems problem and design something that accounts for movement, uncertainty, and real-world constraints from the beginning. Northstar grew out of that mindset.

What it does

Northstar is a real-time navigation engine that tracks live coordinates, calculates distance and bearing to waypoints, and adjusts feedback as the user moves. Rather than relying on static directions, the system continuously evaluates position relative to the next waypoint and updates guidance based on proximity.

Distance between two geographic coordinates is computed using spherical geometry: d = R⋅arccos(sinϕ1sinϕ2 + cosϕ1cosϕ2cos(Δλ))

The engine runs continuously, updating bearing within the 0°–360° range while using controlled state logic to prevent duplicate triggers or unstable transitions when a waypoint is reached.

How we built it

The backend is built with FastAPI. REST handles session creation and route setup, while WebSockets maintain a persistent channel for continuous location streaming. This keeps initialization predictable while real-time updates flow through a dedicated asynchronous path optimized for low latency.

On the frontend, the browser’s geolocation API captures live coordinates and streams them to the server at controlled intervals. Spatial computation executes independently from narration so bearing and distance updates are never delayed by AI responses. Movement logic is processed deterministically, while narration runs in a parallel async loop that can be cancelled or replaced without interrupting navigation state.

To prevent race conditions, we structured concurrent tasks around guarded state transitions and controlled cancellation. Fallback logic was embedded at the session layer so that even if external APIs degrade or time out, the navigation kernel continues operating instead of failing abruptly.

Challenges we ran into

GPS noise was a consistent issue. Small coordinate shifts can cause bearing values to fluctuate rapidly, making feedback unstable. We introduced smoothing thresholds and proximity logic to prevent constant micro-adjustments from turning into confusing guidance. Finding the right balance required iteration.

Concurrency was another challenge. Live location updates and narration responses operate at different speeds, so separating those flows without creating overlapping feedback or duplicate waypoint triggers required careful state control and cancellation handling.

Server deployment also proved difficult. Running a real-time WebSocket-based system meant managing connection stability and session handling differently from a standard API. External API limits forced us to design around rate constraints and failure cases rather than assuming unlimited availability.

Accomplishments that we're proud of

We built a navigation engine that stays stable under asynchronous updates and does not collapse under real-time pressure. State control prevents erratic transitions, and fallback logic allows the system to continue operating even when external services degrade.

More importantly, we delivered a working, intentional system in 48 hours despite deployment setbacks, API limits, and repeated debugging cycles. Finishing something reliable under those constraints is something we are proud of.

What we learned

We learned that accessibility at this level is tightly connected to system reliability. Small architectural decisions have immediate real-world consequences when the system runs continuously. We also learned how sensitive real-time navigation is to noisy inputs, concurrency timing, and infrastructure constraints.

Building Northstar forced us to think more carefully about state control, failure handling, and deployment than any previous project.

What's next for the-404-found

For us, this is just the beginning. Low-vision users and people who face physical or cognitive barriers have too often been treated as edge cases in product development. Northstar is our first step toward changing that.

We want to move beyond basic navigation and build systems that are designed for everyone from the start, not adapted later. the-404-found exists to level the playing field by engineering tools that prioritize reliability, autonomy, and dignity, especially for those who have historically been overlooked in software design.

Share this project:

Updates