PROJECT: AI-Powered Crop & Plant Health Assistant (Production-Grade, Full Build)
CONTEXT Build a complete, production-quality, end-to-end web application in one pass — both frontend and backend fully implemented and working together — for farmers, agriculturists, and plant hobbyists to diagnose plant/crop health from a photo. Primary users are in India with mixed digital literacy, so the UI must be simple, visual, and mobile-first. Support Hindi and English at launch, but design the localization layer so additional languages can be added later without re-architecting anything.
SCOPE FOR THIS BUILD This is not a prototype or a wireframe — build the real thing: working frontend, working backend, database schema applied, API integration wired up end-to-end, so I can run it locally and actually use it today. Plan the architecture first (briefly), then build everything in one continuous pass — don't stop after the plan and wait for approval unless something is genuinely blocking.
CORE USER FLOW
- User opens the app (mobile web, works on low-end Android phones / weak internet).
- User selects language — Hindi or English — this persists across the session (store as a language code so more languages can be added later as a config change, not a code change).
- User uploads or captures a photo of a plant/crop/tree (leaf, stem, fruit, or whole plant).
- System analyzes the image and returns, in the user's chosen language: a. Crop/plant identification (name, and common regional name if known) b. Health status (healthy / diseased / pest-infested / nutrient deficiency) c. If unhealthy: disease/pest name, confidence level, visual symptoms matched d. Actionable treatment steps (organic + chemical options, dosage, timing) e. Preventive care tips going forward f. Sowing season guidance for that crop (best months, soil/climate notes) g. Expected harvest window from sowing, and how to tell it's ready
- User can save results to a history log (per plant/crop) to track over time.
- Optional: text-to-speech playback of results for low-literacy users.
FUNCTIONAL REQUIREMENTS
- Image upload via camera or gallery, with client-side compression before upload.
- Use the Claude API's vision capability (multimodal message: image + text) as the core analysis engine.
- Force Claude to return strict JSON: crop_name, health_status, disease_name, confidence, symptoms_observed, treatment_organic, treatment_chemical, prevention_tips, sowing_window, harvest_window, harvest_readiness_signs. Generate this base analysis in English internally for consistency.
- Localization layer: a separate step/prompt that takes the structured English result and produces natural, farmer-appropriate Hindi (correct agricultural terminology, not stiff machine translation) when Hindi is selected. Structure this as a pluggable function keyed by language code, so adding a third language later means adding one more localization prompt, not touching the pipeline.
- Handle ambiguous/blurry images gracefully — ask the user to retake the photo with a clear, translated reason (poor lighting, too far, out of focus, etc.). Never hallucinate a diagnosis on unclear input.
- History/dashboard: past scans per user, viewable and searchable by crop or date.
- Auth: phone number + OTP flow (mock/stub the OTP provider for local dev, but structure it so swapping in a real provider like MSG91/Twilio is a config change).
- Basic offline tolerance: if upload fails due to network drop, queue and retry automatically with a visible status indicator.
NON-FUNCTIONAL REQUIREMENTS
- Mobile-first, responsive, performs acceptably on 3G/patchy connections (compressed assets, lazy loading, skeleton loaders).
- Accessibility: large tap targets, high-contrast option, icons paired with text (not text-only) for low-literacy users, voice narration option.
- Loading state during analysis (5-15 sec) with reassuring, localized micro-copy.
- Encrypt stored images/health data at rest; don't retain data longer than needed unless the user opts into keeping history.
- Backend should handle traffic bursts gracefully (e.g., basic rate limiting, queuing for the vision API calls).
TECH STACK
- Frontend: React (PWA-installable, so it behaves like an app on rural Android phones without needing an app store)
- Backend: Node.js/Express or Python/FastAPI — pick one and justify briefly
- Database: PostgreSQL for structured data, S3-compatible storage for images
- AI: Anthropic Claude API (vision + text) for diagnosis and localization
- Auth: Phone OTP, stubbed provider for local dev
- Deployment: Dockerized, so it can run locally with docker-compose and deploy to any standard cloud later
DELIVERABLES
- A short architecture overview (how the vision pipeline and localization layer work, why this stack).
- Database schema (users, scans, crops reference table, history) with migrations.
- The actual Claude API prompt templates: one for structured diagnosis (English), one for localization (Hindi), including the exact JSON schema enforced.
- Full working frontend: language selector, image capture/upload screen, results screen (with icons, not just text blocks), history screen, TTS playback control. Should feel like a real consumer product.
- Full working backend: image upload endpoint, Claude API integration (diagnosis
- localization), auth endpoints (OTP request/verify), history CRUD endpoints.
- docker-compose setup so I can run frontend + backend + database locally with one command.
- README covering setup, required environment variables (including where my Anthropic API key goes), and how to run and test it locally.
- Explicitly call out anything that's stubbed/mocked for local dev vs. what needs a real credential/service before going to production (OTP provider, cloud storage bucket, etc.).
QUALITY BAR Build this as if real users will use it tomorrow: proper error handling, empty states, loading states, and warm, clear copy — not robotic placeholder text. The Hindi experience should read naturally to a native speaker with correct farming vocabulary, not translated UI labels bolted onto an English app.
Do the planning yourself and proceed straight to building. Only ask me a clarifying question if something is truly blocking (e.g., you need a real external credential you don't have) — otherwise make sensible production-grade decisions, note them, and keep going.