I led the project from discovery to production, working directly with business stakeholders and a two person engineering team.

I was the Lead Software Engineer & Architect, responsible for user discovery, product decisions, UX, system design, implementation, deployment, and ongoing operations.

The engineering team consisted of two people: myself and one junior engineer.

The project evolved from 2022 to 2025 as the business moved from fragmented legacy systems toward one shared operational platform.

A growing distribution business was being held together by a fragmented operational system.

For more than a decade, PT Sinergi Sukses Mobilindo had operated as an official Samsung and Xiaomi distributor, supplying businesses across Indonesia.

Its operations had grown around a collection of systems supporting inventory, purchasing, sales, finance, reporting, and partner management.

As the business grew, those systems became increasingly difficult to keep consistent. Different branches relied on separate databases and workflows, while important operational work still depended on manual processes.

The challenge was not simply to replace an old ERP.

It was to create one system the business could rely on as its operations continued to grow.

Years of growth had turned useful workflows into operational constraints.

The existing system had evolved alongside the business for years. Each branch operated with its own desktop application and local database, creating fragmented data and workflows that were difficult to keep consistent.

But replacing the software alone would not solve the problem.

People had built habits around the system. They knew which fields to fill, which shortcuts to use, how to navigate tables, where to intervene manually, and how to work around its limitations.

Some of those behaviors made people productive. Others exposed deeper problems.

A completed transaction, for example, could be edited directly at the source. It was convenient, but changing historical transactions could leave inventory and accounting records inconsistent.

The new system therefore could not simply reproduce the old workflows in a new interface.

It had to preserve the knowledge that made the business work, while removing the constraints and risks that had accumulated around it.

I did not want to rebuild the legacy system. I wanted to preserve what made the business productive and remove what held it back.

I started by understanding how people actually worked: keyboard driven navigation, direct table filtering, familiar forms, and the shortcuts they relied on every day.

Those behaviors were not problems simply because they came from a legacy system. Where they supported productivity, they were worth preserving.

I challenged the parts that created unnecessary work or exposed the business to risk. Manual payment reconciliation, disconnected workflows, and unrestricted editing of completed transactions were examples where familiarity had started to outweigh value.

Completed transactions therefore needed controlled correction rather than unrestricted editing, protecting the consistency between operational, inventory, and accounting records.

The principle was simple: preserve the knowledge, remove the friction, and protect the integrity of the system.

One system, with clear boundaries around the work that mattered.

The system was organized around the way the business actually operated: operations, inventory, finance, and the shared relationships connecting them.

Operations handled purchasing, sales, and returns. Inventory tracked the physical movement of products, including serial-level traceability, across multiple warehouses and operational locations. Finance handled invoices, payments, vendor bills, credits, journals, and financial reporting.

Customers, vendors, users, roles, and permissions formed the shared foundation across those domains.

I designed the financial workflows around controlled journal generation, general and subledger posting, and strict chart of accounts enforcement, so operational activity could flow into accounting without relying on manual interpretation.

These boundaries were not created for architectural elegance.

They gave complexity somewhere to live.

A problem in inventory could be reasoned about within its own domain while still accounting for its effect on operations and finance. A new requirement had a clearer place to belong without forcing unrelated parts of the system to change.

The result was a system structured around the relationships the business actually needed to manage.

The highest value came from removing repeated operational work.

Once the core workflows were working, the focus shifted from replacing the old system to creating leverage.

Payment reconciliation was one of the clearest opportunities. BCA Virtual Account integration allowed the system to match customer payments to transactions automatically, reducing repetitive work for finance while giving customers a simpler way to pay.

Other improvements targeted recurring gaps across the operation: multi invoice payments, purchasing and sales returns, automated e-Faktur generation, and cross module reporting.

The principle was not to automate because automation was technically interesting.

It was to remove friction from work that happened often enough to matter.

That same principle shaped smaller improvements such as approval notifications, delivery reminders, and low stock and overdue invoice indicators.

Individually, these changes were small. Together, they made the system easier to operate every day.

The business gained a system that could keep up with the complexity it had already earned.

Distributed operations were brought into one shared environment, giving the business a more consistent source of operational and financial data.

Inventory could be tracked down to the serial level. Financial workflows became more structured and less dependent on manual reconciliation. Payments could be matched automatically, tax reporting could be generated from the system, and information across modules could be connected through shared reporting.

The system now supported thousands of daily transactions across billions of rupiah in monthly transaction volume, while automation removed hundreds of operational hours of repetitive work each month.

The impact was operational as much as technical.

The business did not have to simplify its operations to fit the software. The system gave those operations a more coherent foundation to grow on.

Complex systems become difficult when reasonable decisions start working against each other.

A workflow that makes sense for operations can create problems for finance. A convenient shortcut can undermine data integrity. A feature that helps one team can create friction somewhere else.

The answer is not to eliminate complexity.

It is to make the important relationships explicit, decide where the boundaries belong, and build a system that can absorb change without becoming harder to understand.

That meant listening before redesigning, preserving useful knowledge instead of blindly replacing it, and being deliberate about what the system should allow.

The result was not just a new ERP.

It was a clearer model of how the business operates, expressed through a system designed around that understanding.