We asked Bailey Johnson, Skipper's Ecommerce Manager, about how the brand got started. The sustainability mission isn't a brand story layered on top of the business — it's the founding idea, and it explains everything about how Skipper is built and who they're building it for.
Skipper started back in 2020, a Covid-19 start-up like plenty of other ecommerce businesses. It was a period when ecommerce really started to boom, everyone was in lockdown and online shopping took off almost overnight. Skipper's two co-founders, May Bandi and Lachlan Hill, were mates from The University of Queensland who had always wanted to build a business that was successful and did some good at the same time. Profit for purpose, as they called it.
During lockdown, there were hand wash and sanitiser bottles turning up in every house, and once you look into it you realise most household cleaning and personal care products are 95 to 99% water. So the whole industry is shipping water around the country in single-use plastic, for products people use every single day, which makes no sense and creates a lot of preventable waste.
Their answer was to take the water out and let people add it at home, then keep the same dispenser and top it up forever. That's still the mission today: turn everyday habits into a force for good, and the useful part is that it costs less too. We're now past 300,000 customers worldwide, more than 100,000 of them in Australia, and over 500,000 kg of plastic waste skipped.
The refill model isn't just a sustainability choice — it's the commercial logic that drives nearly every ecommerce decision Skipper makes, including what they choose to test. When we asked Bailey about the product lineup, the answer was really about how the business works.
As a business selling replenishables, our refills are the most important product commercially, but the journey starts with a Starter Kit or Bundle. Those come with the dispensers, tins and a few refills to get going, and then every few months our customers — or Skippers, as we call them — come back for a top up when their tins are running low.
Winning new Skippers is costly and it gets harder over time, so most of our energy goes into looking after the customers we already have and making sure they're happy. That's the most important thing for us, and it's a big part of why so much of our testing sits around refills, the cart and the reorder experience rather than the top of the funnel.
Before Shogun, Skipper had worked through several testing platforms. The frustrations were consistent across all of them. We asked Bailey to describe what that looked like — and what finally changed.
We've done a lot of testing over the last couple of years as the team has grown, and in that time we've worked our way through several different platforms. The frustrations were fairly consistent. We couldn't always run the test type the question called for, so some of the more interesting ideas just sat in the queue, and the reporting wasn't detailed enough to tell us much beyond a headline number. That's a slow way to run a website, because when a result came in we'd end up debating whether it was real instead of acting on it.
Shogun changed that. When we asked Bailey what made it stand out, the answer was simple: features, price, and reliability — and all three delivered.
Features first, then price, then reliability, and in practice those three have turned out to be the whole story.
On features, Shogun runs every test type we actually need. We work mostly in theme tests and template tests, so being able to put a full theme up against the original, or target one template, covers almost everything on our list without us having to build workarounds. The reporting was the other drawcard. We can break a result down by product and see how a test performed hour by hour, which matters more than it sounds, because a weekend or a sale can quietly skew a read and you want to know when that's what you're looking at.
On price, it does more than the platforms we'd used before and costs less, which isn't a combination you come across often. That sounds like a small thing, but it changes behaviour. When testing is affordable, you test constantly, and constant testing is where the compounding happens.
Reliability is the boring one that turned out to matter most. When a testing tool misfires you don't just lose the test, you lose the fortnight you spent waiting on the result. Shogun has been solid from the start, and being able to trial it properly before committing gave us the confidence it would hold up.
Tooling alone doesn't build a testing culture. When we asked Bailey how the team decides what to test and keeps the program moving, what he described was less a workflow and more a set of standing commitments that make experimentation a default rather than an occasional effort.
Anyone can put a test forward, but it has to be written down first. Every proposal goes into our internal hub with a hypothesis, a preview link and what we expect it to move, then it posts automatically into a dedicated A/B testing channel in Slack where the web team review it. Writing the hypothesis before anything gets built does more than it looks like it should, because a test you can't explain in two sentences usually isn't worth running.
From there we rank on four things: whether it improves the customer experience, the time and resourcing it takes to build, whether it's the highest leverage test we could be running right now, and its likely commercial impact against everything else on the list. We commit to a set number of tests a month so it doesn't get dropped the moment something else catches fire, we keep one test running at a time so results stay clean, and we do a short readout each week to keep the broader team in the loop.
Ask most teams what A/B testing looks like and they picture big swings — full page redesigns, new navigation, a complete rethink. At Skipper, the data told a different story. When we asked Bailey what types of tests have been most valuable, his answer reframes the whole thing.
We run two main types of tests, theme tests and template tests, and the pattern in what wins has been pretty consistent. Small changes close to the decision, almost every time. A badge or a line of text right under the add to cart button, the way a price and its savings are displayed, per-unit pricing on refill pack sizes, or a micro-interaction that makes the cart more visible. Product naming has been surprisingly powerful as well, and one bundle name change beat its alternative on conversion for the cost of editing a few words.
We're big believers in kaizen here, which is the idea that small, steady, easy changes stack into something much bigger than any single swing. That's the opposite of how most people picture A/B testing, and it's the lesson we'd hand over first. The grand redesigns have been our least rewarding work, and many of the quick five minute changes have been our best.
The kaizen philosophy shows up clearly in Skipper's results — not just in what won, but in how they responded when something didn't. Bailey walked us through the tests that mattered most.
The standout was a change to the cart icon, where we made it pulse when there's something in the cart. That returned a conversion uplift comfortably above 5% and has since been rolled out to everyone.
Adding shoppable video to product pages gave us a high single-digit lift in desktop conversion, which was enough to justify rolling video out more widely. Our cart redesign is the more instructive one, though. The first version came in behind the original, and worse again on desktop specifically, so we took the feedback, made a handful of small fixes and re-ran it. The second version came out a couple of percent ahead and we shipped it. Without the ability to test that properly we'd have either launched a worse cart or binned weeks of good work.
The number we care about most is cadence. We're running roughly a test a fortnight now, which means we're learning something about our customers every two weeks, and that feels like the right rhythm for us at this stage.
.webp)
We asked Skipper to name the experiment they're most proud of. What Bailey described is a perfect encapsulation of their entire philosophy.
The pulsing cart icon, and it's the one we're proudest of precisely because it's so unglamorous. A water drop icon that gently pulses when there are items in the cart. That's the whole change. It took a fraction of a day to build and returned a bigger conversion uplift than work that took us weeks.
We'd never have run it if we weren't in the habit of testing small things, because on paper it sounds far too minor to bother with. That's the value of the process more than the tool. It gives silly little ideas somewhere to go, and every so often one of them turns out to be worth a lot of money.
When we asked about the most surprising learnings from testing, Bailey offered a few observations — each one a genuine shift in how the team reads results and makes decisions.
Three that changed how we work.
Effort and results have almost nothing to do with each other. Our biggest win cost us an afternoon and our flattest result cost us weeks.
Averages hide the story. Our cart redesign looked roughly level overall, but it was meaningfully down on desktop, and if we'd only looked at the headline number we'd have shipped something that quietly hurt a big chunk of our customers.
And losing tests are worth nearly as much as winning ones. We had a run of them, and it wasn't much fun, but it ruled out a whole category of ideas we'd otherwise still be arguing about. Knowing something doesn't work is a real result. You just have to be willing to say so out loud.
The deeper impact of building a testing culture isn't in the results — it's in what disappears. We asked Bailey how experimentation has changed the way the team operates day to day.
It changed how we make decisions more than what we build. "Let's test it" has replaced a lot of back and forth, which takes the ego out of design debates and gets things live faster. Everything starts as a written hypothesis now, and that discipline alone has killed a few ideas before anyone wasted time on them.
It also reordered our roadmap. We used to reach for the big new page, and now we make small tweaks and polish what's already working, because that's what the data keeps telling us to do. The best part is cultural, though. Testing is a standing habit with its own channel, a monthly planning slot and a weekly readout, so it doesn't depend on anyone remembering to care about it.
We asked Bailey what advice he'd give to brands not yet investing in A/B testing, and what Skipper plans to tackle next. Both answers come back to the same idea: the goal isn't a perfect store, it's a store that keeps getting better.
Start smaller than feels worthwhile, and don't start with a redesign. The temptation is to test something impressive, but the changes that have paid off best for us are the ones that felt almost too small to justify the setup time. Review your web funnel and start with the lowest hanging fruit: your highest traffic pages, your cart, your checkout.
Write the hypothesis down before you build anything, because it forces you to be honest about what you're actually trying to learn. Then make peace with the fact that plenty of your tests will lose, since that's not a sign it isn't working, that's the whole mechanism. This is kaizen applied to a website. Small, steady, easy changes, over and over, until you've ended up somewhere much better than a big rebuild would have taken you.
Looking ahead, pricing and shipping economics are top of the list — the free shipping threshold, shipping price, and per-unit value on pack sizes are decisions made on judgment so far, and they're expensive to get wrong. Reordering is the other priority, because most of Skipper's revenue comes from households topping up products they already use, and anything that makes the next refill faster compounds for years.
Underneath all of it, though, what we're really chasing is a better experience for our customers. We want the Skipper website to be world-class, the best possible experience for the people buying from us, and we'll keep improving it for as long as we're here. Testing is simply how we get there, one small improvement at a time rather than in one big leap.
.webp)
.webp)
