Quick answer: Pick a ready-made theme if your catalogue is simple and your checkout needs are basic. Pick a custom build if you need page types, content structures or checkout rules that a theme can’t give you. Then hire a team that asks about your goals first, works on a development theme, tests properly and hands over with training.
Last updated: November 2026
If your store needs standard pages and a clean look, a ready-made theme is often enough, and you may not need to hire anyone big. If you need page types, content structures or checkout rules that a theme can’t give you, a custom build is worth paying for, and that’s when choosing the right shopify development agency really matters. This guide helps you decide which side you’re on, then shows you what to ask, what to watch out for, and how to read a proposal.
What should you work out before talking to an agency?
Start by writing down what your store needs to do that it can’t do today. Most brands ask “which agency should we hire?” too early, and that question is much easier to answer once the list exists.
Be specific. “Look more premium” is vague. “Show a size chart that changes by product type” is something a developer can price and build.
When is a ready-made theme enough?
A ready-made theme is enough when your needs are simple and fit inside the theme’s settings. It’s one you install and configure, rather than have built from scratch for you, and for plenty of stores it’s the sensible choice.
It’s usually enough when:
- Your catalogue is simple and your product pages follow one pattern.
- Your brand needs fit within the theme’s colour, font and layout settings.
- You don’t need custom content types beyond what the theme already supports.
- Your checkout needs are basic.
- You’re still testing the product or the market and don’t want to sink money into a build yet.
Here’s a hypothetical. A small shop sells one product line, has a handful of pages, and updates the homepage banner twice a month. A custom theme would add cost and very little value. A well-chosen theme, set up carefully, would do the job.
Ready-made doesn’t mean “no help needed” though. Setting up collections, navigation, product data and tracking properly is real work. A good agency will say so, and will also tell you when a custom build is more than you need. If an agency pushes a full custom build without asking what you’re trying to achieve, that tells you something.
When is custom development worth paying for?
Custom work is worth paying for when the theme is the thing holding you back. It earns its cost by removing workarounds, giving your content a proper home and letting your team make changes alone.
Common signs:
- You keep asking for workarounds, and each one adds clutter.
- Your products need extra information (specs, compatibility, care instructions) that the theme has no place for.
- Different product types need different page layouts.
- Your marketing team wants to build or change pages without waiting on a developer.
- You need features from apps to sit neatly inside your pages, not float awkwardly on top.
If that sounds like you, a serious look at custom shopify development is likely worthwhile. To judge any proposal, though, you need to know a few terms. They’re not hard.
What are templates, sections, blocks and snippets?
They are the building pieces of a Shopify theme, and a good custom build uses them so your team can edit pages without code. Shopify’s own developer documentation describes them like this.
- JSON templates act as a wrapper. They don’t hold code themselves. They list which sections appear on a page and in what order.
- Sections are reusable pieces of Liquid (Shopify’s theme language) that a merchant can add to those JSON templates. Think of a hero banner, a product grid or a testimonial strip.
- Blocks live inside sections. A “slideshow” section might have one block per slide.
- Snippets are reusable bits of Liquid code that developers use behind the scenes. Merchants don’t see them in the theme editor.
Why should you care? Because a custom theme built well gives your team the sections and blocks they actually need. They can rearrange a page, swap content and add a new layout from the editor. No developer ticket needed.
A custom theme built badly hard-codes things that should be editable. Then every small change becomes a paid request. We’ll come back to that in the red flags.
What are metafields and metaobjects?
Metafields and metaobjects are Shopify’s ways of storing extra, structured data beyond the standard fields. This is where custom builds often justify themselves.
- Metafields add a field to something that already exists, like a product, an order or a customer. Example: a “fabric type” field on every product.
- Metaobjects are new record types you define yourself. Example: a size chart, or a store location, that many products can point to.
Both need a definition. According to Shopify’s docs, a metafield without a definition is just a plain string, with no validation and no search. So definitions matter.
In practice, this means your product page can show a size chart, a “what’s in the box” list or a care guide, all pulled from structured data your team edits in the admin. Nobody touches code to update it.
An agency that talks about metafields and metaobjects when it hears your requirements is thinking about how your team will run the store in six months, not just how it looks at launch.
Can your team edit pages without a developer?
Yes, if the build is shaped around them from the start. Ask yourself who changes your site most often. If it’s your marketing team, the theme should be designed around their daily work.
A good custom theme gives them:
- Sections for the page types they use all the time
- Blocks inside those sections so they can adjust content without breaking the layout
- Structured fields for product details
That’s the real return on custom work. It’s not mainly about looks. It’s about how quickly your own team can launch a campaign page, and how rarely they need to ask for help.
How do custom and ready-made themes compare?
Ready-made themes cost less effort up front, while custom themes fit unusual needs better. This table stays at concept level, because costs and timelines vary too much by project to put numbers on them here.
| Question | Ready-made theme | Custom theme |
|---|---|---|
| Starting point | Existing design and structure you configure | Built around your requirements |
| Fit with your brand | Within the theme’s settings | Designed for your needs |
| Content structure | What the theme supports | Sections, blocks, metafields and metaobjects shaped to your content |
| Editing by your team | Works inside the theme’s limits | Can be planned around how your team works |
| Unusual page types | Often need workarounds | Can be built in |
| Upfront effort | Lower | Higher |
| Ongoing dependence on developers | Rises if you keep adding workarounds | Lower if the build is planned well |
| Best for | Simple catalogues, testing a market, tight budgets | Complex products, specific workflows, growing teams |
What does a good Shopify agency actually do?
A good agency follows a clear process: it asks questions first, designs with your sign-off, builds safely, tests, then hands over. That’s how you can separate a real agency from a person who installs themes and calls it a day.
For reference, WebbyTroops says it follows an eight-step process for custom themes. Not every agency will follow the same order, but the ideas are worth looking for in any proposal:
- Discovery. Understanding the business, the store and the goals.
- Requirements and route. This includes confirming that a custom theme is the right call in the first place. An agency that checks this is working for you, not for its own invoice.
- UX and design, reviewed by you. You see and approve the design before development starts. Changing a layout in a design file is far cheaper than changing it in code.
- Development setup with version control and a dev theme. The work happens on a separate development theme, not on your live store. Version control keeps a history of every change. Your live store stays untouched while the build is in progress.
- Building sections, blocks and a content model. The editable pieces we covered earlier.
- Apps through app blocks. Shopify’s theme app extensions let apps add features to a theme without merchants editing Liquid. App blocks get placed inside sections, so features sit where you want them, and they don’t edit your theme code.
- Quality checks. WebbyTroops names Shopify Theme Check, Lighthouse, accessibility checks and full buying-journey testing. Theme Check is Shopify’s open-source linter for Liquid and JSON. It catches things like syntax errors, unused variables and snippets, deprecated tags and performance issues.
- Launch and handover. With training and documentation, so your team can run the thing.
Services matter too. WebbyTroops’ shopify development services page lists custom builds, web design and development, ecommerce store development, theme customization, app integration, migration and upgrade, and maintenance and support. That’s a useful template for what a full-service partner might cover. Ask any agency which of those they handle themselves and which they pass to someone else.
What checkout changes should you ask an agency about?
Ask whether anything on your checkout depends on old checkout code or Shopify Scripts, because Shopify has retired or deprecated several of those tools. Checkout is one area where older stores may need changes, so it deserves its own question when you’re hiring.
Here’s what Shopify has said:
- The older checkout.liquid file is unsupported for the Information, Shipping and Payment steps.
- checkout.liquid and additional scripts were sunset on the Thank you and Order status pages on August 28, 2025.
- For script tags on those pages, Shopify’s documentation gives August 28, 2025 for Plus stores and August 26, 2026 for non-Plus stores. Ask any agency how that applies to your store today, since the date is stated and we can’t confirm how it was applied.
- Shopify Scripts were deprecated as of June 30, 2026. Published Scripts are deactivated, and Shopify points merchants to Functions.
Checkout customisation is now built around checkout extensibility. In Shopify’s documentation, checkout extensions include UI extensions, Shopify Functions, web pixel extensions and payments extensions. Merchants add blocks in the checkout editor.
Shopify Functions are backend logic compiled to WebAssembly. Shopify lists use cases like discounts, payment options, delivery options, checkout validation, bundles, fulfillment constraints and pickup. One rule to know: any plan can use public App Store apps that contain Functions, but only Plus stores can use custom apps containing Function APIs.
So what should you do with this?
If your store ever relied on old checkout code or Scripts, ask any agency you’re considering how they’d handle it today. If your store is new to Shopify, ask what checkout changes you might need and which of them can be done with an existing app versus something custom. Whichever shopify website development company you speak to should be able to explain this in plain language, without hiding behind jargon.
When the answer is a custom app, it helps to know the agency can build one. WebbyTroops’ Shopify app development page mentions Functions and checkout extensions, and a free recommendation on whether an existing app, a Shopify setting or a custom app is the best fit. That “check before you build” habit is the one you want from anyone.
Do you need a headless storefront?
Only if a Liquid theme can’t meet a specific requirement of yours. Headless means the storefront is built separately from Shopify’s theme system, and it adds complexity.
WebbyTroops says a custom Liquid theme suits most stores, and offers headless only when a fully custom, multi-channel experience is needed. That’s a sensible position. We don’t have data to say how many stores need headless, but the logic holds: more moving parts mean more to build, test and maintain.
If an agency recommends headless, ask:
- What specific requirement can’t be met with a Liquid theme?
- What will we own and maintain afterwards?
- How will our team edit content?
If the answers are vague, treat that as a warning.
What should you ask an agency before you sign?
Ask about fit, build, quality, checkout and the working relationship. Use these in your first calls. Good agencies enjoy them.
About the fit – Based on what we’ve told you, do we need a custom theme? What would you do if we said no to a custom build? – Which of our requirements can be met with settings or an existing app?
About the build – Will you work on a development theme with version control, so the live store isn’t touched? – How will our team edit pages, and which sections and blocks will you create? – Which custom data will you set up as metafields or metaobjects? – How do you handle apps, and do you use app blocks?
About quality – Do you run Theme Check, accessibility checks and full buying-journey tests before launch? – How do you look at speed during the build, not only at the end?
About checkout – Does anything on our current checkout depend on checkout.liquid or Scripts? – What’s your plan for checkout extensions or Functions?
About the relationship – What do we receive at handover? Training? Documentation? – Who supports the store after launch, and how quickly do they respond? – Who owns the code?
Picking a shopify ecommerce development company is partly about skill and partly about how they talk to you. Notice whether they answer the question you asked, or the one they’d rather answer.
What are the red flags in a proposal?
The biggest red flags are a custom build recommended before any questions, no testing plan, no checkout answer and no handover. Proposals look polished even when they’re thin, so watch for these.
- No discovery step. If they haven’t asked about your goals, how can they know what to build?
- A custom build recommended before any questions. It’s hard to trust a recommendation that skips your goals.
- No mention of a dev theme or version control. That raises the risk of changes landing on your live store.
- Hard-coded content. If every banner or product detail needs a developer, the theme isn’t built around your team.
- No QA section. Testing should be named, not assumed.
- Nothing about checkout. In 2026 this is a gap.
- No handover. If you get a live store but no training or documentation, you’re stuck depending on them.
- Vague scope words. “Fully customised,” “best practices” and “premium experience” mean nothing without detail.
- Guarantees nobody can keep. No agency controls search rankings, or promises exact speed scores. Be wary of anyone who says otherwise.
One more note. Pricing is hard to compare because agencies package work differently. WebbyTroops, for instance, doesn’t publish pricing, so ask for a scoped quote. In any case, ask what’s included rather than only asking for a number.
How do you judge a proposal’s scope?
A good proposal tells you what you’re getting, what you’re not, and what happens if things change. Check these four things, and ask what’s included, such as data migration, content entry and redirects. If it isn’t written down, assume it isn’t.
1. Deliverables you can point at. A list of page templates, sections, custom data definitions and integrations. “Homepage, collection, product, cart, plus these three custom sections” beats “full theme build.”
2. Design sign-off points. You should approve the design before the build starts, not after.
3. Testing and launch. Look for named checks and a launch plan. A good one includes what happens if something breaks after going live.
4. After launch. Is there a support period? Is there a maintenance option? Shopify changes. Its API releases a new version every three months, and each stable version is supported for at least 12 months. So somebody has to keep an eye on things if your store uses custom apps. That’s why ongoing support is worth discussing early.
Speed is worth a line in scope too. If you care about page speed, check whether the proposal covers it during the build or leaves it as an afterthought. A separate Shopify speed optimisation project may be a better fit if the store is already live and slow.
What should be on your hiring checklist?
Use this one before, during and after your agency calls. Print it, or paste it into a doc.
Before you talk to agencies – [ ] I’ve written down what the store can’t do today – [ ] I know who edits pages most often – [ ] I know whether we use anything old at checkout
During calls – [ ] They asked about our goals before recommending a solution – [ ] They said clearly whether a custom theme is needed – [ ] They explained sections, blocks and custom data in plain words – [ ] They mentioned a dev theme and version control – [ ] They had an answer on checkout extensions and Functions – [ ] They said when headless would and wouldn’t make sense
In the proposal – [ ] Clear deliverables and exclusions – [ ] Design review before build – [ ] Named QA steps, including accessibility and buying-journey testing – [ ] Handover with training and documentation – [ ] Support after launch – [ ] Code ownership stated
Before you sign – [ ] I’ve compared at least two proposals line by line – [ ] I understand what I’ll be able to change myself
So, should you go custom or ready-made?
Go ready-made if your needs are simple, and custom if your products, content or workflows keep fighting the theme. If your needs are simple, start with a ready-made theme and spend your budget on getting the basics right. If they aren’t, plan a custom build, and choose an agency that can explain every step in plain words.
If you want to talk it through, WebbyTroops offers a free 30-minute strategy call on its Shopify pages, and says it responds within two business hours. Bring your list of “what the store can’t do today.” That’s usually enough to tell you which path makes sense.
Key takeaways
- A ready-made theme fits simple catalogues, basic checkout needs and early testing. A custom build fits stores where the theme keeps getting in the way.
- Sections, blocks, metafields and metaobjects are what let your own team edit pages and product data without a developer.
- Ask every agency about checkout: checkout.liquid, Scripts, checkout extensions and Shopify Functions all come up in 2026.
- Look for discovery, design sign-off, a development theme with version control, named testing and a proper handover in any proposal.
- WebbyTroops doesn’t publish pricing, so compare scope line by line and ask for a scoped quote.
Frequently asked questions
Is a ready-made Shopify theme enough for my store?
It is often enough when your catalogue is simple, your product pages follow one pattern and your checkout needs are basic. It also suits stores that are still testing a product or market. Setup still takes real work, including collections, navigation, product data and tracking, so a good agency can help even without a custom build.
When is a custom Shopify theme worth the cost?
It is worth it when the theme is holding you back. Typical signs are repeated workarounds, products that need extra information the theme has no place for, different layouts for different product types, and a marketing team that wants to change pages without a developer. Costs vary by project, so ask for a scoped quote.
What changed with Shopify checkout in 2025 and 2026?
Shopify says checkout.liquid and additional scripts were sunset on the Thank you and Order status pages on August 28, 2025. Shopify Scripts were deprecated as of June 30, 2026, published Scripts are deactivated, and merchants are pointed to Functions. Checkout customisation is now built around checkout extensions, which merchants manage with blocks in the checkout editor.
What is the difference between metafields and metaobjects?
Metafields add a field to something that already exists, such as a product, an order or a customer. Metaobjects are new record types you define yourself, such as a size chart or a store location. Both need a definition. Per Shopify’s docs, a metafield without one is just a plain string, with no validation and no search.
What should a good Shopify proposal include?
A good proposal lists deliverables you can point at, design sign-off before the build, a development theme with version control, named testing such as Theme Check and accessibility checks, a launch plan, and a handover with training and documentation. It should also say what happens after launch, including any support period, and what is not included.
