Node.js on the back, React on the front, boring everywhere it counts
We keep a deliberately narrow toolkit so any engineer on the team can pick up any project. New tools have to earn their place against something we already run in production.
Backend — Node.js
- Node 20 LTSruntime
- TypeScriptstrict mode
- NestJSlarge domains
- Fastifyhigh-throughput ingest
- Socket.IOlive console feeds
- BullMQjobs and retries
- Zodpayload validation
- Prismadata access
Frontend — React
- React 18UI
- Vitebuild
- TanStack Queryserver state
- Zustandclient state
- Tailwind CSSstyling
- Recharts / visxtelemetry charts
- MapLibre GLfleet maps
- Storybookcomponent review
Data and messaging
- EMQX / MosquittoMQTT broker
- Kafkastream buffer
- TimescaleDBtime series
- PostgreSQLrelational
- Rediscache, presence
- S3blobs, firmware
Devices and edge
- Zephyr RTOSportable firmware
- ESP-IDFESP32 family
- nRF Connect SDKBLE
- LoRaWANlong range
- Modbus / OPC UAindustrial
- AWS Greengrassedge runtime
Platform and delivery
- AWS / Azure IoTcloud
- Dockerpackaging
- Kubernetesorchestration
- Terraforminfrastructure
- GitHub ActionsCI/CD
- Grafana / Lokiobservability
Quality and security
- Vitest / Jestunit tests
- Playwrightend to end
- Renodefirmware simulation
- Fleet simulatorload testing
- mTLS + X.509device identity
- Signed OTAupdate integrity
Four rules for adding anything to it
New tools have to displace something
We do not add a technology to the toolkit without retiring one or writing down why both need to exist. Every extra tool is a thing the on-call engineer has to understand at 3am.
Boring where it counts
The ingest path, the database and the deployment pipeline are deliberately conventional. We spend novelty budget on the parts of your product that are actually novel.
Anyone can pick up any project
A narrow stack means an engineer moving between two of our builds is productive in a day rather than a fortnight, and your project is never one person's private knowledge.
You could hire for this
Everything here has a real hiring pool. When we hand over, you are not looking for the four people in the country who know an obscure framework.
Already committed to a different stack?
That is usually fine. We have delivered on Azure, on plain Kubernetes and into codebases we did not start. An architecture review is the cheapest way to find out.