Rebuilding the e-commerce shop while customers were still inside

Dan Murphy’s couldn’t close while we rebuilt it

Dan Murphy’s could not close its digital doors while we rebuilt the shop behind them.

The existing website still looked like the early-2010s internet: narrow, fixed-width and compressed into a small strip in the middle of the screen. For a retailer of Dan Murphy’s size, the digital experience had clearly run out of road.

I joined in November 2017 as a Senior Frontend Engineer consultant, working directly on the modern Angular replacement. The new full-width experience was being prepared for a substantial rollout once it was ready, not migrated page by page.

I never needed to work inside the legacy codebase, so its exact framework is less memorable to me than the experience it produced.

Four frontend engineers worked alongside backend engineers, QA, frontend and backend architects, design and project management. It was a complete delivery team because this was a complete retail platform.

We were not only changing how the shop looked. We were rebuilding how people searched, selected, paid, arranged collection and waited for an order to arrive.

The new site had to arrive ready for business

We could not launch a beautiful new homepage and promise to add the actual e-commerce later.

The homepage, product pages and checkout were being rebuilt at the same time as the architecture underneath them. Every technical decision was immediately tested against a real customer journey.

The replacement had to arrive with product discovery, purchasing, delivery and pickup, analytics, search optimisation, marketing integrations, performance monitoring and shared UI foundations working together.

Modernisation and product delivery were the same job.

I was one of four frontend engineers building the new platform itself, and I took particular ownership of performance, the shared UI foundations and the bridge between our application and the SEO and marketing tooling surrounding it.

Working closely with design, I helped break the experience into reusable pieces, establish primitive components and create a shared UI library. The homepage, product pages and checkout needed a consistent visual language without forcing every journey into the same shape.

The architecture became real when checkout had to answer a much more human question: not only where should the order go, but when would somebody actually be there to receive it?

Choosing the hour and telling the store you were coming

Choosing Tuesday was not enough. Customers needed to know whether the order would arrive at 9 a.m., lunchtime or later in the afternoon.

After selecting a date, the checkout presented available delivery or pickup windows such as 9 a.m. to 11 a.m. and 11 a.m. to 1 p.m. That promise had to remain consistent across availability, fulfilment mode, checkout state and final confirmation.

For a customer, this was about ordinary life: being home for a delivery, planning around work or knowing when a collection would actually be ready.

Direct to Boot led me to a more ambitious question: why should an opted-in customer have to tell the store they had arrived if the app already knew they were approaching?

I proposed using the Dan Murphy’s mobile application to recognise that approach and surface the arrival through operational screens or tooling inside the selected store. Staff could then prepare the order before the customer reached the pickup point.

That concept was not approved or implemented. The experience that shipped used SMS communication and a customer link for practical arrival and collection updates.

Not every ambitious version becomes the shipped version. The useful part is allowing the bigger idea to sharpen the simpler one: how much friction could we remove between entering the car park and receiving the order?

We were removing minutes from collection. We could not afford to add seconds back into the website.

The campaign that slowed the website down

New Relic showed the change immediately: a healthy page had suddenly become noticeably slower in production.

The slowdown had appeared immediately after a marketing change.

I traced it to the new campaign content.

The image was far larger than the page needed.

The third-party script was worse. It had not been deferred and was occupying the browser’s main thread, competing with the application for the browser’s attention.

Individually, both choices were avoidable. Together, they created the regression I was seeing in production.

I reverted the change quickly.

The campaign was trying to attract customers. Its implementation was making the shop slower for every customer who arrived.

This was a technical failure in the release process, not a reason to blame marketing. Future images needed optimisation, scripts needed deliberate loading behaviour and larger integrations needed performance review before production. New Relic would remain part of checking what happened after release.

I worked with an experienced SEO and marketing specialist to create that safer process and give both sides visibility into production impact.

I could revert one campaign. The more important job was making sure the next campaign did not need rescuing.

Giving marketing room without giving away performance

Locking every tracking change behind an engineering ticket would have solved the wrong problem.

SEO and marketing specialists needed room to measure journeys, understand customer behaviour and run campaigns. Engineering could not become the queue for every tracking adjustment. The application still needed protection from heavy images, blocking scripts and uncontrolled interface injections.

Freedom without visibility was risky. Control without flexibility was too slow.

I brought experience from Appliances Online and adapted it to Dan Murphy’s. Google Analytics and Google Tag Manager became part of a governed pipeline rather than an unobserved route into the application. Engineering advised on larger or riskier changes, while New Relic kept their production impact visible.

The tools were only part of the answer. The working relationship mattered more: marketing understood what the campaign needed to achieve, and engineering helped it reach customers without competing unnecessarily with the page they were trying to use.

Once the Dan Murphy’s platform began looking like a foundation rather than a collection of pages, it was difficult not to look across the office at BWS.

The platform idea waiting a few desks away

Only a few desks away, another bottle-shop frontend was living in a very different generation of Angular.

Dan Murphy’s was moving to modern Angular. BWS had a separate team and an older AngularJS-era application. I could see a path where the two brands remained different shops without needing completely different frontend foundations.

I proposed a gradual BWS migration supported by shared libraries, modern Angular foundations and a monorepo-style structure. The teams could reduce duplicated platform work while retaining separate product experiences.

The proposal was not approved or implemented.

Dan Murphy’s was still the immediate priority, and the wider migration would have opened another substantial programme before the current replacement had landed.

The architecture opportunity was real. So was the cost of opening a second transformation before the first one had landed.

Consulting taught me to recognise the next platform problem. Dan Murphy’s also taught me that recognising it does not automatically make it the next thing the business should fund.

The larger architecture idea stayed on the shelf. The Dan Murphy’s platform did not.

Performance was part of the product

By the end of my extended contract, Dan Murphy’s no longer looked or behaved like the narrow retail website I had first encountered.

The wider team had established a modern full-width experience with new homepage, product and checkout foundations, fulfilment time slots, Direct to Boot, reusable UI, New Relic monitoring and governed SEO and marketing integrations.

My original twelve-month contract was extended. After the major platform areas were established, I chose to continue consulting at Woolworths Group in February 2019. The fulfilment-window knowledge later informed my work on Woolworths Group checkout. The code did not travel between teams; the product understanding did.

Dan Murphy’s taught me that performance is not the final polish added after a feature is complete.

It changes whether the feature works at all.

Direct to Boot can remove friction from collection. Time slots can make delivery fit around somebody’s day. Analytics can help the business understand what customers need.

But every one of those ideas still arrives through the same page.

If that page becomes slow, the customer experiences the performance problem before they experience the feature.

Performance was not sitting beside the product.

It was part of the product.