The full story
The challenge
Make.com is a capable platform and the visual approach to building automations genuinely suits certain teams and certain problems. Harbour Commerce Group used it well in the beginning. Three e-commerce brands, one small operations team, and a tool that let non-developers wire together Shopify, supplier systems, a warehouse platform, and a customer communication tool without needing a developer on hand.
For eighteen months it held together. Then the trading volumes grew.
The first sign of trouble came during a sale period. Scenarios that ran reliably at normal volume started failing under the load of a busy trading day. Make.com’s plan limits operations per month, and the scenarios built for three brands in parallel were consuming that quota faster than anticipated. When a scenario hit its limit mid-run, it stopped. Orders that were mid-process were left in an incomplete state.
The operations team spent two days after the sale manually reconciling which orders had been processed correctly and which needed intervention. That two days came directly out of the time the team needed for everything else.
The second issue was complexity. The scenarios had been built incrementally to reflect how each brand operated. Brand one had different supplier lead times. Brand two had a returns workflow that differed from the others. Brand three had a wholesale channel alongside retail that needed separate routing. The attempts to handle all of this inside Make.com had produced scenarios that were difficult to read and harder to change. A modification to one brand’s logic risked affecting another because the scenarios shared modules in ways that had made sense at the time and caused confusion later.
The operations manager was reluctant to change anything without testing it extensively first, and testing a Make.com scenario properly was not straightforward.
The solution
We took time to understand how each brand actually operated before proposing anything. The differences between them mattered and needed to be preserved. A single unified system that averaged out the three brands would have created new problems.
We built a custom automation platform that handled order routing, inventory updates, and supplier communications across all three brands from a single underlying codebase. Each brand has its own configuration. The logic that is shared, such as the structure of a supplier notification or the trigger points for a low-stock alert, runs once and applies to all three. The logic that is brand-specific is separated clearly so that changing it for one brand cannot affect the others.
Operation count is not a concept in a custom-built system. The automation runs as many times as the business requires without a quota ceiling. During peak periods it processes the full order volume. Under quiet conditions it waits. There is no plan tier involved.
We paid particular attention to failure handling. Every step is logged. If an order cannot be processed for a legitimate reason, such as a supplier system being unavailable, the automation retries at intervals and alerts the operations team if it cannot resolve after a defined period. Nothing fails silently. Nothing is left in an unknown state.
The operations team have a simple interface for adjusting the configuration items that change regularly: supplier lead times, communication templates, routing rules by brand. The code underneath does not need to be touched for the changes that happen day to day.
The result
The first peak trading period after go-live passed without a single scenario failure. The operations team processed the highest single-day order volume in the company’s history and spent no time on reconciliation afterwards.
Managing three brands from one system with clear separation between them made the operation easier to understand and easier to change. When brand two updated its returns policy, the change took twenty minutes to implement and did not require checking whether it affected brand one or brand three.
The Make.com subscription was cancelled. The cost became a fixed build investment rather than a variable monthly fee that grew with order volume.
The operations manager’s summary was direct. They had spent eighteen months working around the limits of a tool. The replacement was built to fit the problem rather than expecting the problem to fit the tool.
Make.com is the right answer for straightforward automations at manageable volumes. When the complexity, the volume, or the reliability requirements grow past that point, a custom build pays for itself quickly.
If your automation platform is struggling to keep up with how your business actually runs, we should talk.
What changed
After go-live, the shift showed up in the week first. Then it showed up in the numbers. Here is what that looked like on the ground.
with no scenario failures during their busiest trading period
with consistent logic and shared configuration
replaced by a fixed-cost custom build
How we approached this