- i only speak liquid
- Posts
- "i only speak liquid" #88: To Code or Not to Code?
"i only speak liquid" #88: To Code or Not to Code?
Written by Rishi (a Storetasker Expert)
Hey everyone,
This is Rishi’s 4th and final edit of “i_only_speak_liquid”!
Bittersweet moment as he’s been an incredible contributor these last few edits.
But let’s look at the bright side: We can dive right into Rishi’s last masterpiece right here, and in 2 weeks another writer from the Storetasker network will take over for 4 edits 🤗
Until then, let him cook!! 👨🍳
—
About Rishi: Rishi is a UK based frontend developer with over 10 years of specialised experience in Shopify development. His expertise includes custom theme development, marketing and conversion rate optimisation (CRO), design-led development, and e-commerce strategy.
Ofc: He’s an expert on Storetasker 😉 apply here.
Let’s dive in 🤿
What I’ve been thinking about:
Shopify seems to be evolving faster than ever and it’s making me approach projects differently. When I started out, building custom functionality was the only real answer. Now, with the vast size of the app ecosystem and improvements to Shopify's native features, the question isn't always "Can I build this?" but rather "Should I build this?"
For example, I had a client request a custom wishlist feature. Five years ago, I would have immediately started coding. Nowadays, there are solid wishlist apps that handle edge cases I wouldn’t have even considered, include customer accounts integration, and provide analytics. Building custom would take hours and create something I'd need to maintain. Installing an app took 30 minutes and gave the client a better solution.
This shift in thinking has changed how to position my value to clients:
Strategic Advisory: I'm not just a developer anymore, I'm someone who can evaluate the best path forward. Sometimes that's custom code, sometimes it's an app, sometimes it's a combination. Clients appreciate when I can say "here's what makes sense for your budget and timeline" rather than defaulting to the billable option.
Focus on the Unique: I now reserve custom development for things that truly differentiate a client's store. Standard design? There's usually a great theme for that. But that unique checkout flow or specialised product configurator that's core to their business model? That's where custom development shines and delivers real ROI.
Building for Longevity: When I do build custom, I'm thinking about handoff and maintenance. What happens if this client moves to an agency in two years? What if their budget changes and they can't afford custom updates? I try to build in ways that are either self-explanatory or could easily be replaced with an app solution if needed.
The industry talks a lot about "learning to code" but I think there's an equally important skill: learning when not to code. Strategic thinking often serves clients better than “this will be a huge billable project” and “an opportunity to flex my dev skills”.
3 links you can’t miss:
Web Interactions Gallery - Need inspiration for some nice interactions? Look no further.
For Starters - I really enjoy this weekly newsletters about starting a small business. I don’t normally like newsletters but this one is always great.
Jam.dev - Save the back and forth with clients trying to ask what’s in the console or what browser they are using. Great for working out bugs.
1 app I like:
Why I Love It: This is another request I get from a number of clients, so having an app that’s super easy to use and implement is always a bonus. Stoq handles preorders and back in stock alerts and syncs straight into Klaviyo as well.
One learning as a freelancer:
Given its BFCM and holiday season coming up, I’ve been looking at seasonality and how it affects freelance work. The past few months have shown me just how cyclical e-commerce development can be. Q4 is chaos, everyone wants updates before Black Friday. January is dead, clients are recovering from holiday sales and reassessing budgets.
In 2026, I'm going to be more intentional about planning for these cycles rather than just reacting to them. During busy periods, I'm banking extra income. During slower months, I'm using that time for things I never have bandwidth for: updating my portfolio, learning new technologies or reaching out to past clients about potential projects.
Freelancing isn't just about managing projects, it's about managing momentum. The slow periods aren't failures; they're opportunities to invest in yourself so you're even stronger when things pick back up. The sheer amount of developers or freelancers that burn out shows that this is a lesson learnt the hard way.
The other side of this is communicating these rhythms with clients. Setting expectations that "Q4 books up fast" or "January has more availability for discovery work" has actually helped with planning and reduced last-minute panic requests.
Thanks everyone, this is my last edit and I've really enjoyed writing them. As always would love to hear your thoughts and connect over on LinkedIn.

