HattaDev
Menu
Foodtech & Operations SaaS

KateringKu — Kitchen Management & Inventory System

ClientKateringKu
Year2025
Stack7 technologies
Scroll

Business Challenge

Indonesian catering businesses operate on thin margins with high sensitivity to ingredient cost fluctuations. Most home-scale caterers (serving 20-100 meals/day) manage orders via WhatsApp messages, track inventory in paper notebooks, and calculate costs using mental arithmetic. This leads to over-ordering of perishable ingredients, underpriced menu items, and missed orders due to communication gaps. One caterer we worked with was losing 15% of monthly revenue to unaccounted costs.

## Solution Architecture

Solution Architecture

We built a mobile-first web application designed for kitchen-table use. The core modules include Inventory Management with real-time stock tracking, automated low-stock alerts, and purchase list generation based on upcoming orders. Order Management with customer database, recurring order scheduling, and automated WhatsApp confirmation messages. Production Planning generating prep lists and cooking schedules based on order volume. Cost Calculation tracking per-recipe ingredient costs with automatic margin calculation when ingredient prices change.

## Key Features

Key Features

Inventory tracking with barcode scanning and expiry date management. Order management with WhatsApp Business API integration for automated confirmations. Production planning with automated prep lists and cooking schedules. Cost calculation with per-recipe margin analysis and ingredient price fluctuation alerts. Delivery coordination with route planning for multiple daily deliveries. Customer management with order history, preferences, and dietary restrictions.

## Technology Stack

Technology Stack

Next.js PWA for mobile-first progressive web app with offline support. Node.js with Express.js backend. PostgreSQL for transactional data. Redis for caching and session management. WhatsApp Business API integration. Docker containers on a VPS with automated backups.

## Results

Results

Food waste reduced by 35% through demand-driven purchasing. Revenue increased 25% through accurate cost-based pricing. Order errors reduced by 90% moving from WhatsApp to structured order management. Administrative time reduced from 3 hours/day to 30 minutes/day. Platform adopted by 150+ catering businesses across Jabodetabek.

Technology Stack

Technologies Used

Next.jsNode.jsExpress.jsPostgreSQLRedisWhatsApp APIDocker
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.