DEV Community: Liang Jacky

From Satellite Pixels to Farmer Decisions: What Building FieldLens Taught Me

Liang Jacky — Tue, 27 Oct 2026 09:05:55 +0000

This post is part of the Monthly MLH × DEV Writing Challenge — a look back at what I built, how I built it, and what I'd do differently.

This post is part of the Monthly MLH × DEV Writing Challenge — a look back at what I built, how I built it, and what I'd do differently.*

The problem nobody asked me to solve

I grew up around pomelo orchards in Meizhou, Guangdong. Every year, growers there make the same high-stakes guesses: which blocks are underperforming, where to fertilize, whether the irrigation is actually reaching the trees. Satellite data could answer all of this — Sentinel-2 flies over every five days, free for anyone to use. But "free data" and "usable answers" are very different things. No grower I know is going to open Google Earth Engine and write JavaScript.

There's a part of this origin story I didn't tell in my submission post. In July, I joined the fieldwork for a Guangdong provincial research project — a Natural Science Foundation–funded study of farmland protection, including the "farmland chief" system （田长制）, led by a South China University of Technology team. For a week I walked villages in Fengshun and Jiaoling doing door-to-door farmer interviews and organizing the survey data.

The farmland chief system is simple to describe and exhausting to run: named local officials are personally responsible for watching specific plots — walking them on foot, checking that nothing illegal gets built and nothing is abandoned. Sitting in farmers' homes, working through a 29-question survey on how this system actually runs, I kept coming back to the same thought: the whole oversight system runs on human legs and human eyes, a few times a month if that. A satellite passes over those same fields every five days, for free.

And one farmland chief （田长） said the quiet part out loud. He wasn't asking for software — he was just tired of the work. If there were automatic monitoring, he told me, he wouldn't have to go out and check the fields under a blazing sun or in the wind and rain.

That week is where FieldLens really started: the very person whose job is walking the fields, naming the pain in plain words — and me realising the data that could answer it was already falling from the sky, for free.

So for Hacktoberfest Week 2 ("Side Hustle"), I built "FieldLens": draw your orchard on a map, get a vigor report that reads like advice from an agronomist, not a data dump. NDVI time series go in; plain-language actions come out — in Chinese for the growers, in English under the hood.

🎥 Live demo: https://fieldlens-api.onrender.com/app

How it works (the honest version)

The pipeline is deliberately boring where it should be, and interesting where it matters:

Draw a polygon on the map (or use the sample orchard — more on that below).
Sentinel-2 NDVI time series pulled through Google Earth Engine, composited into vigor zones across the block.
A local Gemma model via Ollama writes the advisory report. This was a deliberate choice, not a gimmick: grower data never leaves the machine, there's no per-report API bill, and it works where connectivity is flaky. The report takes a lang parameter — Chinese for the actual farmer reading it, English for the code comments and the DEV crowd.
A 199 RMB/plot/year pricing story, because the Week 2 theme was "build something someone would actually pay for." I priced it like a utility bill, not a SaaS moonshot.

Two decisions I'm proudest of are both about honesty with data:

During research I found that NDVI ≥ 0.70 is a drone canopy-pixel reference, not a Sentinel-2 block-average threshold. Mixing those up is exactly how ag-tech demos lie to farmers. I added an explicit caveat to the model's prompt so it never presents one as the other.
Every screenshot and demo polygon is a sample geometry with a visible "Sample" badge. I never drew a real orchard boundary in any public material. Real growers' land stays private, full stop.

What I learned

Writing is the product.Hacktoberfest's judging criteria weight writing quality above everything else, and building FieldLens taught me why: the demo took a week; explaining why it matters to a specific person took longer and mattered more. "A grower in Meizhou deciding where to fertilize this week" beats "a satellite analytics platform" every time.

Local AI is a feature, not a compromise.Running Gemma locally wasn't just cheaper — it became the trust story. "Your orchard data never leaves your computer" is the sentence that makes a skeptical grower keep listening.

Cold starts are a design constraint.The demo runs on Render's free tier, which sleeps. Instead of fighting it, I documented it in the post and designed the UI to degrade gracefully. Constraints you name honestly stop being embarrassments.

First users are slower than code. I reached out to a pomelo-growing relative in Meizhou through a carefully written WeChat message. No reply yet. The code shipped in a week; trust takes a season. That's fine — the field validation is scheduled for November, and the product will be shaped by what actually happens in the orchard, not by what I imagine happens.

What's next about the future

Radar-optical fusion. Southern China is cloudy for months; optical imagery alone has gaps. A recent paper hit 93% early-season crop classification by fusing Sentinel-1 radar with optical time series — that's going straight into the FieldLens method library.
A second software copyright if the November validation works — because in my world, shipped and validated beats shipped and demoed.

Why open matters here

None of this works closed. Open satellite data (Sentinel-2), an open-weight model (Gemma) running on my own machine, open tooling throughout. If FieldLens depended on a proprietary API, every report would cost money, every grower's data would travel somewhere, and the whole "199 RMB a year" story would collapse. Open is what makes this deployable, not just demoable.

Built with open-source AI for Hacktoberfest 2026. If you work on ag-tech, remote sensing, or just like the idea of satellites helping small growers — I'd love to hear what you'd build differently.

