HattaDev
Menu
Agritech

AgriConnect MY — Direct Farm-to-Restaurant Supply Platform

ClientAgriConnect MY
Year2025
Stack10 technologies
Scroll

Business Challenge

Malaysian vegetable farmers in Cameron Highlands typically sell through a chain of 3-4 middlemen before produce reaches restaurants — wholesalers, distributors, and market vendors. Each layer adds 15-25% markup. Farmers receive only 30-40% of the final restaurant price. Produce quality degrades through the multi-day distribution chain. Restaurants have no visibility into farm practices, harvest dates, or pesticide usage. A restaurant in KL was paying RM 12/kg for tomatoes that farmers sold for RM 3/kg.

## Solution Architecture

Solution Architecture

We built a B2B marketplace with Farmer App for listing available produce with harvest dates, pricing, and minimum order quantities. Restaurant App for browsing available produce, placing orders, tracking deliveries, and managing payment. Logistics Module for route optimization of farm-to-restaurant deliveries with temperature monitoring. Quality Assurance with farm certification verification, produce grading standards, and customer quality ratings.

## Key Features

Key Features

Direct marketplace with real-time produce availability, transparent farm-gate pricing, and order aggregation for delivery efficiency. Logistics optimization with temperature-controlled delivery routes from Cameron Highlands to urban centers within 12 hours of harvest. Quality traceability with farm certification, harvest date tracking, pesticide usage disclosure, and batch traceability. Payment system with digital invoicing, 7-day payment terms for restaurants, and immediate farmer payout upon delivery confirmation.

## Technology Stack

Technology Stack

Next.js frontend for farmer and restaurant dashboards. Node.js with Express.js backend. PostgreSQL with PostGIS for delivery route optimization. Redis for real-time inventory and order caching. Docker and Kubernetes on AWS. IoT integration for temperature monitoring during transport.

## Results

Results

Platform connects 200+ farmers with 350+ restaurants. Farmer income increased 60-80% by eliminating middlemen. Restaurant produce costs reduced 25-35%. Delivery time from harvest to kitchen reduced from 3-4 days to under 12 hours. Food waste reduced by 40% through demand-driven harvesting.

Technology Stack

Technologies Used

Next.jsNode.jsExpress.jsPostgreSQLPostGISRedisDockerKubernetesAWSIoT
More Work

Related Projects

Enterprise Software

Manufacturing ERP Platform — Enterprise Production Management

