HattaDev
Menu
Services Marketplace

RuangTukang — Home Services Marketplace for Developing Cities

ClientRuangTukang
Year2026
Stack9 technologies
Scroll

Business Challenge

In developing cities outside Jakarta, finding a reliable technician for home repairs is a major pain point. Homeowners rely on personal recommendations or random roadside workshops with no quality guarantees. Technicians lose productive hours traveling between scattered jobs with no route optimization. Payment disputes are common due to unclear pricing. The market is fragmented with no dominant platform serving tier-2 and tier-3 Indonesian cities.

## Solution Architecture

Solution Architecture

We built a two-sided marketplace with mobile apps for both customers and technicians. The platform includes Customer App for service discovery, booking, real-time technician tracking, and digital payment. Technician App for job acceptance, route optimization, digital invoicing, and earnings dashboard. Admin Dashboard for technician verification, quality monitoring, dispute resolution, and business analytics.

### Matching Algorithm

The core innovation is a technician-customer matching algorithm that considers technician skills, current location, route efficiency, customer ratings, and historical job completion rates. The algorithm clusters jobs geographically to minimize technician travel time — a critical factor in cities with unpredictable traffic patterns.

## Key Features

Key Features

Service discovery with categorized services, transparent pricing, and technician profiles with verified credentials and ratings. Real-time booking with instant availability checking, estimated arrival time, and live GPS tracking. Digital payment with in-app invoicing, multiple payment methods (bank transfer, e-wallet), and automatic receipt generation. Quality assurance with mandatory job completion photos, customer rating system, and satisfaction guarantee with dispute resolution. Technician tools with route optimization, earnings dashboard, and skill certification management.

## Technology Stack

Technology Stack

React Native for cross-platform mobile apps (iOS and Android). Go backend for high-performance matching algorithm and real-time location processing. Next.js for admin dashboard. PostgreSQL with PostGIS for geospatial queries. Redis for real-time technician location caching and session management. Docker and Kubernetes on AWS.

## Results

Results

Platform operational in 5 cities with 2,000+ verified technicians. Average technician response time of 45 minutes (vs 4+ hours via traditional channels). Customer satisfaction of 4.7/5. Technician earnings increased 40% through route optimization and reduced idle time. Monthly transaction volume grew 25% month-over-month.

Technology Stack

Technologies Used

React NativeGoNext.jsPostgreSQLPostGISRedisDockerKubernetesAWS
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.