Dexova — Integrated ERP Platform

Context

Dexova is an ERP platform for Indonesian businesses — built for small and mid-size companies that need serious operational software without enterprise pricing. I built it as the architect and full-stack developer, from database schema design to the cashier UI.

The product is live at dexova.id and is used through three production applications: an admin dashboard (dex-fe), an employee attendance PWA (dex-attendance), and a cashier app (dex-pos).

Business problem

SMEs run HR, payroll, cashier, and stock in separate tools: attendance in spreadsheets, salaries computed by hand, a standalone cashier app, stock in warehouse notebooks. The data never reconciles — overtime hours don't reach the payslip, sales don't decrement stock, and owners can't see the business across divisions.

The consequences are real: payroll mistakes (with labor-compliance risk attached), unexplained cash differences, and business decisions made from stale data.

Product ecosystem

Four business modules run on one Go backend — each owning its own SQL queries and migrations, so modules evolve without breaking each other:

• HRIS & Payroll — the full employee lifecycle: employee data, org structure, attendance, leave, shifts, payroll runs, and digital payslips.
• Attendance (employee PWA) — geofenced check-in/out with nearest-office detection, attendance history, correction requests, leave, and payslips.
• POS — multi-outlet cashier with barcode scanning, multi-payment (cash, Midtrans QRIS, transfer, EDC, split), shift + cash reconciliation, and sales reports.
• Inventory — multi-warehouse: purchase orders, goods receipt with QC, barcode stock opname, approval-gated transfers, and automatic sync with POS.
• Dexova AI — an AI layer (OpenAI / Google AI) over operational data for search and insight.

My role

Architect & full-stack developer — backend-heavy. I designed the modular-monolith architecture, wrote the domain logic (payroll, cash reconciliation, stock), built all three frontend applications, and operate the deployment. Product decisions and feature priorities were mine too, so every technical decision on this page is also a product decision.

Technical challenges

• Multi-tenant from the foundation — tenant scoping is enforced in tokens (PASETO) and middleware on every query, with AES-256-GCM encryption for sensitive data (plus encryption-migration tooling for schema changes).
• Regulation-aware payroll — tiered overtime following Indonesia's PP 35/2021, income tax (PPh 21), social security (BPJS), pro-rata, and paydays that shift automatically on bank holidays. Implemented as tested business rules, not hardcoded branches.
• Strict module boundaries — four modules in one Go codebase, each with its own controller → service → repository layering and a single DI composition root. Adding a module never tears up an old one.
• Real-time without overengineering — Server-Sent Events for dashboard updates and PWA notifications; heavy work (bulk Excel import, exports, payroll runs) runs as async jobs, plus an outbox pattern for provisioning that must never be lost.
• Payment integration — Midtrans QRIS (static & dynamic) in the cashier flow, reconciled at the shift level.

Architecture & engineering decisions

A modular monolith, not microservices: one Go (Gin) binary with four clearly-bounded modules is far cheaper to operate at this scale — and the module boundaries keep extraction into separate services on the table if it's ever needed.

• Go + PostgreSQL (sqlc) — generated, type-safe queries instead of an ORM; each module owns its migrations.
• Redis for caching, sessions, and rate-limiting; 12+ in-process schedulers (payroll auto-lock, approval escalation, audit purge) plus an outbox worker.
• SSE for real-time updates; a gRPC client integration to the workshop service; WebSocket for POS stock sync.
• Cookie-based PASETO auth; AES-256-GCM encryption for sensitive data + application-level multi-tenant isolation.
• Frontends: Next.js/TypeScript for the admin dashboard, a PWA for employee attendance, and a separate cashier app.

UI

All screenshots use demo data.

Outcome

• Four business modules (HRIS, Payroll, POS, Inventory) in production on one modular Go codebase.
• Three applications used by real users: the admin dashboard, the employee attendance PWA, and the cashier app.
• Employees got a self-service portal (attendance, payslips, leave, shifts) — manual HR processes became self-serve.
• The module boundaries proved out: new modules were added without breaking existing ones.