Daniel LarkinSystems Architect & Technical Founder

I build systems for places where failure isn’t recoverable.

Systems architect and technical founder. Applied AI, distributed systems, and edge infrastructure down to the firmware it runs against. Usually a few years before it was comfortable.

Based
UTC+8 · works anywhere
Building since
2010
On Workers since
2017

Three industries, one failure mode.

Vertical farms, off-grid houses and technical divers look like unrelated industries. They are the same engineering problem.

Each is a closed loop running under constraint, where a model is the only thing standing between the system and a failure you cannot undo. A hydroponic bay drifts and a crop is gone in days. A house misjudges its power budget in winter and the people inside are cold. A decompression schedule is wrong by a few minutes and a diver is hurt on the way up.

I build the instrumentation for those loops: the sensing, the modelling, the control, and the distributed infrastructure that keeps them honest when the network is not.

Most systems are not life-critical. The ones worth hiring me for behave as if they are.

Bloom

2016–2017Vertical farming · computer vision

Teaching a camera to notice a plant is sick before a grower can.

Bloom was a vertical-farming stack built around one question: can a machine see disease earlier than a person walking the aisles?

We trained convolutional image models on leaf imagery to classify disease and deficiency from the visual signal alone, then fed the classification straight back into the hydroponic control loop. Nutrient dosing, EC and pH targets, photoperiod and spectrum all moved on the model, so the response was automatic rather than advisory.

This was 2016. There was no off-the-shelf vision API worth the name for this, no managed training platform that made sense at our budget, and no pretrained agricultural model to fine-tune. We gathered the dataset, labelled it, trained it, and ran inference on hardware sitting in a humid room next to the plants.

Domain
Controlled-environment agriculture
Models
Convolutional image classification · disease & deficiency
Control
Closed-loop dosing, EC / pH, photoperiod, spectrum
Constraint
On-site inference, intermittent connectivity

OneIsland

2018–2022CAD / CAM · robotics · off-grid housing

A browser that outputs a house.

OneIsland compressed the distance between designing an off-grid dwelling and manufacturing one.

The core was a web-based parametric CAD environment: geometry kernel, constraint solving and real-time visualisation running in the browser, coupled directly to CAM output and robotic fabrication. A change to the design propagated through to toolpaths and cut files without anyone redrawing anything.

The hard part was never the rendering. It was building a geometry system that stayed numerically stable across thousands of parametric edits, that emitted toolpaths a machine would actually accept, and that treated the physical constraints of living off-grid as first-class parameters rather than notes in a PDF: thermal envelope, water capture, power budget, structure.

Domain
Off-grid housing, design-to-manufacture
Core
Browser-native parametric CAD, geometry kernel, constraint solver
Output
CAM toolpaths, robotic fabrication, cut files
Encoded
Thermal envelope, water capture, power budget, structure

DiveLogic

PresentDecompression modelling · applied AI

Right to the minute, or not right at all.

DiveLogic is decompression planning for technical, cave and closed-circuit divers. It is the segment where the plan is the safety equipment.

It implements Bühlmann ZHL-16C with gradient factors and VPM-B, tracks CNS, OTU and IBCD across every phase of a dive, and plans multi-gas trimix and heliox profiles with automatic switch depths, bailout ascents, lost-gas contingencies and rule-of-thirds reserves. It syncs over Bluetooth with Shearwater Perdix, Petrel and Teric computers, and replays tissue loading afterwards so a team can debrief against what actually happened.

The AI sits on top of the physiology, never in place of it. Divers interrogate a plan in natural language and the system proposes adjustments, but every number it returns is produced by the deterministic model underneath and traceable back to it. In this domain a plausible answer is worse than no answer.

Models
Bühlmann ZHL-16C · gradient factors · VPM-B
Tracking
CNS · OTU · IBCD, across all phases
Gases
Nitrox · trimix · heliox, automatic switch depths
Hardware
Shearwater Perdix / Petrel / Teric over Bluetooth

At the edge since there was an edge.

Edge · Rust · embedded

Cloudflare shipped Workers in 2017. I was building on it that year, when the runtime had no KV, no Durable Objects, no queues, no D1, and a deployment story you assembled yourself. I shipped tooling for the platform because the platform did not have any yet.

That period taught the most useful thing I know about distributed systems: when compute is everywhere and state is nowhere, correctness stops being a database feature and becomes a design problem. Everything since is the same problem with better primitives: edge inference, globally consistent state, coordination without a coordinator.

The same instinct took me to Rust. Where a wrong answer has a physical consequence I want the compiler arguing with me before the system does, and I want to know what the machine is actually doing with my memory and my microseconds. Rust also compiles to WebAssembly for the edge and to bare metal for a microcontroller, so one implementation of a model can run in a browser, in a Worker, and on the device holding the sensor, and return the same number in all three. That property is worth more than any framework.

Below all of that is hardware. Inference running next to the plants at Bloom, toolpaths driving machines at OneIsland, dive computers syncing over Bluetooth at DiveLogic: every venture I have built ended at a device standing in a place with unreliable power and worse network. I write the firmware and the control loops that sit on it, because that is where the interesting failures live. Not in the dashboard.

Edge
Cloudflare Workers · Durable Objects · WebAssembly
Systems
Rust, and C where the hardware insists
Targets
Microcontrollers · single-board Linux · the edge · the browser
Constraint
Intermittent power, intermittent network, no second attempt

Three ways to bring me in.

Advisory · Build · Diligence
  • Applied AI & ML systems
  • Distributed systems & consistency
  • Edge architecture & Cloudflare Workers
  • Rust & WebAssembly
  • Embedded firmware & real-time control
  • Sensing & instrumentation
  • Design-to-manufacture pipelines
  • Systems where safety is a requirement, not a feature

Before all of that.

Tecto · New Zealand

Before the ventures I ran Tecto, my own systems architecture consultancy in New Zealand, delivering for institutional clients: the University of Otago, the New Zealand Parliament and ACC. Systems with real users, real auditors, and no appetite for surprises.

30,000+customers on products I have built and shipped.
5,000+users on open-source libraries I maintain.
2 × mentorStartup Weekend, plus judging entrepreneurship programmes across New Zealand.
Daniel Larkin, smiling, in dense New Zealand rainforest wearing a bright floral shirt.
Indonesia · New Zealand · UK · UTC+8

Available globally.

New Zealand originally. I work from UTC+8 now, between Indonesia and New Zealand, with summers in the UK, and to whatever timezone or site an engagement actually needs. Distributed work is not a concession I make. It is the condition I have designed for from the start.

The rest of the time I am away from a desk: off-grid, up mountains, or a long way underwater. That is not a personality section. It is where the work comes from. Every system I have built started as a problem I met somewhere without reliable power, without reliable network, and without a second attempt.

The best engineering I know is the kind that assumes conditions will get worse.

Tell me what’s hard.

If you have a system that has to hold, and you would rather find out now than at 3am, write to me. I read everything and reply to anything specific.

What happens next

  1. A reply, from meNot a form response and not an assistant. Usually within two working days, wherever you are.
  2. A call, if it fitsForty-five minutes on the actual system. You will get an opinion on that call whether or not we work together.
  3. A written proposalScope, shape, price and what I would need from your team. No retainer talk before we know the problem.