Professional experience · Connected networking · 2026 – present

The cloud control plane for a wireless networking product

A cloud platform built from scratch for a hardware startup's wireless base stations. It covers device identity, telemetry and OTA updates, plus an AI assistant network engineers use to configure their sites.

0 → 1
cloud platform owned end to end
AI + MCP
chat-driven, human-approved device configuration
  • AWS
  • Go
  • NATS / MQTT
  • X.509 & mTLS
  • ClickHouse
  • Terraform
  • MCP

Professional experience as Cloud Lead at NoWire Connect AB. Described at the level that’s appropriate to share publicly.

Context

NoWire builds outdoor wireless networking: base stations and relay nodes that form mesh networks in places where cables don’t reach, with uplinks over fibre, LTE/5G or satellite. The hardware and embedded networking were in good hands. What didn’t exist yet was the cloud: the part that knows which devices exist, what they’re allowed to do, how they get configured and updated, and what they’re telling us.

As founding platform engineer I own that cloud side end to end, working closely with the founders and the embedded team.

The hard problems

  • Device identity. A physical device has to be enrolled, proven genuine, assigned to a network cluster, moved later and eventually decommissioned. A shared API key or a self-reported cluster ID won’t do.
  • Fine-grained messaging permissions. Lightweight embedded MQTT clients need a broker that still enforces per-device and per-cluster permissions, and updates them when the fleet changes.
  • Telemetry that doesn’t bankrupt you. Radio, power, traffic and client metrics every few seconds are gold for operations and expensive to keep forever.
  • Production foundations on a startup budget. Real account isolation, security, reproducible infrastructure and sane releases, without a platform team’s overhead.

What I built

  • AWS foundations. A multi-account organisation with SSO, guardrails and budgets, all provisioned as code through Terraform/OpenTofu and GitHub Actions with OIDC. No long-lived CI keys.
  • Go services on a small footprint. A control-plane API with desired-state management, PostgreSQL as the source of truth, and services sized to the team rather than to a conference talk.
  • Hardware-first device identity. Certificate-based enrolment and mTLS, with physical identity kept separate from logical fleet membership so devices can be reassigned safely.
  • Dynamically authorized messaging. MQTT over NATS where each device’s permissions are derived from cloud-side fleet state rather than trusted from the device.
  • Economical telemetry. ClickHouse with batched ingestion and multi-resolution rollups: short-lived raw data, aggregates for months, hourly trends for years.
  • OTA updates. Firmware delivered through object storage with short-lived signed URLs, orchestrated from the cloud instead of pushing big files through the message broker.
  • An AI copilot for network engineers. MCP servers that let AI read a base station’s configuration, spot issues and propose changes, which the engineer approves only on equipment they have access to. Customers can plug in their own AI through the same MCP interface.

Decisions that mattered

  • Simplify the MVP on purpose. Several clever early designs (embedded brokers, custom gateways, outboxes) were cut in favour of devices talking straight to cloud MQTT and fetching firmware over HTTPS.
  • Self-hosted where it pays. Managed AWS services where they remove toil; a self-run broker where cost, protocol needs and on-prem portability matter.
  • Humans approve, AI assists. The AI layer sits on top of the same identity and permission model as everything else, so it can’t do anything the engineer couldn’t.

Lessons

IoT security is mostly an identity and lifecycle problem, not a crypto problem. And AI features are only as trustworthy as the permissions underneath them: get the platform right first, and the AI part becomes surprisingly straightforward.

← All case studies

Have a difficult technical problem?

Tell me what you're building and where it's getting stuck. I usually reply within two working days.

Email hello@tomalaci.com