FieldLens: Orchard Vigor Monitoring That a Grower Would Actually Pay For — Sentinel-2 NDVI + Local Gemma

Liang Jacky — Fri, 16 Oct 2026 13:28:34 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

FieldLens turns a drawn orchard boundary into plain-language growing advice.

A grower draws a plot on the map. FieldLens pulls Sentinel-2 imagery through Google Earth Engine, computes an NDVI vigor time series for that plot, and a locally running Gemma model turns the curve into a short report: what changed, what it might mean, and what to check in the field. (Where no local model is available, a deterministic rule engine covers the same steps — labeled in-app as a fallback.)

We're starting with high-value orchards in Meizhou — Dapu honey pomelo and citrus — at 199 yuan per plot per year. The buyer is not a tech company. It's a grower who already walks the orchard and wants to know which block to check first.

Why would a grower pay for this when Sentinel-2 data is free? Because they're not buying data — they're buying a shortcut: instead of walking every block to find the struggling one, the report tells them which block to check first. The 199 yuan isn't priced on our costs (near zero per report, thanks to the local model). It's priced on the grower's decision: cheap enough to say yes to without a meeting.

What the report deliberately won't do: diagnose a disease, or prescribe pesticide doses. It says what the NDVI curve shows, flags what looks unusual, and tells the grower to go check in person.

Demo

Live demo: https://fieldlens-api.onrender.com/ — the tool page is at /app.

Note: the demo runs on Render's free tier — if it has been idle a while, the first load may take ~30 seconds to wake up; everything after that is fast.

How to try it in 30 seconds: open the demo, click "Load demo field", then generate the report. No account, no drawing required.

An honest note on scope: the live demo above runs the UI and the sample field on a transparent rule-engine fallback (labeled in-app as "Rule-based fallback"); the full GEE + local Gemma chain runs on my own machine — setup is in the README. The sample polygon is illustrative, not a real farm's boundary, and every threshold is a literature value cited in the README.

Code

Repo: https://github.com/liangjacky8921/fieldlens (Public)
The README covers setup (ollama pull gemma2:2b, earthengine authenticate), the /api/ndvi endpoint, and a data-sources section with a source note on every threshold.

How I Built It

Frontend: map drawing (Leaflet) + bilingual UI (English default, Chinese reports for real growers).
NDVI: NDVI = (B8 − B4) / (B8 + B4) on COPERNICUS/S2_SR_HARMONIZED, Sentinel-2, ~5-day revisit.
Interpretation thresholds (all sourced in README, not invented):
- NDVI ≥ 0.70 = high-vigor canopy (published sweet-orange study).
- NDVI > 0.25 = vegetation vs soil (published sooty-mould study).
- Citrus-orchard NDVI ranges from published studies, including how low values can go under stress or infection — the report treats a drop as a reason to go look, not a diagnosis.
Report: local Gemma (gemma2:2b via Ollama) with a lang parameter (English default, Chinese for growers). Alert rules (e.g. drop > 0.10) are project settings, labeled as such — not literature values.
Sample field: an illustrative polygon inside the real Dapu honey-pomelo geographical-indication protection zone (116°18′–116°56′E, 24°01′–24°41′N). It's labeled "Sample field" in the app — not a real farm's boundary.

The NDVI pipeline is one file (app/gee_ndvi.py). Per-scene mean is computed twice: once with QA60 cloud masking, and once unmasked as a fallback for scenes where cloud cover masks the whole plot. Scene-level means are then reduced to a single value per revisit date, and any scene with a null (fully cloud-masked) mean is dropped rather than counted.

# Dual-track per-scene NDVI mean: QA60-masked, falling back to unmasked mean
# so a fully cloud-covered scene still contributes instead of being silently dropped.
masked = ndvi.reduceRegion(reducer=ee.Reducer.mean(), geometry=geom, scale=10)
unmasked = ndvi.unmask().reduceRegion(reducer=ee.Reducer.mean(), geometry=geom, scale=10)
return ee.Algorithms.If(
    ee.Algorithms.IsEqual(masked.get('nd'), None),
    unmasked.get('nd'),
    masked.get('nd'),
)

Why Open Innovation Matters

All economic, not ideological:

The unit economics only work because the model is local. A per-report cloud API bill would eat the 199 yuan/plot/year price. Local Gemma has no per-call charge, so the price can stay low enough for a grower to say yes.
The data stays on the farm. Plot boundaries and orchard health are business-sensitive. Nothing is uploaded to a vendor server for inference.
Open data + open weights = auditable numbers. Sentinel-2 is open Copernicus data; every threshold in the README carries its source. A grower (or a judge) can check where each number came from.

First User

We're in talks with a Meizhou pomelo cooperative to run an on-site validation in November — real blocks, real walking, comparing the report's "check this block first" ranking against the grower's own walk order.

Prize Categories

Best Use of Gemma — report generation runs on local Gemma 2B via Ollama; the live demo surfaces the labeled fallback path because Ollama can't run on Render's free tier.
Best Use of Render — frontend + FastAPI backend + GEE-backed NDVI pipeline deployed on Render; /health reports gee_ready: true.
Overall (Week 2: Side Hustle) — a grower would actually pay for this.