How hipages Scaled Marketplace Notifications and Modernized Their Messaging Stack
When owning notifications became a liability
That’s how Clayton Bell, Head of Platform at Hipages, described their decision to stop owning notifications infrastructure. As one of Australia’s leading home services marketplaces, Hipages depends on fast, reliable messaging to connect homeowners with tradies. But their in-house system—built in PHP and stitched together with Firebase and APNs—was becoming a bottleneck.
Instead of rebuilding it, Hipages made the call to reset. They replaced it with Courier, cut message launch time from four weeks to one day, eliminated critical bugs, and unlocked the freedom to build forward.
Speed is everything—but the system was slowing them down
Hipages connects homeowners with local tradies across Australia—fast. A job post might go live, and within minutes, push notifications are landing in tradies’ hands. The first to respond often wins the work.
That speed is essential to the business. Messaging isn’t just an operational layer—it’s core to how the Hipages marketplace runs. Every job post, every response, every quote is enabled by reliable, timely notifications.
But with millions of messages flowing through legacy code paths across multiple mobile apps and channels, the cracks in their in-house infrastructure were starting to show.
When shipping a message took four weeks
As Hipages grew, its in-house notification system began to drag behind. What started as a handful of PHP scripts tied to Firebase and APNs had become a tangled layer of brittle logic—difficult to modify, impossible to monitor, and increasingly risky to touch.
Every new message type introduced more complexity. A single change might take four weeks and result in unexpected bugs. Even then, product teams couldn’t confirm if messages had delivered, support teams had no visibility, and engineers spent more time debugging than building.
The cracks weren’t just technical. Hipages was already in the middle of a major architectural shift—breaking apart its legacy monolith into services. But notifications were one of the hardest systems to extract. They were everywhere: high-impact, low-ownership, and critical to the user experience.
It became clear the messaging system was holding the rest of the platform back. Fixing it wasn’t enough. Something had to change.
A reset, not a rebuild
The team considered rebuilding it—briefly. But they’d been down that road before. They knew how long it would take, how fragile it might still be, and how much it would distract from work that actually mattered to users.
Courier offered something different. Not just the features, but the philosophy. It didn’t force a framework. It met Hipages where they were: clear APIs, modular design, strong documentation, and first-class support for hard things like token management, retries, and multi-app delivery.
That flexibility mattered. The team was migrating to services, unbundling apps, and maintaining legacy systems all at once. Courier fit into that chaos without adding to it.
But what really stood out was the partnership. Courier’s team got involved—offering architecture support, answering edge-case questions, and shipping fixes fast.
The result was a reset. Hipages finally had a messaging system they didn’t need to worry about—and could move forward with confidence.
A clean break from the monolith
Instead of patching Courier into the legacy PHP monolith, the team built a dedicated messaging service from the ground up in Node.js. It connected to Kafka event streams and used its own data store, fully decoupled from the old architecture. That separation gave them a clean integration point—and control over how it evolved.
A lightweight middleware API sat at the edge, translating internal events into Courier payloads. That abstraction meant upstream systems didn’t have to change. Teams could adopt the new messaging stack gradually, without rewriting their apps.
Some workflows still depended on the monolith, so they kept backwards compatibility by exposing REST endpoints that routed through the new system. It wasn’t glamorous, but it kept the business running.
Courier supported them at every step. A dedicated solutions architect partnered closely with Hipages engineers to navigate edge cases, test assumptions, and help the rollout land smoothly.
By the time they onboarded their mobile apps—each with different states of deprecation—it didn’t feel like a high-risk migration. It felt like infrastructure they could trust.
Key Courier Features Used
Token management. Automatically handled expired tokens
Retry and failover. Built-in retries and fallback ensured reliable message delivery.
Multi-tenant support. Managed distinct message flows across multiple apps.
Provider abstraction. Swapped email providers without system changes.
Observability. Support teams gained delivery insights without engineering help.
Messaging, solved — From four weeks to one day
Now it just works
Messaging isn’t something the team thinks about anymore—and that’s the point.
What was once a fragile, in-house system is now a cleanly abstracted service. Courier didn’t just replace old infrastructure; it helped Hipages reset their approach to building. Less firefighting. More forward motion.
Today, engineers focus on product, not plumbing. Support teams get answers on their own. And messaging just works.
Hipages
hipages.com.au
Industry
Marketplace, Home Services
Pain point
Aging home-built notifications infrastructure
About the company
hipages (ASX: HPG) is Australia’s leading online platform for connecting homeowners with trusted local tradies. With over 3 million jobs posted, hipages makes it easy to find licensed professionals for everything from repairs to renovations.
