The questions that come up on every first call

We design and build firmware, and we work with your electronics team or one of the contract manufacturers we partner with for schematic and enclosure work. If you have no hardware partner yet we will introduce you to two and stay out of the commercial conversation.

You do, from the first commit. Work happens in your repository where possible, or in ours and transferred at each milestone. Nothing we write for you is reused in another client's product.

Every device gets a unique X.509 identity provisioned at manufacture, talks over mutual TLS, and can only be updated with a signed image. Keys never leave the secure element. We run a threat model in week one and revisit it before the production rollout.

It keeps working. Local rules continue to run on the device or gateway, readings are buffered to flash, and the backlog is replayed with original timestamps when the link returns. We test this by pulling the cable during the pilot.

Because the work is overwhelmingly I/O rather than computation: thousands of idle connections, small frequent messages, and fan-out to live dashboards. Node handles that shape well, the ecosystem for MQTT and streaming is mature, and one language across backend and frontend keeps a small team fast. Where we need heavy number crunching we put it in a Python or Rust service and keep the rest as it is.

Discovery usually begins within two to three weeks of a signed statement of work. If you are up against a trade show or a regulatory date, tell us on the first call and we will say honestly whether it is possible.

Often, yes. We start with a two-week architecture review so both sides know what we are inheriting, then agree a plan to stabilise before adding anything new.

A fixed-scope pilot is priced after discovery, because pricing it before means padding it. The estimator on the engagement models page will get you to a defensible range for budgeting, and discovery converts that range into a number we will hold to.

Alongside, in almost every case. The most common arrangement is that we own the parts nobody internally has done before — usually firmware and the ingest path — while your team keeps the domain logic they already understand.

A pilot is fixed scope, so it ends when it ends. A pod needs a month's notice after the initial three. In either case you already have the code, the infrastructure definitions and the runbooks, because they are delivered continuously rather than at the end.

Yes, and we will send ours if you do not have one ready. Nothing about your product is discussed outside the engagement team.

A monthly fee based on fleet size and the response time you need, with the infrastructure billed to your own cloud account rather than through us. You can see the bill and you can cancel without a migration project.