Shopify Developers who write the code, not just install apps.

A Shopify developer writes the code that makes a store behave differently from the theme it started as. In practice that is Liquid templating, JavaScript for storefront behaviour, CSS for the design system, Shopify's Admin and Storefront GraphQL APIs for data, and app code where the storefront alone cannot do the job. It is distinct from a Shopify designer, who decides what the store should look like, and from a merchandiser, who runs it day to day.

Liquid is Shopify's templating language, the layer that turns store data into HTML. Badly written Liquid is the most common cause of slow Shopify storefronts: nested loops over large collections, repeated lookups that could be assigned once, and rendering work that belongs in a section rather than a global template. It is easy to write Liquid that works and hard to write Liquid that stays fast at 5,000 products.

Yes, everything we build uses the Online Store 2.0 architecture: JSON templates, sections available on every page rather than only the home page, app blocks, and metafields and metaobjects for structured content. The practical benefit is that your team can rearrange and edit pages in the theme editor without coming back to us for layout changes.

We work with what you have wherever that is the honest answer. A well-built premium theme with sensible customization is often the right call and we will say so. A rebuild is worth it when the theme has been modified past the point of upgrading, when performance problems are structural, or when your merchandising model no longer fits the template. We tell you which situation you are in before quoting.

Both, deliberately. An app is the right answer when it is a solved problem maintained by someone else, and we will recommend one rather than bill you to rebuild it. Custom code is the right answer when an app would need heavy configuration to half-fit, when several apps would overlap, or when the app tax on page speed outweighs the feature. Most slow Shopify stores we inherit are slow because nobody made that call.

By keeping customization out of the files most likely to change upstream. Custom logic goes into new sections, snippets and blocks rather than edits scattered through core template files, styling extends the theme's own tokens rather than overriding them at random specificity, and anything genuinely bespoke is documented in the repository. A theme customized this way can take a vendor update; one edited in place cannot.

Always. Work happens in a development store or an unpublished theme, never on the live theme, and you get a link to watch it as it is built rather than a reveal at the end. Publishing is a deliberate step with a checklist, not a side effect of a save.

Yes. We can take a defined workstream while your team runs the rest, review their pull requests, or act as the senior developer a junior in-house team can escalate to. What we ask for is a clear boundary on who owns which part of the codebase, because shared ownership without that boundary is how two competent teams produce one broken theme.

Yes, on Hydrogen and Oxygen, and on other frameworks against the Storefront API. We are also willing to talk you out of it. Headless earns its cost when you need a genuinely custom front end, content from several systems, or performance the Liquid storefront cannot reach. It costs you the theme editor, most of the app ecosystem and a permanent increase in maintenance, which is a bad trade for most merchants.

Every project lives in Git, with branches per piece of work and a review before anything merges. Theme code is deployed from the repository rather than edited in the Shopify admin, so there is always a history of what changed and a way back. If you have your own repository and workflow we work inside it.

Yes, and it is a large part of what we do. We start with a read-only audit: what the theme is, what has been modified, which apps are installed and what they inject, and what is actually causing the symptom you are seeing. You get that assessment in writing before any remediation is quoted, so you are not paying us to discover the problem twice.

Often nothing, which is the problem. Many Shopify apps inject snippets into theme files on install and do not fully remove them on uninstall, so a store accumulates dead script tags and orphaned Liquid that still cost load time. Cleaning that up is usually the cheapest performance win available on an older store, and it is part of any theme work we do.

Yes. Shopify Functions cover custom discounts, payment and delivery customization and cart transforms, and Checkout UI Extensions cover the interface changes that used to require checkout.liquid. Both require Shopify Plus. Worth knowing before you plan around them: a discount Function does not run for an API-created draft order, so B2B flows that rely on draft orders need the agreed price written onto the line instead.

A written checklist rather than a click around. Every template on real data, the full purchase path on desktop and mobile including a live test transaction, discount and shipping edge cases, form submissions arriving where they should, analytics and conversion tracking firing, redirects resolving, and a Lighthouse pass on the home, collection and product templates. Anything that fails is fixed before launch, not logged for later.

The repository with its history, a written summary of what was built and why, documentation for anything a future developer would otherwise have to reverse engineer, and a walkthrough for whoever runs the store. Access sits with you throughout, so handover is a conversation rather than a transfer of custody.

Yes. A fixed-price audit covers theme and code quality, the installed app stack and what each app costs in load time, performance against Core Web Vitals, technical SEO, and the specific problems you have raised. You get a prioritized written report you own and can hand to any developer. Plenty of clients take the report and fix things themselves, which is a legitimate outcome.

Lead with the business problem rather than the solution you have in mind. What you sell, who buys it, what is happening now that should not be, and what success would look like in numbers. Screenshots of the current behaviour beat descriptions. If you already have designs, send them early, because a build quoted before seeing designs is a guess.