Aerobotics builds agricultural intelligence software: drone and satellite imagery turned into something a grower, an insurer, or a field team can act on, across farms, orchards, crop blocks, yield estimates, scouting, and pest and disease tracking.
I spent about a year and a half there as a senior frontend and mobile engineer on the Aeroview suite, working across three connected products: the web platform growers and internal teams use, the In-Field mobile app field teams take into the orchard, and the internal configuration tool that keeps all the farm data straight. It was a busy codebase with several engineers; I was one of the larger contributors, mostly on the web platform.
What I built
Most of my time went into the Aeroview web platform. I helped stand it up and then built across a lot of its surface: yield and performance reporting, the map-driven farm views, crop inventory and counts, investigations, irrigation, and pest and disease. Yield and crop estimation was the part I lived in most, fruit-size target setup, raw fruit-size binning, size distribution and forecast graphs, sample positions, growth curves, and the long tail of empty states, translations, and edge cases that estimation work always drags along. Alongside the product work I created and grew the Aeroview design system: the tokens, the Storybook, the component set (buttons, inputs, selects, tables, modals, date pickers), and the accessibility and testing foundations under it.
On the In-Field mobile app I worked across the offline field workflows and the camera-heavy data capture: scouting screens and drone scout maps, sample positions, pest traps, multi-capture camera flows, image galleries, and the offline persistence, sync, and batch uploads that keep a day’s scouting intact when the connection drops. That reached down into native territory too, iOS camera code, file-system image handling, map-rendering performance, and the iOS and Android release plumbing (CodePush, Firebase distribution, TestFlight, Fastlane, CircleCI).
The third surface was the internal configuration tool, the least glamorous and quietly important one. It is what ops teams use to set up client and farm data: policies, crop years, farm boundaries, shapefile import and export, assigning blocks to farms, and the farm creation and transfer flows.
Threaded through all of it was the engineering-quality work: a Create React App to Vite migration, React and TypeScript upgrades, the linting and commit conventions, Storybook, the Vitest/Jest/Playwright setup, and Sentry.
Hard parts
Almost everything here was geospatial, and maps are unforgiving. Farm and block layers, image overlays, markers, bounds, selection state, the Turf calculations, all of it had to stay fast and correct while a grower panned around an orchard, because the map wasn’t decoration. It was the actual interface to the data.
The other hard part was the field app. Field teams work where the connectivity isn’t, so the app had to be genuinely offline-first: capture photos and samples, persist them locally, then sync and batch-upload reliably whenever a signal came back, without losing or duplicating a day’s scouting. Getting that sync boring and trustworthy was most of the battle.
Stack
React 17 and React Native, TypeScript, Vite (migrated off Create React App); Google Maps with Aerobotics’ own map packages, Turf.js, and D3, Recharts and Nivo for the charts; WatermelonDB, Redux Saga, React Native Vision Camera and background-upload tooling on mobile; i18next and Lingui with Lokalise; Sentry, Firebase and Mixpanel; Storybook, Vitest, Jest, jest-axe and Playwright; and CircleCI with Fastlane for the iOS and Android releases.