Custom Shopify Development Services: What Founders Actually Get (vs What They Expect)
Hiring a custom Shopify development company? Learn what scope, QA, handoff, post-launch support, and red flags actually look like before you sign.
Pratik Talati · 10 min read · 26 June 2026
Custom Shopify Development Services: What Founders Actually Get (vs What They Expect)
TL;DR - Custom Shopify development is worth it when the scope is tight, the QA is methodical, and the handoff leaves you able to run the store without the agency in the room. The expectation gap closes before the contract is signed, not after: know which of the four types of "custom" you're buying, insist on a written spec over a Figma file, screen for a real QA process, and confirm you own the code and every credential at handoff.
Most founders enter a Shopify development engagement with a clear picture of what they want: a store that looks exactly like the mockup, checks out without friction, and runs fast. They exit with something close to that - plus a list of things they didn't know they needed to ask about, and a few they wish they'd asked before signing.
That gap is the point of this article. Not to scare you off custom development (it's the right call for plenty of Shopify builds) but to make the scope, QA, handoff, and post-launch phases legible before you engage a Shopify development company or agency.
This article is for:
Founders about to hire a custom Shopify development company or agency for the first time
Store owners who've been burned by a vague engagement and want to scope the next one properly
Anyone comparing quotes that look wildly different and can't tell why
This article is NOT for:
A step-by-step Liquid tutorial - this is about the engagement, not the code
Merchants who only need a paid theme installed with no customisation; that's not a custom build
Enterprise Plus buyers with an in-house dev team - your procurement process already covers most of this
What "custom Shopify development" actually means
The phrase covers at least four distinct things, and what you're buying determines what good delivery looks like.
Custom theme development. Building or modifying a Shopify theme in Liquid. This is the most common engagement. It ranges from heavy customisation of a paid theme like Dawn ($2,000 to $8,000) to a ground-up bespoke theme ($12,000 to $30,000+). The output is a theme.zip you publish from the Themes tab.
Custom Shopify app development. A private or public app that extends Shopify's native behaviour - a custom B2B pricing engine, a wholesale portal, a pick-and-pack integration. These are built in Node/Remix or Rails using Shopify's App Bridge and Admin API. Budget: $8,000 to $50,000+ depending on complexity.
Headless storefront. A React (usually Hydrogen) or Next.js front-end that uses Shopify only as a commerce backend via the Storefront API. Justified when you need full control over routing, rendering, and third-party integrations that Liquid can't accommodate. Budget: $20,000 to $80,000+. Most SMB merchants don't need this, and the decision of where the Liquid-versus-Hydrogen line actually sits deserves its own analysis (a forthcoming article in this series covers exactly that).
Custom Liquid sections and features. Adding functionality to an existing theme - a custom product configurator, a multi-step bundle builder, a loyalty tier display. Scoped per feature, usually quoted as a fixed price or time-and-materials block.
Knowing which category you're in is step one. A vague "custom Shopify development" request will get you a quote - it just won't be a quote for the same thing across different proposals.
Scoping: where most engagements go wrong
The gap between what founders expect and what they receive usually opens during scoping, not delivery.
A well-scoped Shopify project has:
A written feature list, not just a Figma file. Designs show how things look; specs say how they behave. "The cart should update without a page reload" is a spec. The Figma of the cart is not.
A device and browser matrix. Which browsers and devices are in scope? Chrome 120+, Safari 17+, Firefox, Edge, iOS Safari, Android Chrome - these should be named, not assumed.
Integration assumptions documented. If you're connecting Klaviyo, Gorgias, ReCharge, or a 3PL warehouse API, each integration is its own mini-project. They need to be line-itemed in the scope.
A change management process. What happens when you decide mid-project that the product page needs a video carousel you didn't brief? The answer should be a written change order process, not silence.
A concrete example (based on a real engagement; client details anonymized): a DTC skincare founder came in with a Figma file and a budget of roughly $15,000. The mockup showed a quiz-driven product recommendation flow. Nobody had scoped the quiz logic against Shopify's native capabilities. The quiz required a custom app, not theme Liquid, adding around $6,000 to the project - a roughly 40% overrun that a 30-minute technical discovery call would have surfaced up front.
Any Shopify development agency that prices from a mockup alone, without a discovery call or written brief, is pricing a guess. You pay for the delta when the actual spec materialises.
What good QA looks like
"We tested everything" is not a QA process. For a Shopify build, a proper QA pass covers:
Checkout flow (the non-negotiable). Every payment method you plan to accept - Shopify Payments, PayPal, Shop Pay, any buy-now-pay-later option - should be tested before launch. Shopify Payments test mode uses test card numbers to simulate successful and failed transactions without processing a real charge. Any agency that hands off without running a Shopify Payments test-mode transaction before launch is skipping the most business-critical test.
Shopify theme review checklist. Shopify publishes a Theme Store review checklist, and even for private themes it's a useful quality standard. It covers accessibility, performance, metafield usage, and mobile behaviour. A good agency references it; a thorough one provides their own annotated version.
Core Web Vitals and Lighthouse targets. Core Web Vitals aren't aspirational numbers - they're part of how Google evaluates page experience and how users actually experience your store: target LCP under 2.5s, INP at 200ms or less, and CLS under 0.1. In Lighthouse, treat mobile TBT under 200ms as a lab proxy for main-thread responsiveness (TBT is a lab metric, not a Core Web Vital itself). You should receive a performance report for at least three key page templates (home, PDP, and collection) before sign-off.
Cross-device testing on physical hardware. A real iPhone (not Chrome DevTools mobile emulation) and at least one Android device. Emulators miss Safari-specific rendering bugs consistently. If the agency doesn't mention physical device testing, ask.
App conflict testing. If you're running more than six Shopify apps - and most stores are - verify that the custom code doesn't conflict with your existing app scripts, particularly apps that inject content into the cart or checkout.
For custom checkout work, the QA scope expands significantly. Shopify's checkout customisation model now runs through Checkout Extensibility rather than old checkout.liquid theme edits, so any custom checkout UI or workflow needs to be built and validated through extensions before production - a constraint that catches teams off guard when they assume the old theme-editing approach still applies.
Handoff: what you should actually receive
A completed custom Shopify development engagement should hand you:
Source code in a repository you own. Not "we'll push to our GitHub and you can pull from there." Your GitHub org, your repo, your commit history. This matters for auditing, for future developers, and for disaster recovery.
A staging-to-production deployment process you can execute. How do changes get from staging to live without the agency present? If the answer is "drag the theme file in the Themes admin," that's fine for theme-only work - but you need to have done it yourself at least once before the engagement closes.
Credentials and access - transferred, not shared. Any third-party service accounts created during the project (CDN, monitoring, email provider) should be in your billing and under your login, not the agency's. Walk through every external service and confirm ownership before paying the final invoice.
A brief technical handover document. It doesn't need to be long. What's custom vs stock, which apps are configured and how, where to find the theme settings that control key behaviours. One hour of documentation saves ten hours of confusion during the first post-launch change request.
Post-launch: what's included vs what's extra
Typically included in a fixed-price engagement:
Bug fixes for issues directly caused by the delivered work, usually for 14 to 30 days post-launch
One round of minor visual tweaks (button colours, font adjustments) surfaced in the first week
Typically extra:
New feature requests, even small ones
Performance optimisation beyond what was scoped
Support if a third-party app changes its behaviour after launch
The distinction that trips founders: a bug is something that doesn't work as scoped. A change is something that works as scoped but you've decided you want differently. Establish this definition in writing before launch day, not after.
If you need ongoing support after the warranty window, a retainer (fixed monthly hours) is almost always better than time-and-materials for anything requiring quick turnarounds. A typical Shopify support retainer from a senior-led agency runs $1,500 to $4,000/month for 10 to 20 hours, depending on the complexity of your stack.
Red flags to screen for
No staging environment. All work happens directly on a live theme or a Shopify test store, with no separate staging URL. This means QA happens on production - your real customers are the test audience.
"Unlimited revisions." A scope without limits is a budget without limits for the agency. In practice, this usually means unlimited revisions to design-only elements, with functionality changes quietly excluded in the fine print.
Vague timelines. "Four to six weeks depending on complexity" isn't a timeline, it's a placeholder. A serious Shopify development company gives you milestone dates: design approval by X, development complete by Y, QA period by Z.
No written scope before a deposit. If they ask for 50% upfront before delivering a written project spec, the spec is what you're paying to discover. That's a legitimate paid discovery engagement - it's not legitimate when framed as a project kickoff.
Solo developer, no review process. For any engagement above $10,000, you want a team where code gets reviewed before it gets pushed. A single developer with no peer review is a single point of failure - for quality, for knowledge continuity, and for delivery risk.
Questions to ask before you sign
Six questions that separate agencies with a real delivery process from ones building theirs mid-engagement:
Can you show me three Shopify stores you've built in the last 12 months? Ask for live URLs, not screenshots.
What does your QA process look like, specifically? Listen for a device matrix, a payment testing protocol, and Lighthouse targets - not "we test thoroughly."
Who owns the code repository after delivery?
How do you handle scope changes mid-project?
What's included in your post-launch warranty, and what ends it?
Do you use a separate staging environment?
The answers to these six questions will tell you more about an agency's delivery maturity than their portfolio page ever will.
The real question behind the question
Custom Shopify development is worth the investment when the scope is tight, the QA is methodical, and the handoff leaves you able to run the store independently. Most of the disappointment founders report isn't about bad code - it's about an expectation gap that was never closed during scoping. Close it, and the engagement becomes predictable: you know what you're buying, what good looks like at each phase, and what to do when something falls outside the lines.
If you're scoping a Shopify project and want a senior team to sanity-check the brief, technical risk, QA plan, and handoff before build starts, see how BrainFeed approaches Shopify development.
FAQ
What's included in custom Shopify development services?
It depends which of the four types you're buying: custom theme development (Liquid), custom app development (Node/Remix or Rails on the Admin API), a headless storefront (Hydrogen or Next.js on the Storefront API), or custom Liquid sections added to an existing theme. A complete engagement also includes scoping, QA against a defined device and checkout matrix, a handoff with code ownership and credential transfer, and a defined post-launch warranty window.
How much does custom Shopify development cost?
Theme customisation typically runs $2,000 to $8,000, a ground-up bespoke theme $12,000 to $30,000+, a custom app $8,000 to $50,000+, and a headless build $20,000 to $80,000+. Ranges vary by market and complexity; treat any quote that arrives without a discovery call as an estimate against an unknown spec.
How do I tell a good Shopify development agency from a bad one?
Screen for a written scope before any deposit, a real QA process (device matrix, Shopify Payments test-mode transactions, Lighthouse and Core Web Vitals targets), code delivered to a repository you own, and clear post-launch warranty terms. The strongest single signal is whether they can show three live stores built in the last 12 months and describe their QA process specifically rather than saying "we test thoroughly."
What should I receive at handoff?
Source code in a repo you own, a staging-to-production deployment process you can execute yourself, every third-party credential transferred into your accounts, and a short technical handover document explaining what's custom vs stock and where the key theme settings live.
Pratik Talati
Founder, BrainFeed Solutions
15 years shipping product. Senior-led teams, AI-augmented delivery, AU & US clients. I write about the things we ship — and the things we wish we hadn't.
