The client's merchants, the businesses using the platform to ship orders across Australia, Singapore, the US, and Dubai depended on dashboards that had been built on aging technology. The codebase was server-rendered, heavily duplicated, and slow to change. Adding a feature required navigating code that had grown without clear structure. End-to-end testing of new features was difficult. Releases were infrequent.

The organization wanted to revamp the UI, improve the merchant and developer experience, and add new features at a pace the old system could not support. Some features that had been released received enough negative feedback to be pulled back entirely the process for iterating on them was too slow to recover quickly.

‍

Technogise structured the work around three squads, each owning a distinct part of the merchant journey.

The Flow squad owned the order lifecycle from when a merchant places an order through to tracking. They built React-based frontends and the APIs merchants used to integrate with the platform.

The Shipping squad handled carrier assignment: selecting the right delivery partner based on product type, urgency, documents required, and destination. Merchants could also bring in their own preferred carriers.

The Carrier squad managed tracking integration between delivery partners and the platform, ensuring end users could see the same shipment status information regardless of which carrier was handling their order.

This structure gave each squad clear ownership and the ability to move independently, without waiting for each other or creating conflicts in a shared codebase.

‍

New features were never switched on for all merchants simultaneously. They were enabled for a subset first with merchants notified in advance and asked for permission to test new functionality without affecting their live operations. If the reaction was positive, the rollout continued. If feedback was negative, the feature was disabled while the team iterated.

This made the earlier pattern of pulling back widely-released features unnecessary. Problems were caught at small scale, not after the entire merchant base had been disrupted.

Within two months, the entire software platform had been replaced. The pace of change was not the result of cutting corners, it was what became possible once the architecture supported change instead of resisting it.

An MVP was delivered in three weeks. The full platform replacement took two months. Build time dropped by approximately 50% through isolating the frontend from the monolith and creating a shared UI component library. New features could be deployed every week a frequency that had previously required at minimum a two-week sprint and manual testing.

85% of merchants were on the new experience. New signups received it by default. Existing merchants opted in. The improved dashboards gave merchants better data for order decisions and simplified the management of their warehouse operations.