KiloPOS — Point of Sale for Cafés & Restaurants
A point-of-sale system for cafés and restaurants, designed for tablets and phones and comfortable on desktop too. It covers the full counter-to-kitchen flow: ordering, tables and open bills, cash and digital payments (QRIS, e-wallets, virtual accounts via Midtrans), kitchen and receipt printing, shifts, stock and reports. Built with Next.js, TypeScript and PostgreSQL.

Overview
KiloPOS is a point-of-sale system for cafés and restaurants in Indonesia. It is designed first for tablets and phones, because that is what a counter or a waiter actually holds, and it stays comfortable on a desktop. It runs on an outlet's own server or a VPS with a PostgreSQL database, and the interface and documentation are in Indonesian. The goal was a complete F&B workflow in one product: take an order, send it to the kitchen, split the bill, accept payment, close the shift and read the numbers at the end of the day. It is at version 1.0.0.
Key features
- Cashier screen with a step-by-step new order flow, barcode scanning, saved orders and a practice mode. Restaurant tools include a table map, open bills, moving and merging tables, splitting the bill and partial payments.
- Menu with variants, modifiers, photos, schedules and sold-out switches, plus tax, service charge, vouchers and promotions.
- Payments by cash, card and Midtrans (QRIS, GoPay, ShopeePay, bank virtual accounts), with a demo mode for trying it without real money.
- Receipt and kitchen ticket printing to LAN printers with a retry queue, shifts with blind cash counts, stock tracking, and sales reports with CSV export and an end-of-day Z-report.
How it is built
A TypeScript monorepo with pnpm and Turborepo. The main app uses Next.js and React for the cashier screens, back office and API, with shared packages for a design system, core business logic (money, tax, rounding), security, and the database schema using Drizzle ORM on PostgreSQL. It installs as a PWA on tablets and deploys with Docker. Money is always whole rupiah, every order total is calculated on the server by one pricing function, and digital payments are only marked paid after a signature-checked notification from the provider. A load test of 30 tablets placing 20 orders each (600 orders in about 13 seconds) also caught and fixed a real freeze that happened when many tablets paid at once.
What this project demonstrates
A product built with the correctness a till needs: totals must be right, payments must never double-charge, and a busy shift must not stall. It also shows end-to-end ownership, from schema, security and payment integration to printing, deployment and guides for cashiers, managers and owners.
.webp%3Fv%3D1792961855816&w=640&q=75)
.webp%3Fv%3D1792961862087&w=640&q=75)
.webp%3Fv%3D1792961867297&w=640&q=75)








.webp%3Fv%3D1792570478588&w=640&q=75)