A cloud-native Enterprise Resource Planning system built for a multi-factory manufacturer producing 50,000+ SKUs across 8 production lines. The legacy system — a combination of Excel spreadsheets, disconnected Tally installations, and paper-based quality control — was causing production delays, inventory discrepancies, and financial reporting that lagged 2-3 weeks behind actual operations. ## Business Challenge The manufacturer operated 3 factories across Java with 2,000+ employees and a complex supply chain involving 300+ raw material suppliers. Each factory ran its own spreadsheet-based production schedule with no real-time visibility into material availability, work-in-progress status, or quality metrics. Procurement was reactive rather than planned, resulting in both stockouts stopping production lines and overstock tying up working capital. Financial consolidation required 5 accountants spending 10 days per month reconciling data from three separate systems. ## Solution Architecture We designed a modular ERP platform with bounded contexts for Production Planning, Inventory Management, Purchasing, Warehouse Management, Quality Control, Finance, and Executive Analytics. Each module operates as an independent service communicating through Apache Kafka for event-driven data synchronization. The system uses CQRS with PostgreSQL as the write store and Redis-powered read projections for real-time dashboards. The architecture enforces eventual consistency across modules while maintaining ACID transactions within each bounded context. ### Key Architecture Decisions **Event-Driven Integration:** All state changes are published as domain events (ProductionOrderCreated, InventoryReserved, QualityCheckPassed) to Kafka topics. Downstream services consume these events to maintain materialized views. This ensures loose coupling — the Quality Control module can be deployed independently without affecting Production Planning. **CQRS Pattern:** Write operations go through command handlers that validate business rules against the PostgreSQL write model. Read operations query denormalized Redis projections optimized for specific UI views — the production dashboard reads from a pre-computed projection updated in real-time via Kafka consumers, not from raw transactional tables. **Multi-Tenancy at Database Level:** Each factory operates within its own PostgreSQL schema, providing data isolation while sharing the same application infrastructure. Cross-factory reporting uses a dedicated analytics database populated through Kafka Connect. ## Key Features Production Planning with finite capacity scheduling considering machine availability, labor shifts, and material constraints. Inventory Management with real-time stock tracking across 8 warehouses using barcode scanning. Purchasing with automated purchase requisition generation based on reorder points and production schedules. Quality Control with inspection workflow, non-conformance tracking, and supplier quality scorecards. Finance with automated journal entries, multi-factory consolidation, and Indonesian tax compliance (e-Faktur integration). BI Dashboard with real-time OEE (Overall Equipment Effectiveness), production variance analysis, and cost-per-unit tracking. ## Technology Stack Frontend built with Next.js 15 App Router and React Server Components for island architecture — interactive dashboards render client-side while static reports use server components. Backend API layer built with NestJS following Clean Architecture with use cases, repositories, and domain entities. PostgreSQL 16 for write models with table partitioning for high-volume tables (production transactions, inventory movements). Redis Cluster for caching read projections and session management. Apache Kafka for event streaming between bounded contexts with exactly-once semantics. Docker containers orchestrated with Kubernetes on AWS EKS. Infrastructure as Code with Terraform managing VPC, RDS, ElastiCache, MSK, and EKS. ## Security Architecture Role-based access control with 12 permission roles mapped to factory-level and module-level scopes. JWT authentication with refresh token rotation. Audit logging on every state mutation with tamper-evident hashing. Data encryption at rest using AWS KMS and in transit using TLS 1.3. Network segmentation between application tier, database tier, and message broker tier using Kubernetes network policies and AWS security groups. ## Scalability Design The system is designed to handle 50,000+ production transactions per day with peak loads during shift changes. Horizontal Pod Autoscaling on Kubernetes scales API services based on CPU and custom metrics (Kafka consumer lag, request queue depth). Database read replicas serve analytics queries without impacting transactional performance. Redis Cluster shards read projections by factory ID for predictable scaling as new factories are added. ## DevOps Pipeline GitHub Actions CI/CD with automated testing (unit, integration, E2E), security scanning (Snyk, Trivy), and infrastructure validation (Terraform plan). Blue-green deployment on Kubernetes with health check gating and automated rollback on metric degradation. Centralized logging with OpenTelemetry, Loki, and Grafana. Prometheus monitoring with custom alerts for business metrics (production order backlog, inventory stockout risk). ## Results Production planning cycle reduced from 3 days to 4 hours. Inventory accuracy improved from 72% to 99.2%. Financial close time reduced from 10 days to 2 days. Supplier lead time variability reduced by 35% through data-driven purchasing. Overall equipment effectiveness improved from 68% to 84% through real-time monitoring and predictive maintenance triggers. The system now handles 50,000+ daily production transactions across 3 factories. ## Lessons Learned Event-driven architectures introduce eventual consistency that requires careful UI design — we implemented optimistic UI updates with WebSocket reconciliation for real-time dashboards. CQRS adds complexity in command-validation-read flows but pays off in query performance at scale. Multi-factory deployment requires rigorous tenant isolation testing — a schema migration that succeeds in Factory A may fail in Factory B due to data differences.

View Case Study
Artificial Intelligence

AI Customer Service Platform — Intelligent Support Automation

