Custom Software Full case study

Retail Operations Management System (Multi-Outlet)

BK Team Sdn Bhd Retail operations · Malaysia

"Managing 30+ retail outlets manually — no real-time stock visibility, no centralised sales tracking, and no HQ control over outlet pricing."

30+

Outlets unified

5 mo

SRS to go-live

100%

Offline-capable POS

OPEX

Engagement model

Technology stack

Flutter Desktop

POS client — offline-first

SQLite

Local database — POS device

Java Spring Boot

REST API — backend logic

Nuxt.js

HQ web portal — SSR

MySQL

Centralised database — HQ

The challenge

30+ retail outlets. No centralised visibility. Every day felt like guesswork.

BK Team Sdn Bhd operates 30+ retail outlets across Malaysia. Before this project, every outlet ran independently — stock counts were done manually, sales figures were compiled at end of day through WhatsApp messages, and pricing updates had to be communicated by phone to each outlet manager individually. There was no single source of truth for anything.

The problems this created were compounding. Stock discrepancies went undetected for days — by the time HQ noticed an outlet was running low, it had already lost sales. Pricing inconsistencies were common — outlet managers would apply their own discretion when they couldn't reach HQ for approval, and there was no audit trail. And every Monday morning, the operations director was consolidating the previous week's sales from 30+ separate Excel files sent by outlet managers.

Off-the-shelf retail management software wasn't solving it. The available options were either too generic for their specific multi-outlet structure, too expensive to licence across 30+ locations, or required continuous internet connectivity — a problem for outlets in areas with unreliable mobile data. What they needed wasn't a product. It was a system designed around how their business actually worked.

Our approach

We started with the SRS. Not the code.

Before a single line of code was written, we conducted a full requirements study — interviewing HQ management, outlet managers, and floor staff. We mapped every workflow, identified every edge case, and produced a complete System Requirements Specification that both sides signed off. The SRS became the project's reference point for every decision that followed.

Inventory & Stock Control

Centralised stock visibility across 30+ retail outlets — real-time tracking, warehouse-to-outlet transfer management, automatic deductions on sale, and low-stock alerts with replenishment support.

Stock balanceGRN receivingTransferStock count

Sales & POS Tracking

Real-time sales synchronisation from all outlets to HQ, with a daily manager closing workflow — daily close submission, manager login verification, and automatic EOD reporting to HQ.

POS transactionsSales dashboardManager close

Pricing Management

HQ-controlled pricing with global, area, and outlet-level configuration. Branch managers can submit price change requests — HQ reviews and approves before any change takes effect. Full audit log on every change.

Global pricingApproval workflowAudit trail

Reporting & Analytics Dashboard

Centralised real-time dashboard for HQ — sales performance analytics, inventory movement insights, outlet comparisons, and on-demand PDF report generation across any date range and outlet combination.

Real-timePDF exportMulti-outlet

How we delivered it

Requirements study

Stakeholder interviews · Workflow mapping · SRS

System design

Architecture · Database design · UI wireframes

Development

Milestone-based · Regular demos · Client checkpoints

UAT

Client testing · Bug fixing · Sign-off per milestone

Go-live

Deployment · Staff training · Stabilisation support

The architecture decision

Offline-first by design. Not as an afterthought.

The single most important technical decision in this project was the choice to build the POS as an offline-first application. Outlets in Malaysia operate in varying connectivity conditions — some locations have reliable broadband, others depend on mobile data that drops during peak hours.

We designed the Flutter Desktop POS to operate entirely from a local SQLite database during the shift. Sales transactions, stock deductions, price overrides, and GRN receipts are all written locally first. At shift open, the POS pulls the latest data from the server — products, prices, stock balances. At shift close, it pushes all the day's activity back up — transactions, deductions, overrides, manager close report.

This means a full shift of operations can run without a single API call. No connectivity, no problem. The sync architecture handles conflict resolution deterministically — stock deductions are additive across outlets, HQ pricing always wins on sync, and transfer records are matched by GRN pair. Nothing is silently dropped.

System architecture

POS Client

Flutter Desktop + SQLite · offline-first

↕

Sync Engine

Open shift pull · Close shift push

↕

REST API

Java Spring Boot · JWT auth · business logic

↕

MySQL + HQ Portal

Centralised DB · Nuxt.js SSR dashboard

No live internet required during shift operations

The outcome

One system. 30+ outlets.
Full visibility from day one.

30+

Retail outlets unified under one platform

Every outlet now operates from the same system — the same product catalogue, the same pricing, the same reporting structure. HQ has real-time visibility across 30+ locations from a single dashboard.

5 mo

From SRS sign-off to live deployment

Requirements study, full system design, development across 5 modules, UAT, staff training, and go-live — completed within the agreed timeline and scope, with no unplanned cost additions.

100%

Offline capability — no live internet needed

The Flutter POS operates entirely offline during shifts. Syncs at open and close. Outlets with unreliable connectivity now run exactly the same as outlets with fibre — the system doesn't discriminate by location.

OPEX

Structured as managed service — maximising Year 1 tax deductibility

The project was structured as a fully managed digitalisation service — 100% tax deductible as operating expense in Year 1 versus approximately 40% under a standard CAPEX purchase. Significant tax saving on the same project value.

Trendtive Digital didn't just build what we asked for — they challenged our thinking on several design decisions and delivered something more robust than we imagined. The SRS process alone was worth the engagement. We now have full visibility across 30+ outlets from one screen, and our Monday morning report runs itself.

Anson Kong

Director, BK Team Sdn Bhd

Start a project

Have a similar challenge? Let's talk.

Book a free 30-minute consultation with Jack. We'll tell you honestly whether your project is a fit for what we do — and what a realistic build would look like for your specific operation.

Jack Chang

Director, Trendtive Digital Sdn Bhd

Your consultant for this session

30 minutes · Free · No obligation

Format: Microsoft Teams

With: Jack Chang, Project Director — Trendtive Digital

What we'll cover

Your business operations and the specific challenge you're trying to solve

Whether your project is a fit — and which service approach applies

Realistic scope, timeline, and CAPEX or OPEX engagement model

No credit card · No commitment · Response within 24 hours