Skip to content
helloinfotech
ProductsFieldsMethodNotesAboutContact

Research and product company

We build the systems other systems depend on.

Hello Infotech researches and builds its own products, from firmware and packet forwarding up to distributed platforms. We own what we ship, and we stay answerable for it in production.

ProductsMethod
Two engineers collaborating at an electronics workbench.

Research, together

Hardware, networks and platforms tested as one system.

View products

Fields

Four fields, one company

The products sit across layers. A latency regression can be a scheduler decision, a queue policy or a cache line — and the research has to be fluent in all three.

All fields
Systems & Software ArchitectureDistributed systems designed to survive contact with production — and with the next five years of change.Distributed-system boundaries and contracts · Event-driven and streaming systems · API design, versioning and compatibilityEmbedded Systems & FirmwareFirmware and embedded Linux for products that ship, run unattended for years, and update safely in the field.Board bring-up and hardware/software integration · Bare-metal and RTOS firmware development · Embedded Linux BSPs, Yocto layers and kernel driversNetworking, Datacom & TelecomCarrier and data-centre networking from the packet up — control plane, data plane, and the software that operates both.Routing, forwarding and convergence · Data-centre, campus and carrier-edge network design · Data-plane implementation and packet processingPlatform, DevOps & ReliabilityThe delivery path and the runtime beneath it — automated, observable, reproducible, and boring in the best sense.Kubernetes platform design and hardening · GitOps delivery pipelines and progressive rollout · Infrastructure as code and environment reproducibility

How we operate

Research,
then a product.

A lab that only writes papers never finds out whether the idea survives. A product company that skips the research ships the first idea. We do both, and we keep the result.

  • We keep what we build

    The people who design a product are the people who run it. There is no hand-off to a delivery team.

  • Decisions are written down

    Every significant trade-off ships with the reasoning behind it. The architecture stays explained, not just compiled.

  • Measured, not asserted

    Performance and reliability claims come with the methodology and the numbers. If we have not measured it, we say so.

  • Whole-stack research

    Firmware, packets and distributed services in one company — because the hardest defects live exactly where those layers meet.

Products

What we are building

Products we own, and research designs published with the reasoning. Each one is labelled. Nothing on this site is client delivery work.

View all
Product2026

corerouter — a first-party routing stack in Rust

An edge routing stack with no unauditable components — DHCP, DNS, firewall, multi-WAN failover, traffic shaping and a transactional configuration plane, all first-party, with zero third-party runtime dependencies and a total footprint of about 15 MB.

Status In service on ARM64 hardware, serving live clients — Wi-Fi, DHCP, DNS, NAT and firewall. Current scope is IPv4 edge routing.

NetworkingEmbeddedPlatform
Third-party runtime dependencies
Zero
Total memory footprint
~15 MB
Config transactions, auto-revert
Atomic
Failure paths tested against a live kernel
Fault-injected
Product2026

NorthStar — end-to-end encrypted conferencing for regulated organisations

Browser-based video conferencing where the media server never holds the keys — built for organisations whose legal team needs a better answer than "trust the vendor".

Status In pilot with design partners. End-to-end encrypted two-party calling and screen share, verified across desktop and mobile browsers. Multi-party is in development and ships as secure only when its cryptography is verified.

SoftwarePlatformNetworking
Product2026

ChatForge — team messaging you host yourself

A self-hosted messaging platform for teams whose conversations should not live on someone else’s servers — real-time and complete enough to use, small enough to audit.

Status Phase 1 shipped and tested: the real-time messaging core — conversations, replies, reactions, presence, read state and attachments — running end to end on infrastructure you control.

SoftwarePlatform

Method

From a question to a product we run

The same five stages on every effort, scaled to the size of the work. Each one has an output. None of them is a hand-off to someone else.

How we build

  1. Frame

    We establish what the system must do, what it must never do, and which constraints are real. Most projects fail here, quietly, and only find out later.

  2. Design

    Boundaries, contracts, failure modes and capacity — written down as decision records with the trade-offs made explicit, so the reasoning outlives the meeting.

  3. Build

    Small, reviewable increments behind automated verification. Working software at every step, never a six-month integration cliff at the end.

  4. Harden

    Load, fault injection, soak testing and security review before production — not after it. We try to break it while breaking it is still cheap.

  5. Ship

    Documentation, runbooks and telemetry ship with the product, and we keep operating it. A product we cannot run ourselves is not finished.

Notes

What the work taught us

Published as the research happens, so the thinking can be read without a brochure around it.

All notes
Software · 3 minYour average latency is a story about a system nobody usesMean response time describes a request that mostly does not exist. Tail latency describes the one your customer remembers — and at scale, almost every user hits the tail eventually.Networking · 3 minNetwork convergence is not one numberA vendor datasheet quotes convergence as a single figure. In production it is a chain of four independent delays, and the one you did not tune is the one that decides your outage duration.Embedded · 3 minThe bootloader is the only code that is never allowed to be wrongEvery other component in an embedded product gets a second chance through an update. The code that performs the update does not. That asymmetry should change how it is written and reviewed.

Contact

A question about the work?

A product, a research note, or something this site got wrong. Write to us. The reply comes from the people who build it.

Contacthello@helloinfotech.in