Problem
Plant owners who lose a plant usually lose it slowly: a symptom shows on a leaf, nobody knows what it means, and by the time a care calendar says anything it is too late. The apps in this space lean on static care calendars and species lookups. In our informal comparison, none connected what the leaf looks like with the conditions that produced it, and none gave a source you could check.
The gap: a diagnosis that looks at your plant, factors in your local conditions, and recommends an action with a source attached, not a template.
Users
Plant enthusiasts and collectors, the people who own enough plants that one dying quietly in a corner is a real loss. Their job is to catch a problem early and know what to do about it.
What we heard came from informal conversations with plant owners (self-reported, not a study) and a side-by-side look at popular care apps. Three things changed the plan:
- The trust gap is a sourcing gap. People could not check why an app said what it said, so every recommendation read as a guess.
- Diagnosis has to be visual and local. A species lookup answers "what is this plant". The real question was "what is wrong with this one, here".
- Citations are the differentiator. None of the apps we compared showed a source.
Decision
The call that made the eval loop possible was keeping the orchestrator stateless, with persistence in Supabase (history, growth tracking) and R2 (images). The Worker is cheap to re-run and trivial to version, and the eval harness can replay any stored photo against a new model without touching user data.
Trade-offs
Three constraints were fixed before the first line of code.
- Latency. A diagnosis that arrives after the user has closed the app is worthless. Target: P95 under 10 s end to end, photo upload included.
- Cost ceiling. A two-person side project cannot carry idle server bills. Fixed infrastructure in single-digit dollars a month, per-user cost in cents.
- Auditability. An AI that prescribes treatment for a living thing has to show its sources.
What shipped
It starts with a photo.
Forensic Health Audit. Gemini 1.5 Pro reads the photo for pests, deficiencies and stress. In parallel, a web-search call pulls source links for the symptoms and species, and OpenWeather adds 7 days of local context. Back comes a health score from 1 to 100, a severity tier (Healthy, Warning or Critical) and an action plan with a source on each recommendation.
Growth Velocity Tracking. Over weeks of photo logs, pixel-based measurement tracks leaf expansion, stem elongation and internodal distance, and turns that into a verdict: thriving, stagnating or declining.
Pro-sumer Asset Management. For collectors with many plants, care actions can be batched by micro-climate zone, and exportable Health Certificates give a plant a record for peer-to-peer sales. This is the business bet, not a proven one.
The landing page at the top of this page positions Aarchid as a digital twin for plants and previews a diagnosis before sign-up.
Under the hoodArchitecture and implementation
The Edge Stack
Next.js PWA → Cloudflare Workers (Hono) orchestrator → Gemini 1.5 Pro (vision) + a web-search API (sources) + OpenWeather (environment) → Supabase (Postgres) + Cloudflare R2 (image storage).
Request flow
Image upload lands on R2. A single Worker fans out three parallel calls, Gemini vision, the web-search call and OpenWeather (7-day local context), then composes the response. The web-search call returns source links inline; the frontend renders them as a footnote trail.
// Simplified; provider names omitted
const [diagnosis, sources, weather] = await Promise.all([
vision.analyze({ image, prompt: DIAGNOSIS_PROMPT }),
research.search({ symptoms, species }),
weather.local({ lat, lon, days: 7 }),
]);
const report = composeReport({ diagnosis, sources, weather });
return c.json(report);
Eval harness
Because the Worker is stateless, the harness replays any stored photo against a new model or prompt and reports the accuracy delta, without touching user data.
Validation
Evidence here is self-reported. The team ran an offline eval on a golden set (about 200 samples across 12 failure modes, as reported by the team). The eval artefacts live in the private aarchid-rework repo, so the result is withheld here until the eval artefact or the co-builder's confirmation is available.
What an offline eval can and cannot tell you is the point of this section. It can tell you whether a prompt or model change helped or hurt on the cases you chose: every change re-runs the whole set and reports the delta. It cannot tell you whether a real plant owner, with their own photo and their own plant, gets a diagnosis they trust enough to act on.
- Live: aarchid.space returned HTTP 200 on 30 Sep 2026.
Limits and next
- Field accuracy is not measured. The only accuracy check is the team's offline golden-set eval, whose result is withheld here; nothing comes from live user photos, and there is no confirm-or-correct loop yet. Usage figures are not reported here.
- Next bet: a structured feedback loop. Users confirm or correct a diagnosis and the deltas feed back into the golden set. The harness exists; the pipe is the next PR.
- Open question: whether Health Certificates are the wedge we think they are. Whether sellers pay for provenance is not measured.
- What I'd do differently: build the correction loop alongside the harness. The 12 failure modes are the ones we chose; users will find the ones we did not.
Credits
Aarchid is a two-person side project, co-built with Dilpreet Grover (@dfordp). I owned product scope, the golden eval set and the citation-grounding requirement; platform engineering was shared.
The orchestrator and eval harness live in aarchid-rework, which is no longer public. The public aarchid-api repo holds the data-layer API only; it does not contain the diagnosis pipeline.