An AI-powered customer service platform built for a telecommunications company handling 500,000+ monthly customer interactions across WhatsApp, email, live chat, and phone. The legacy system relied on 200+ human agents using scripted responses with an average first-response time of 45 minutes and a resolution rate of only 62% on first contact. ## Business Challenge The telecom provider faced escalating support costs as their subscriber base grew to 10 million. Customer satisfaction scores were declining due to long wait times and inconsistent answers. Agents spent 60% of their time answering repetitive questions — billing inquiries, plan changes, network coverage checks — rather than solving complex problems. The knowledge base existed as 50+ PDF documents that agents searched manually. Multichannel support (WhatsApp, email, chat, phone) operated in silos with no unified customer context. ## Solution Architecture We built an AI Customer Service Platform using a Retrieval-Augmented Generation architecture. The core components include a knowledge ingestion pipeline that converts documents into vector embeddings stored in Qdrant, a RAG-based AI engine that retrieves relevant knowledge and generates contextual responses using OpenAI GPT-4o via the Sumopod provider, a human handoff system that escalates to agents when AI confidence drops below threshold, a multi-channel gateway that unifies conversations from WhatsApp Business API, email, and web chat into a single thread, and an analytics engine tracking resolution rates, response times, and customer satisfaction. ### AI Pipeline Architecture Documents (PDFs, FAQs, product specs) flow through an ingestion pipeline: text extraction → chunking (512-token segments with 64-token overlap) → embedding generation (text-embedding-3-large) → vector storage in Qdrant with metadata filters. At query time, the user message is embedded and used for hybrid search (dense + sparse) against Qdrant. Top 5 chunks are retrieved and inserted into a prompt template that includes conversation history, retrieved context, and system instructions defining the AI as a professional support agent. The LLM generates a response with confidence scoring. If confidence < 0.7, the conversation is escalated to a human agent with full context. ## Key Features AI Chatbot powered by GPT-4o with RAG for accurate, context-aware responses trained on company-specific knowledge. Knowledge Base management with versioned articles, automatic re-indexing on updates, and content quality scoring. Intelligent ticketing with automatic categorization using fine-tuned classifiers and priority assignment based on sentiment analysis. Human escalation with full conversation context transfer — agents see the AI conversation history, retrieved knowledge, and suggested responses. Multichannel support unified across WhatsApp, email, live chat, and phone with consistent AI responses. Analytics dashboard tracking containment rate, resolution time, CSAT, agent productivity, and topic clustering. ## Technology Stack Frontend built with Next.js and React for the agent dashboard and admin console. Python backend with FastAPI for the AI orchestration layer handling embedding generation, vector search, and LLM integration. OpenAI API for GPT-4o models with prompt caching optimization. Qdrant vector database for high-performance similarity search with quantization for memory efficiency. PostgreSQL for transactional data — tickets, users, conversations, knowledge articles. Redis for caching frequent queries, session state, and rate limiting. Docker containers with Kubernetes orchestration for horizontal scaling of AI workers. ## Security Customer PII is filtered before reaching the LLM — phone numbers, email addresses, and account numbers are masked with placeholder tokens. All API communication uses TLS 1.3. Knowledge base access is role-restricted. Conversation logs are encrypted at rest with AES-256. The system maintains SOC 2 Type II compliance with audit logging of every AI interaction. ## Results First-response time reduced from 45 minutes to under 30 seconds. Resolution rate on first contact improved from 62% to 85%. AI containment rate reached 72% — nearly three-quarters of inquiries handled without human intervention. Agent headcount reduced from 200 to 80 while handling 2x conversation volume. Customer satisfaction increased from 3.2 to 4.6 out of 5. Monthly support cost reduced by 60%. ## Lessons Learned RAG quality depends critically on knowledge base curation — poorly structured documents produce poor retrieval results. Investing in knowledge architecture upfront (hierarchical taxonomy, consistent formatting, regular reviews) yields compounding returns. AI confidence thresholds need continuous tuning — set too high, excessive escalation defeats the purpose; set too low, incorrect AI responses damage trust. Multichannel unification is the unsung hero — customers switching channels mid-conversation was a major pain point solved by the unified thread architecture.

View Case Study
Start Your Project

Ready to build your enterprise solution?

Discuss your software engineering needs with the HattaDev engineering team.

Start the Conversation

Free consultation. No commitment.