Every material should be able to describe itself

Frontier AI has consumed nearly everything humans have written and photographed. It knows almost nothing about physical reality. Not because the world is unknowable, but because measuring it was assumed to cost more than the answer was worth. Entire industries run overprovisioned and underutilized because they cannot measure what matters.

Flying Wire solves that. We build pixels: self-contained computers smaller than a grain of sand, embedded directly into the materials around us. When a sensing point costs a few cents instead of tens of dollars, density stops being a budget decision.

Put a hundred on a server rack instead of two and problems that were invisible become clear. A containment gap here. Local overcooling there. Capacity you are paying for and cannot use. Do that everywhere and every surface describes itself continuously: drones, turbine blades, aircraft cabins, furnace walls.

The hardware is the pixel. The product is the physical data layer that emerges when thousands of spatially aware pixels report continuously from an asset. That layer does not exist yet. That is the job.

You are the first software hire, and everything between the pixel and the customer's query is yours to design, build, and own.

What We're Asking of You

Move the data, and prove it can be trusted
Thousands of pixels today, and an architecture that has to survive millions. They report continuously from environments we do not control, over connections that drop. You will build the ingest path over MQTT or whatever replaces it, the buffering and backfill that survive dropped connections, and the quality layer that catches problems before a customer does. Sensor exhaust behaves nothing like clean API data. Expect dropout, calibration drift, late and out-of-order readings, gaps that need reconciling, and a device fleet running mixed firmware. Making that data trustworthy is the foundation everything else sits on.

Give every reading a place in the world
A reading is useless without knowing where it came from. You will decide how spatial metadata is modeled, stored, and queried, and how a physical asset gets resolved into an instrumented map: deploy, scan, locate. We own the full pixel creation process, so the hardware is not fixed: we expect you to partner with the hardware team on the optimal solution, not work around the status quo. The model has to hold up whether pixels go down structured, adhered to tape along a rack, or unstructured, sprinkled into an environment with no grid at a

Protect the economics
Our hardware advantage is cost per sensing point. That advantage only holds if the data layer preserves it. Given our ambition to sense the physical world at scale, you will need to make the calls on sampling rates, retention, storage tiers, downsampling, and deadband.

Build the substrate, not the app
We are not building a general purpose analytics suite. The platform's job is the hard part: building the metadata that surrounds each pixel and structuring it so everything downstream moves fast. Schemas people can reason about, data contracts that do not break, documented APIs, bulk export that works. The consumers are our own applications, our customers' existing systems, and the models they will eventually point at this data. Every facility we enter already runs software that monitors it and we have to integrate seamlessly with all of them. If a customer's engineer can answer a question about their facility in an afternoon without calling us, the platform is doing its job.

Own the device fleet
Thousands of devices will land in facilities that take security seriously, and most of what protects them does not exist yet. You will own how devices get identity, how they are onboarded and authenticated, and how firmware reaches the fleet without anyone driving to a site.

Sit at the table
You will spend real time with the operators and engineers who depend on this data. The data model is only right if it matches how they think about their assets. Our commercial strategy is to put hardware in customers' hands and let them show us the use cases we did not anticipate. You have to hear that and build the general version, not one customer at a time. You will also carry what you learn back into decisions about hardware, firmware, and what we sell next. We are not hiring someone to build to a spec. We are hiring the person who helps write it.

What We Think It Takes

• You have designed, operated, and owned data systems where the source was physical and unreliable: sensors, vehicles, industrial equipment, scientific instruments. You have been paged at 2am to get everything back on track

• You have real opinions about time-series storage and can defend them with cost numbers.

• You have handled schema evolution on a dataset you could not go back and re-collect.

• You have built idempotent backfills, replay, and reconciliation against partial or out-of-order data.

• You treat data contracts, lineage, and pipeline observability as part of the build, not as cleanup afterwards.

• You have designed an API that external developers had to live with, and you cared how it felt to use.

• You get suspicious when a number looks slightly wrong, and you chase it down rather than filing it away.

We do not have hard requirements for degrees or years of experience. We are looking for intellectual curiosity and for engineering judgment good enough to be trusted alone. Customers will make expensive decisions about their facilities and products based on what this platform tells them, and readings we lose or corrupt cannot be collected again. That sets the bar. If you read the list above and immediately started thinking about how you would build it, we should talk.

Why Flying Wire

• This is a founding-level seat. Flying Wire is a hardware company and a data company, and the data half is a prototype, not yet a platform. You will build it and set the engineering culture from day one. You report directly to the CEO and sit in every major tradeoff between hardware, product, and data. Make your case, own the outcome.

• You own the software stack. Not a component of it. Everything from the pixel to the API, plus the call on what gets built next. No legacy system, no inherited decisions, no migration.

• The people. Our CTO invented the manufacturing process and is a professor of chemical engineering at Georgia Tech. Our engineering leads come from Georgia Tech, Stanford, and Festo. Our advisors include the former CMO of Wiliot and a hardware leader from Logitech.

• The hard part is behind us. Five years of DARPA and NSF funding, exclusively licensed from Georgia Tech. The pixels work, customers are already paying, and the volume only goes up from here.

• Freshly funded. We just closed an oversubscribed seed round from top tier VCs. The runway and the mandate both exist, and the budget to hire and lead your own team comes with the next raise.

Send a short note, CV or LinkedIn, and a brief description of a data system you took from prototype to production where the data source was physically unreliable. What broke, and what you did about it. Email mike@flyingwire.io.