<  Back to blogs

How we cracked half metre fabric ordering on Shopify: an interview with our lead developer

Published by: Untapped
June 4, 2026
8
mins
Ecommerce
Ecommerce
Published by: Untapped
June 4, 2026
8
minutes

The Stripes Company has been a UK fabric specialist since 2007, designing woven striped textiles and lifestyle products for the home, beach and garden. Loved by retail customers and trade buyers alike, the brand had grown organically across the globe, with dedicated solutions in 4 countries, each with its own quirks, until they came to us for a full rebuild.

The site had a challenge, a wrinkle you could say, nobody in the fabric industry had solved cleanly. Customers needed to order fabric by the metre, in 0.5m increments, but Shopify is built around whole units. The standard workaround is to sell fabric in 0.5m chunks and ask customers to do the unit maths themselves. It works; however, this user experience was not up to our quality standards. We knew we could do better.

We sat down with the developer who led the build to talk through what we did, why it mattered, and how the methodology shifted along the way.

Will: Maria, the CEO at Stripes, told us nobody in the fabric industry had really nailed decimal-length ordering. Why is that so hard on a platform like Shopify?

Developer: If you weren't using an off-the-shelf system, it would be trivial. You'd just build it. But then you'd lose all the things Shopify gives you: marketing, drip campaigns, stock management, social integration, AI integration, all of that. The brief was to keep all those benefits and still let customers order in metres and half metres.

Most people get around it by selling fabric in 0.5m units and putting a note on the product page saying "if you order 10 of these, you'll get 5 metres". That's actually what Shopify themselves recommend. But it's a really poor user experience.

Will: So, how did we solve it?

Developer: We modified the front end, in the liquid code itself, so the price, the weight, the basket totals, the invoice, all of it reads in metres. Customers select 0.5m, 1m, 6.5m, whatever they need, and everything looks the way they expect. The platform is still doing its thing underneath, but the customer never has to think about it.

Will: There's a proof of concept we built and trialled but held back from launch. The admin side. Tell me about that.

Developer: The team at Stripes work in metres. So we worked out how to make the back end speak metres too: stock management, manual orders, all of it. They didn't need it on day one, so we shelved it for now, but it's ready to be taken to a production ready solution when the time is right.

Will: What we ended up with is a custom set of Shopify apps that are bespoke to Stripes. Their team can manage the things that make their business different from any other Shopify store, all from inside their own dashboard.

Developer: Right. And that's the point. The uniqueness of their business is what gives them the edge. The tools have to support that, not work against it.

Choosing fabric, visualising the result

Developer: One of the other things that makes Stripes different is the way fabric works as a product. If you sell deck chairs in 50 fabrics, you can photograph all 50. But if you're selling something with multiple fabrics, say, cushions where the front and back can be different, that's 2,500 combinations. You can't photograph that.

So we built a way of configuring the data and the UI so customers can see the fabric images, choose the combinations they want, and get as close to a real preview as possible without us photographing every variant.

Will: And there's a future stage planned around AI generated visualisation, isn't there?

Developer: That's the goal. If you could generate a render of the actual cushion or chair with the fabrics the customer just selected, that would be a huge differentiator. Visualisation is everything when you're buying fabric. It drives purchase intent. We haven't built it yet, but it's on the roadmap.

Will: There's another piece that doesn't get talked about as much but is genuinely clever: how the bill of materials work.

Developer: Stripes holds stock of fabric and stock of frames separately. They don't pre-make a deck chair. So when someone orders one, you need to take stock off the fabric and the frame at the same time. That's standard bill of materials behaviour, but normally you'd need an expensive ERP system to handle it.

We built it inside Shopify. You configure that a particular product is made up of, say, 3.5m of fabric and one frame, and the stock updates correctly when the order goes through. No bolt-on systems, no extra licences.

Migrating 20 years of business onto a modern stack

Will: The other unglamorous bit of work is the migration. Stripes had years of bespoke product data behind them that couldn’t be lost. What's involved in moving that onto Shopify cleanly?

Developer: A lot. Shopify only has one copy of the data. If you mess it up, you're in trouble. So you need to be able to relate everything back to the starting point all the time. Repeatable migrations, double checks, the lot.

Beyond the data, you're moving a long-running brick and mortar business onto a standardised modern stack and keeping everything they had. Getting that right is no small feat.

Why we did agile in reverse

Will: This is the bit I find most interesting. Talk me through the methodology, because I know you ended up doing the opposite of what we’d normally recommend.

Developer: Yeah, it was strange. Normally, I'd say start incrementally: do what you can first, see what's left. With a project like Stripes that doesn't work. You have to understand all the edge cases before you start, you build something that doesn't fit 5% of the data, and you're stuck.

So the process was data analysis first. Understand the new model. Then understand all the things that don't fit into it. That's 100% of the data and 100% of the UI, because not everything lives in the data. Some of it lives in how things connect on the website.

Once you've got that totality, you can say right, 95% of this is the same thing, now let's deal with that 5%. From there, it becomes iterative again. You move forward on the things you've identified while you're still solving the harder bits.

Will: So neither pure agile nor pure waterfall.

Developer: Exactly. Pure agile says forget the unknowns and just build. Pure waterfall says answer everything before you build anything. On a replacement system with a lot of unknowns, neither works. You need to build and resolve unknowns in parallel, in the right balance. That's the actual skill.

The takeaway

The Stripes build is a good example of what we mean when we talk about being technology agnostic. We didn't pick Shopify because it was familiar. We picked it because it was the right long-term platform for Stripes, then put the work in to make it do things it wasn't designed to do out of the box.

Off the back of the rebuild, Stripes moved straight onto our Premium Shopify Maintenance retainer for ongoing development and CRO, and we now run their paid social and search across Google, Pinterest and Meta.

If you're sitting on a business with quirks that off-the-shelf software doesn't quite handle, that's usually the most interesting place for us to start.

See it in action

You can browse the finished build at thestripescompany.com. The decimal-length ordering, the fabric configurators, the trade experience, the bill of materials work, it's all running there.

Thinking about a Shopify build of your own?

We're a certified Shopify Partner with a track record of taking businesses that don't fit neatly into off the shelf templates and making Shopify work for them anyway. Custom apps, complex variant logic, migrations from legacy systems, international rollouts, ongoing maintenance and CRO, paid media, the lot.

If you've got a project in mind, whether it's a full rebuild or a stubborn problem on an existing store, get in touch. We'd love to hear about it.

Any thoughts?

Leave a comment

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Responses
--

ReplyDelete

ReplyDelete