Owner dashboard
Outlet readiness and operational KPIs separate sales, received cash, receivables, appointments, work orders, rentals, and expenses.
Back to projects
- SaaS · Point of Sale
- 2026
Case study · 01 / 08
Dagangin POS
One operational engine for multiple SME business models.
A multi-tenant, multi-outlet POS platform combining checkout, inventory, appointments, work orders, rentals, reporting, and platform controls in one modular architecture.
- My role
- Product Engineer · Full-stack · System Design
- Status
- Active development
Key achievement
Designed one POS engine for nine SME business models, so no new app has to be built for each type of business.
Private product repository
01 · Context
The problem this project solves.
Primary users
- Multi-outlet SME owners
- Cashiers and operations staff
- Platform operators
The problem
SME cashier applications are often rebuilt for every business type. Features quickly sprawl, business rules get duplicated, and data consistency across outlets becomes difficult to protect.
The approach
Dagangin uses business profiles as presets and capabilities as configuration. Retail, food service, services, wholesale, rental, and hybrid businesses continue to run on the same API and business rules.
Key numbers
02 · My role
What I worked on.
Product Engineer · Full-stack · System Design
Technology used
- Laravel 12
- React
- TypeScript
- Flutter
- MySQL
- Redis
- Docker
- Nginx
- 01
Designed a multi-tenant, multi-outlet architecture with layered data isolation.
- 02
Built a capability system that drives both the interface and backend validation for each business model.
- 03
Built an Android cashier with an offline queue that prevents duplicate transactions.
- 04
Separated the platform control plane from tenant workspaces, including accounts, permissions, and audit.
03 · Highlights
A few selected screens.
Click an image to view it larger.
Swipe through them all, tap an image to enlarge it.
01 / 04
Owner dashboard
Outlet readiness and operational KPIs separate sales, received cash, receivables, appointments, work orders, rentals, and expenses.
Checkout across business models
The transaction flow adapts to active capabilities: variants, modifiers, tables, price tiers, customers, payments, and receipt printing.
Inventory per outlet
Stock, transfers, counts, purchasing, and movement ledgers remain separated by tenant and location.
Operational reporting
Reports distinguish revenue, money actually received, receivables, and unsettled payments.
04 · Challenges & decisions
Technical problems and how I solved them.
01 / 03
05 · Outcome
What the solution delivers.
The architecture lets the product expand across verticals without rebuilding from zero while preserving tenant, role, outlet, and audit-trail isolation.
User flow
- 01Register tenant
- 02Choose business profile
- 03Enable capabilities
- 04Prepare outlets and catalog
- 05Open cash session
- 06Process orders and payments
- 07Review ledgers and reports
Architecture
Clients
Admin web · Cashier PWA · Flutter Android · Platform web
Application
REST API · RBAC · tenant context · domain services · events
Data
MySQL shared tenant data · Redis queue/cache · private object storage
Runtime
Nginx · PHP-FPM · worker · scheduler · Docker Compose
Data model
Tenant
id
business_profile
capabilities
Outlet
tenant_id
name
timezone
User & Role
tenant_id
role_id
permissions
Product
tenant_id
sku
type
unit
Order
outlet_id
customer_id
status
total
Payment
order_id
method
amount
status
Stock Ledger
product_id
outlet_id
direction
qty
- Tenant 1—N Outlet
- Tenant 1—N User / Product
- Outlet 1—N Order
- Order 1—N Payment
- Product 1—N Stock Ledger
