Horus

Context

This case study describes confidential professional work using public product information and supported responsibility areas. Horus is a NETe2 emergency-response video product. It starts a live video session from a caller’s phone browser without requiring an installed app.

Public product capabilities include GPS caller location, live video, live chat, browser compatibility, secure data handling, and short-lived SMS links. Together, these support real-time guidance and incident assessment for operations centres.

Problem

An operations team may need visual and location context from a caller who has no specialist app installed. The interaction must begin with little caller setup while giving the operations centre enough information to understand the incident and guide the next action.

That creates a cross-disciplinary engineering problem. Browser media, session lifecycle, location, mapping, API integration, operational interfaces, delivery, and troubleshooting all need to support one clear workflow.

Role and responsibilities

The contribution to Horus was made as a Senior Software Engineer at NETe2 Asia during the 2017–2026 tenure. This was team product work, not sole authorship.

Supported contribution areas include architecture, full-stack implementation, real-time media streaming, API integration, mapping, testing, CI/CD, delivery, troubleshooting, and planning. Confidential implementation details, customer information, and internal architecture are omitted.

Constraints

• The caller workflow must operate in a phone browser without requiring an installed app.
• Real-time guidance on the live video stream, alongside chat, location context, and session state, needs to support one operational interaction.
• Short-lived SMS links create a clear session-lifecycle boundary.
• Emergency-response software requires careful testing, troubleshooting, and delivery discipline.

Approach

The engineering contribution connected product requirements with implementation planning across frontend, backend, media, mapping, integration, and delivery. Architecture and full-stack work supported the public workflow by starting a short-lived session, letting the caller join from a browser, surfacing location and media context, and keeping communication available to the operator.

Stakeholder discussions and troubleshooting were part of the same delivery loop. Requirements had to become implementable work, then be reviewed, tested, and supported through deployment.

Important decisions

Reduce caller friction

Using a browser session reached through an SMS link avoids requiring app installation. The engineering work needed to respect browser and device differences while keeping the joining path clear.

Keep operational context together

Video alone is not the complete workflow. Location, chat, session status, and secure data handling provide the surrounding context an operations centre needs for assessment and guidance.

Treat delivery as part of the system

Testing, CI/CD, deployment, troubleshooting, and planning were part of the contribution. For mission-critical product work, operational readiness cannot be separated from implementation.

Lessons learned

Low-friction emergency communication depends on more than media transport. Session entry, browser compatibility, location context, operator workflow, and failure handling must work as one journey.

Confidential product work can still be explained responsibly. Public capabilities, scoped contribution areas, engineering tradeoffs, and operational purpose provide useful evidence without exposing customers or private implementation details.