Shopify stores built by someone who writes the Liquid himself.
20+ WooCommerce or Shopify stores, inside the 150+ projects I have delivered under my own name since 2019. One developer, start to finish.
A Shopify store can look finished and still lose money quietly.
The theme is decent, the products are loaded, and the traffic arrives. The checkout still leaks, the product page still does not answer the question the buyer actually has, and nothing in the dashboard tells you which one is costing you more.
I build Shopify storefronts in Liquid, by hand, with the buying journey treated as the thing being engineered rather than decorated.
What I can prove, and what I cannot
On WordPress and WooCommerce I can point you at published code. Five plugins, a theme and ten block patterns of mine are on wordpress.org, and you can read every line before you decide anything.
Shopify is different, and I would rather say so than dress it up. Shopify work lives inside client stores, not public repositories.
So what I can offer here is a straight account of how I work, and the same standard applied.
The public code is the honest sample. If the way I write WordPress and WooCommerce holds up when you read it, that is the same discipline going into your Liquid.
20+ WooCommerce or Shopify stores sit inside the 150+ projects I have delivered since 2019. That number is on my about page and it has not been rounded up for this one.
What I build
Custom Liquid theme development, tailored storefronts, and checkout journeys built to convert rather than just to look current. Migrations in and out when the platform is the problem.
In practice that means:
Every build ends with the theme in a repository you own and notes explaining why it is put together the way it is.
Why brands outgrow a bought theme and a stack of apps
A paid theme is the right answer for a first store. It stops being the right answer at about the point the store starts carrying real revenue.
The Generic Reality
The pattern is consistent:
- The storefront looks like every other store on the same theme.
- The layout fights the product rather than presenting it.
- Each new feature arrives as another app, and another script.
- Page speed drops, and nobody notices until sales do.
- Checkout collects fields nobody reads.
- A theme update overwrites a customisation somebody made two years ago.
The Custom Solution
A build shaped around your products gives you:
- a storefront that looks like your brand, not the theme’s
- fewer apps, so fewer scripts and fewer things to break
- a product page that answers the buyer’s actual question
- a checkout that asks only for what you need
- theme code in a repository you own, with the customisations documented
What makes my Shopify work different
I write Liquid rather than assembling apps.
Most storefront problems are solved better in the theme than by adding another app. An app is a dependency, a script on every page, and a monthly cost. A section written properly is none of those things.
Before I change anything, I want to know:
- Where exactly are people leaving, and on which device?
- What question is the product page failing to answer?
- How many apps are loading, and what does each one earn?
- Which checkout fields are optional in practice?
- What breaks if the theme updates tomorrow?
- Who edits this store after I hand it over?
What I focus on in every Shopify build:
Speed
These are the ones that move money, and they are rarely the ones that get the attention.
Product clarity
The product page should answer the buyer’s question before they have to go looking for it.
Fewer apps, deliberately
Every app is a script on every page. If a section can do it, a section should do it.
Checkout treated as revenue
Field count, validation behaviour and payment failure states get the same attention as the design.
Speed on a real phone
Tested on a mid-range device on mobile data, not on a desktop connection.
A store your team can run
The person adding products on Monday morning is a user too, and usually the one nobody designed for.
The problems Shopify work actually solves
Brands usually come to me when one or more of these is true:
People arrive and leave, and the analytics tell you that it happened without telling you why.
Nobody made it slow on purpose. It arrived one app at a time.
The changes were made in the theme editor rather than in version control, so the update overwrote them.
The acquisition cost is real and the destination is not strong enough to justify it.
The catalogue, the merchandising or the market moved, and the theme did not.
What you are actually buying
You are not buying a Shopify store.
Custom Shopify work is not about making the store more elaborate. It is about making it harder to break and easier to sell from.
You are investing in:
- a storefront that survives a theme update
- fewer apps, so fewer scripts and lower monthly cost
- a product page that does the selling
- a checkout that asks for less and completes more
- theme code in a repository you own
- customisations documented rather than remembered
- a build the next developer can pick up without a rewrite
- a developer you can reach directly, start to finish
How I approach Shopify work
My Shopify work follows a structured path because a store that handles money deserves more than a theme purchase and an app stack.
1. Discovery
What you sell, who buys it, where they leave, and what the store is costing you today.
2. Audit
Which apps are installed, what each one costs in weight and in money, and what can go.
3. Structural planning
Product data, collection logic, page hierarchy, and the path from landing to checkout.
4. Development
Liquid sections and theme work in version control, not edits typed into the theme editor.
5. Testing in real conditions
On a real device on mobile data, with real products and real payment states.
6. Handover
Theme repository, credentials and documentation to you. Ongoing work is optional and never a condition of the build.
“A store you cannot safely change is a store that quietly stops improving.”
Who this is best suited for
Shopify development with SoftGlaze is a strong fit for:
- stores converting below what their traffic deserves
- brands whose storefront looks like the theme rather than the brand
- anyone whose customisations were wiped by a theme update
- stores carrying more apps than they can justify
- brands migrating into or out of Shopify
- anyone who would rather talk to the developer than an account manager
I am one person, so I cannot take unlimited work, and I will say so rather than let you find out halfway through a build.
Why SoftGlaze is a stronger choice
I write the Liquid myself. There is no account manager between you and the person changing your theme.
The public evidence for how I write code is on wordpress.org, in five plugins, a theme and ten block patterns. Shopify work is private by nature, so judge the standard by the code you can actually read.
What that means in practice:
- theme code in version control, not the theme editor
- apps removed wherever a section will do
- checkout treated as revenue, not layout
- speed tested on a real phone on mobile data
- everything documented as it is built
- every credential and repository transferred to you at launch
If your store is slow, leaking at checkout, or looks like the theme you bought, let’s look at it properly.
Tell me what is broken or what you want built. If it is not a good fit, I will say so quickly and point you somewhere better.