Skip to content

( /shopify-development )

Shopify development

  • 01Builds on Liquid
  • 02Apps and integrations
  • 03Maintained past launch

Carrtel Solutions is a Shopify Partner. We build stores on Shopify.

Shopify development, built to survive the next platform change

Shopify retires things on a schedule and publishes the dates in advance. A store with no in-house developer finds out when something breaks instead, because those dates are published in a developer changelog nobody on the merchant's side is reading. We build stores, apps and integrations, and we track that calendar as part of the work.

  • Store builds on a Liquid theme, Online Store 2.0 structure throughout
  • Custom apps and the order plumbing between Shopify and your back office
  • Hydrogen and headless: assessment and maintenance, not greenfield rebuilds
  • An inventory of every dated surface your store depends on, at handover
Run the free scanSee what it costs
The short answer

What Shopify development covers here, and what it costs

Carrtel Solutions is a Shopify Partner. We build stores on Shopify and the order-and-tracking plumbing behind them: a store build on a Liquid theme starts at $4,900 and covers 40 hours of build — one paid theme, up to 8 templates, up to 200 products imported — a migration onto Shopify is that build plus a $2,600 add-on for the data job, so $7,500 for a full replatform, and the Order-Ops Build between Shopify and an ERP, 3PL or accounting system starts at $3,900. Theme customisation, Online Store 2.0 sections and custom single-store apps are scoped per engagement. Hydrogen and headless we assess and maintain; we do not build new ones for small merchants. Every project carries a 30-day bug warranty, and ongoing work is $299/mo or $1,290/mo.

Last updated: August 2026

The capability

What we build, and what we decline to build

Six things. Three of them come with a published price and the scope that goes with it. One of them is a capability we will actively talk you out of buying.

01

Store builds on a Liquid theme

From $4,900 · 40 hours

A working storefront on a Liquid theme, structured the Online Store 2.0 way: JSON templates, sections on every template, and settings your merchandising team can move without opening a ticket. One paid theme, up to 8 templates, up to 200 products imported, standard payments and shipping, two revision rounds, and a 30-day bug warranty on what we delivered.

How we do it

We start from a well-maintained theme rather than a blank file. A theme with an active vendor gets updates when the platform moves; a bespoke theme written from nothing gets updates when you pay for them. Where the theme cannot do the thing, we write the section, and we write it with a schema so the next change is a settings change.

See the full price list
02

Theme customisation and Online Store 2.0 sections

Scoped per engagement

The work of turning a purchased theme into your store: custom sections and blocks, template-level layouts, metafield-driven content, and merchandising controls that do not require a developer to use.

How we do it

The rule we hold to is that content belongs in settings and metafields, not in markup. A section with a schema can be rearranged, duplicated and re-themed by the person who owns the storefront. A hardcoded block can only be changed by someone who can read Liquid, which means every seasonal change becomes an invoice.

03

Custom Shopify apps

Scoped per engagement

A custom app installed on your store — not a public App Store listing. Admin API access with named scopes, webhook subscriptions, background jobs, and an admin surface where one is genuinely needed.

How we do it

Every app we write pins its API version in exactly one place and carries a note about when that version ages out. Every scope is named to the feature that needs it, so the access list is auditable by someone who is not a developer. If a public app already does the job, we will tell you to buy it instead.

04

Hydrogen and headless

Assessment and maintenance only

We assess an existing headless storefront and we maintain one. We do not sell greenfield headless rebuilds to small merchants, and the reason is arithmetic rather than taste.

How we do it

Hydrogen is Shopify’s React framework for custom storefronts, built on React Router 7 and deployed to Oxygen. It is a real tool with a real audience. That audience is not a store doing $80,000 a month with no in-house developer.

Why we say no, in full
05

Platform migration

Plus $2,600 on a build

Moving a live store onto Shopify from WooCommerce, Magento, BigCommerce, Wix or Squarespace. It is a line item on a build rather than a product of its own — up to 20 hours, up to 5,000 products and 10,000 historical orders, a full 301 redirect map, and a data-integrity reconciliation at the end that you can read. A full replatform is $7,500.

How we do it

The part that goes wrong in migrations is never the products. It is the URLs, the historical orders, the customer records with no password to carry over, and the analytics baseline that resets to zero on cutover day and takes your ability to compare anything with it.

How a migration runs
06

Order operations integration

From $3,900

The Order-Ops Build: the plumbing between Shopify and your ERP, 3PL or accounting system. Idempotent ingestion keyed on order id, a reconciliation ledger, and an exception queue that someone actually watches.

How we do it

Webhook delivery is at-least-once and unordered. A receiver that answers 200 and then throws internally loses the order in silence, and neither side has any way to notice an absence. Integrations that survive are the ones built on that assumption from the first line.

What the bridge covers
The frame

Shopify deprecates things on a schedule

The dates are public. The failure is not that the platform surprises anyone, it is that the announcement lands in a developer changelog and your store does not have a developer.

A store is a stack of dependencies with expiry dates on them, and almost none of those dates live anywhere the owner can see. An API version your middleware is pinned to. A tag pasted into a settings box that is being retired. An app that injects a script into a surface the platform is moving away from. Each one is fine until the day it is not, and each one was announced months ahead in a place built for developers.

None of this is a criticism of Shopify. A platform that never deprecates anything is a platform that stops improving. The obligation the schedule creates is real, though, and somebody has to carry it.

Six dated surfaces, and what replaced them

( 06 )

01

checkout.liquid

Retired

Replaced by Checkout UI extensions, Shopify Functions, and web pixels

This one was never yours — checkout.liquid was a Shopify Plus file, and the stores this page is written for are on Basic, Grow or Advanced. We list it because it is the cleanest worked example of what a platform retirement is: an entire customisation surface, announced with a date, removed on that date, and replaced by something a different shape rather than a drop-in.

02

Additional Scripts on the order status page

Retired in the same move

Replaced by Customer events and web pixels, sandboxed, subscribing to a defined event stream

This is the one that did apply to your plan. If a conversion tag, an affiliate postback or a post-purchase survey was pasted into that box, it was running on the single page that fires once per completed order. A sandboxed pixel cannot reach the page and cannot make arbitrary calls, so a tag that worked by touching the DOM does not move across. It has to be rebuilt, and until it is, that measurement is simply gone.

03

App-injected script tags

Being displaced

Replaced by Theme app extensions and app blocks

A script tag is invisible in the theme editor and outlives the app that created it. An app block is a thing the merchant can see, move and delete. The direction of travel is away from code an app injects behind your back and toward code you can point at, and anything still relying on the old shape is on borrowed time.

04

Private apps and older credential schemes

Replaced

Replaced by Custom apps with access tokens and named access scopes

Credentials issued under an old scheme stop being issued first and stop working later, which is a long gap in which nothing appears to be wrong. An integration a contractor wrote three years ago authenticates with whatever was normal three years ago, and nobody has opened it since the week it shipped.

05

Admin API versions

On a fixed schedule, permanently

Replaced by A new version each quarter, each supported for a minimum of twelve months — per Shopify’s API versioning documentation

This is the deprecation that never ends. Your app or middleware is pinned to a version, that version ages out, and a field you depend on is renamed, restructured or removed in the version you are forced onto. Nothing on the store warns you. The call starts returning something slightly different, or stops returning.

06

Vintage themes

Superseded

Replaced by Online Store 2.0: JSON templates, sections everywhere, app blocks, metafield definitions

A vintage theme still works, which is exactly why so many are still running. It also cannot accept an app block, so every app added since gets pasted in by hand. That is how a theme accumulates a hundred lines nobody can attribute to anything, and why a theme update becomes a project instead of a button.

How a store usually finds out

Not with an alert. Deprecations rarely produce a crash, because the replacement behaviour is usually valid behaviour. Three shapes are worth knowing, because each one goes wrong quietly in a different way.

A number goes quiet

Conversions in an ad platform drop and stay down. It looks like a soft month, so it is discussed as a soft month. The optimiser, meanwhile, treats the smaller number as true and bids away from audiences that are no longer being measured. By the time anyone checks the tag, the account has been learning from a partial signal for weeks.

A rule stops matching

A discount, a shipping rate or a validation was keyed on something the platform now supplies differently, or no longer supplies. The rule still runs. It matches nothing, returns no operation, and that is a valid result. Checkout completes without it, which means nothing errors and nothing alerts.

An error lands in a log nobody opens

The integration starts returning a version error on a field that moved. Retries run, then stop. Shopify is fine, the storefront is fine, and only the receiving system is short — and a receiving system has no way to know what it never received. Support absorbs the difference one ticket at a time.

What we do instead

Tracking the calendar is not clever. It is clerical, and being clerical about it is the entire trick.

A written inventory of every dated surface

At handover you get a list: every API version anything of yours is pinned to, every app that injects code into your theme or checkout, every metafield namespace a rule depends on, and every credential and the scheme it was issued under. One page. It is the document that makes the next change a task instead of an investigation.

A calendar entry, not a memory

When we pin an API version we write down the quarter it ages out, and that date goes in a calendar rather than in someone’s head. Shopify publishes its changelog and its version support window in the open. The information has never been the hard part; noticing it on a Tuesday in month fourteen is.

The quarterly upgrade lives in a retainer

Doing the upgrade is ordinary work. Remembering to do it, forever, is the part that fails. The quarterly API-version upgrade is included in Care Plan — Operate at $1,290/month, along with the middleware itself. If you would rather own it in-house, take the inventory and do exactly that — it is yours either way.

One thing worth saying plainly: none of this locks you in. The inventory, the runbook and the code are yours at handover whether you keep us or not. A retainer should be something you renew because it is doing work, not because leaving is expensive.

The mechanism

Seven build decisions, and the failure each one prevents

None of these cost more on the day. They cost less in month fourteen, which is the only place the difference shows up.

  1. 01

    One constant names the API version

    What it prevents

    A version string scattered through fourteen files means an upgrade is a search-and-hope exercise, and the one occurrence you miss is the one that fails in production four months later.

  2. 02

    App blocks and theme app extensions, never pasted snippets

    What it prevents

    A pasted snippet survives uninstalling the app it belongs to. Orphaned code either double-fires an event — which inflates your conversions and reads as good news — or throws and takes down every tag queued behind it.

  3. 03

    Metafield definitions with stable, documented namespaces

    What it prevents

    Functions and extensions bind to a declared input query against specific metafields and owner types. Rename a namespace in a bulk edit and the function receives null where it expected a value, then correctly does nothing.

  4. 04

    Receivers idempotent by order id, with a record of what arrived

    What it prevents

    Delivery is at-least-once and unordered. Without idempotency a retry writes the order twice; without a delivery record nobody can ever answer the question of what did not arrive, because an absence leaves no trace to count.

  5. 05

    Theme changes in version control, with a changelog

    What it prevents

    Edits typed straight into the code editor at 6pm are unattributable by the following month. When a tag stops firing, the first question is what changed and when, and a theme with no history cannot answer it.

  6. 06

    Every access scope named to the feature that needs it

    What it prevents

    A scope list nobody can explain is a scope list nobody will ever reduce. Naming each one to a purpose means access can be reviewed, narrowed and revoked by someone who does not write code.

  7. 07

    Nothing new is built on a surface already announced as going away

    What it prevents

    It is faster on the day and it is a rebuild inside a year. If the only way to hit a deadline is to build on something with a retirement date, we say so in writing before you decide, rather than after.

If a store you already own does none of these, that is not an argument for rebuilding it. It is an argument for reading it first. The free Store Scan does that from the outside, and fixing the first named thing it turns up is the $690 Fix Sprint. Where the whole money path needs reading, that is tracking and checkout integrity.

Order operations( 03 )
Core systems

Your store is not the only system that thinks it knows what happened.

This is the shape of the connection we build: what leaves Shopify, what comes back, and which system is allowed to be right. Every lane runs both ways — that is exactly why they drift.

Source

Shopify Admin API

GraphQL + webhook events

  • ERP

    Enterprise resource planning

    Shopify sends
    orders, refunds, customer records
    Shopify receives
    inventory levels, catalogue updates

    The ERP usually already owns stock and pricing. Before any code is written we write down which side is authoritative for each field — a two-way sync without that answer is a loop.

  • 3PL / fulfilment

    Warehouse and fulfilment provider

    Shopify sends
    fulfilment requests, cancellations
    Shopify receives
    tracking numbers, stock movements

    The pick happens in a warehouse. Shopify only learns about it if something tells it, and a status that never came back is the same to a customer as a parcel that never shipped.

  • Accounting

    Ledger, invoicing and payouts

    Shopify sends
    orders, refunds, payout records
    Shopify receives
    posting and reconciliation status

    Refunds and adjustments are where the three systems most often stop agreeing, because each one applies them on its own clock. They get reconciled rather than assumed.

What we build into every lane

  • Ingestion that tolerates a retry

    Shopify re-sends a webhook it never got a success response for. Handled once, keyed on the event, so a retry cannot create a second fulfilment.

  • A replay path, not guesswork

    Every message is logged on arrival. When one never showed up, it gets re-sent from the log instead of rebuilt by hand from a spreadsheet.

  • A reconciliation ledger

    Both sides of each lane are compared on a schedule. Disagreements land in an exception queue with the record attached, rather than surfacing later as an oversell.

  • Versioned against the platform

    Shopify retires Admin API versions on a published schedule. The integration is moved to the next version before the one it runs on goes away.

This describes how we build the connection, not something a merchant has already measured — we have no case studies yet. The full order-operations scope

Worked example( 04 )

One order, end to end.

This is the shape of a build, not a case study. An order arrives, the stock is checked where the stock actually is, and the customer hears about it before they think to ask.

  1. 01

    The order lands

    Checkout completes and Shopify fires its orders/create webhook. The flow starts from that payload, so it runs on the order itself rather than a job that sweeps the store every few minutes and hopes.

    Trigger · orders/create webhook

  2. 02

    Stock is checked at the warehouse

    Each line item is matched to the 3PL’s own SKU — warehouse codes almost never match Shopify’s handle — and read against live stock, so the answer comes from the shelf and not from the store’s cached quantity.

    Check · line items vs 3PL stock

  3. 03

    It commits, or it stops

    One clean pick and it continues. Short stock, or a split across two warehouses, and it holds the message and raises the order for a person — the step that keeps automation from confidently promising a date nobody can keep.

    Decide · continue or hand to a human

  4. 04

    The customer gets a text

    Twilio sends one plain message with what is shipping and when it leaves. This is the step that already runs live on our own system today — text only, no voice call.

    Send · Twilio SMS

Honest about what exists: the Twilio message in step four is built and running on our own system today. The Shopify and warehouse steps are built per store, against the APIs your platform and your 3PL already expose — which is why we look at both before quoting the work. No merchant results are claimed here, because we have none to claim yet.

Hydrogen and headless

We will not sell you a headless rebuild

Hydrogen is Shopify's React framework for custom storefronts, built on React Router 7 and deployed to Oxygen. It is a serious tool with a real audience. That audience is a store with an in-house frontend team and enough traffic that a fraction of a percent of conversion pays for one.

Our rule of thumb, not an industry statistic

Below roughly $5M USD a year in revenue, the payback on a greenfield headless build does not work. The build costs a multiple of a Liquid build, and the ongoing obligation it creates does not go away afterwards. This is our own threshold, applied to our own work. Treat it as a judgement, not a finding.

Going headless does not remove work. It moves work off Shopify's roadmap and onto your payroll. Everything the platform was doing for free in the background becomes something you own, budget for and staff. Checkout stays Shopify's either way, so the part of the funnel that decides whether an order happens is not the part you gained control of.

What you take on

  • The theme editor. Merchandising changes stop being drag-and-drop and become developer tickets with a queue in front of them.
  • App blocks and theme app extensions. Every app that would have dropped into your theme now needs a custom integration, and some apps have no headless path at all.
  • A deploy pipeline, hosting, preview environments and a build that someone has to own for as long as the store exists.
  • One codebase becomes two, and both have to be kept current against the same quarterly platform schedule.
  • The hiring pool. A Liquid theme can be picked up by a large number of contractors. A bespoke React storefront can be picked up by the people willing to read it first.

What you genuinely gain

  • Real control of the frontend, including a performance ceiling a theme genuinely cannot reach.
  • One frontend serving several storefronts, locales or brands from shared components.
  • Rendering and interaction patterns that Liquid cannot express, where those patterns are load-bearing for the business rather than decorative.
  • Freedom from theme-vendor timelines when the storefront is the product rather than the packaging.

What we do take

Assessment

You inherited a headless storefront, or you are being sold one. We read it: what it is pinned to, what it would cost to keep current, what breaks at the next quarterly version, and whether moving back to a Liquid theme would serve you better. Sometimes the answer is to retire it, and we will say so.

Maintenance

If it is worth keeping, we keep it current: dependency and framework upkeep, the Storefront API surface it depends on, the deploy path, and the same quarterly version discipline we apply to everything else.

If you are a store doing $80,000 a month and someone has quoted you a headless rebuild, get a second opinion. It does not have to be ours.

Your storefront( 01 )

What the free scan can already name inside a storefront

These are apps our scanner fingerprints from what your storefront serves publicly. Detection is not an integration — it is how the scan tells you what you are running before anybody quotes you anything.

Detected by the free scan

Our scanner reads what your storefront already serves publicly and names the apps it finds. Detection is not an integration — it is how the scan tells you what your store is running.

  • Klaviyo
  • Gorgias
  • Recharge
  • Yotpo
  • Judge.me
  • Okendo
  • Postscript
  • Attentive
  • Loox
  • Stamped

43 app signatures in total, including analytics tags, page builders, subscriptions, loyalty and buy-now-pay-later.

Nothing in this strip is an integration claim, and no vendor here is a partner of ours. If an app you depend on is not on the list, the scan still reads the storefront around it and reports what it could not see.

Run the free scan
Pricing

Every price, and what each one buys

All prices in Canadian dollars. Flat-scope items are a flat price; the rest publish a starting point and the scope it buys. Anything outside that scope is quoted at $120/hour and approved in writing before it starts.

01

Free Store Scan

About 90 seconds

Free

Self-serve, no signup, no app install. Reads your public storefront and reports what is visible from the outside.

02

Fix Sprint

5 business days

$690

One named problem, up to 5 hours, one revision round. The paid entry point is work rather than a document.

03

Restoration Sprint

7 business days

$2,400

The bigger remediation job: event wiring, orphaned scripts, checkout-side behaviour, webhook delivery.

04

Store Build or Rebuild

40 hours of build

From $4,900

One paid theme, up to 8 templates, up to 200 products imported, standard payments and shipping, two revision rounds.

05

Migration add-on

Up to 20 hours

Plus $2,600

A line item on a build, not a product: up to 5,000 products and 10,000 historical orders, including URL redirects. Build plus migration is $7,500.

06

Order-Ops Build

Scoped per integration

From $3,900

Shopify to your ERP, 3PL or accounting system: idempotent ingestion, reconciliation ledger, exception queue.

07

Care Plan — Watch

Ongoing

$299/mo

Daily money-path checks, a weekly reconciliation receipt, an exception queue, and 2 hours of work each month. Hours do not roll over; extra hours are $120. Cancel any time with 30 days notice, no cancellation fee.

08

Care Plan — Operate

Ongoing

$1,290/mo

Everything in Watch, plus maintained middleware, the quarterly API-version upgrade, and 8 hours of work each month. Same 30 days notice, no cancellation fee.

The scan is free

The Store Scan is free, self-serve, and does not sit behind an email. The paid entry point is work rather than a document: the $690 Fix Sprint, one named problem, up to 5 hours, 5 business days.

Three projects at a time

We run a maximum of three concurrent projects. That limit is the reason a delivery date means anything.

Overage is quoted first

Change orders and work beyond a published scope are $120/hour, scoped and approved in writing before anyone starts. If a flat-scope job is going to run long, we tell you before hour 6. We never send a surprise invoice.

See the full price list
The store build

What $4,900 includes, and what it does not

40 hours of build. One paid theme, up to 8 templates, up to 200 products. Most builds land between $4,900 and $7,700. The right-hand column is the one worth reading twice.

Included

  • One paid theme, licensed by you, set up and structured rather than written from nothing
  • Up to 8 templates: home, collection, product, cart, search, and the content pages you name
  • Up to 200 products imported, with options, variants and metafield-driven detail
  • Standard payments and shipping configured, and two revision rounds
  • Online Store 2.0 structure throughout: JSON templates, sections everywhere, app blocks
  • Custom sections written with a schema, so content changes stay in settings
  • Analytics and conversion tracking wired through customer events, verified against orders before launch
  • Redirects for any URL that changes, and a launch checklist run in front of you
  • The dated-surface inventory, the scope list, and a written handover
  • 30-day bug warranty on defects in what we delivered

Not included

  • Brand identity design: logo, naming, brand system. We do not sell that.
  • Copywriting and product photography. We will lay out what you supply.
  • Paid media and SEO retainers. Not our line of work.
  • Third-party app subscriptions, theme licences and platform fees, which you buy directly.
  • Defects inside third-party apps. We identify them, document them and chase the vendor. We cannot patch someone else’s code.
  • What pushes it above $4,900: custom sections beyond those 8 templates, product data we have to clean, a custom app or integration, more than two revision rounds, content we have to write.
  • Anything past the published scope. It is quoted as a named line item at $120/hour and approved in writing before it starts.
  • Shopify Plus enterprise bids, and greenfield headless rebuilds for small merchants.
How it runs

From first call to handover

( 04 steps )

  1. 01

    A scope call, then a written scope

    We look at the store, the apps, the theme and whatever sits downstream of an order. You get a fixed scope with a fixed price and a named delivery date, or you get told this is not work we should take.

  2. 02

    The free scan first, then one named problem

    Anything that touches tracking, checkout behaviour or order flow starts with the free Store Scan, because tuning anything to a store we have not read is decoration. The first paid step after it is work rather than a document: the $690 Fix Sprint covers one named problem and up to 5 hours, delivered in 5 business days with one revision round.

  3. 03

    Built in weekly increments against the date

    Weekly, you see what moved and what is left. Change requests are quoted before they are started, never absorbed quietly and never invoiced as a surprise. Overage and change orders are $120/hour.

  4. 04

    Handover, then your choice

    You get the code, the inventory of dated surfaces, the scope list and the runbook. You can take that in-house, hand it to another developer, or keep us on a retainer. Nothing we build requires us to keep existing.

The questions worth asking us

  • What timezone overlap do we actually get?
  • Who owns the code, and how do I leave?
  • What happens when a change request lands mid-build?
  • What access do you need, and can I revoke it myself?
All of it, answered
The commitment

What we stand behind, stated plainly

30-day bug warranty

Defects in work we delivered are fixed at no charge for 30 days after delivery.

25% credit on a missed date

If we miss an agreed delivery date, you get a 25% credit toward the next engagement. A credit, not a cash refund.

Three projects at a time

We run a maximum of three concurrent projects. That limit is why the dates are meetable in the first place.

Exclusions

The warranty and the credit do not cover defects inside third-party apps, delays on your side (access, approvals, content, decisions), or platform incidents. None of those are ours to control, so we do not price as though they are.

Who this is for, and who it is not for

( Fit )

A good fit

  • A live store past product-market fit, roughly $40k to $400k USD a month
  • On Basic, Grow or Advanced, running a Liquid theme
  • No in-house developer, so nobody currently owns the platform calendar
  • A store somebody else built and then stopped maintaining
  • At least one system downstream of the order: an ERP, a 3PL, accounting, a subscription tool
  • A migration onto Shopify where the URLs and the historical data have to survive

Not a fit

  • Shopify Plus enterprise bids. We do not take that work.
  • Greenfield headless rebuilds for a small merchant.
  • Paid media or SEO retainers, and brand identity design.
  • Dropshipping store spin-ups.
  • A store still searching for product-market fit. The money is better spent finding demand than protecting it.
  • Anyone who needs a portfolio of client results before they will start. We do not have one yet, and we will not manufacture one.

On that last one: we would rather lose the deal than borrow someone else's results. Here is what you can verify about us instead.

Common questions

( 11 )

01
What does Shopify development mean here?
Carrtel Solutions is a Shopify Partner. We build stores on Shopify: store builds on a Liquid theme (from $4,900, which covers 40 hours of build), theme customisation and Online Store 2.0 sections, custom apps installed on a single store, platform migrations onto Shopify (a build plus a $2,600 migration add-on, so $7,500 for a full replatform), and the order-operations plumbing between Shopify and an ERP, 3PL or accounting system (from $3,900). We also assess and maintain existing Hydrogen storefronts, though we do not build new ones for small merchants. All prices are in Canadian dollars.
02
What does "built to survive the next platform change" actually mean?
It means the store is built so that a known, dated platform change is a scheduled task rather than an outage. Concretely: the API version is named in one place with the quarter it ages out written next to it, app code lives in app blocks and theme app extensions rather than pasted snippets, metafield namespaces are documented because Functions and extensions bind to them, webhook receivers are idempotent by order id, and every theme change is in version control with a changelog. You also get an inventory of every dated surface your store depends on at handover, whether or not you keep us on afterwards.
03
How often does Shopify change something that can break a store?
Continuously, on a schedule that is published in the open. Shopify releases a new Admin API version each quarter and supports each version for a minimum of twelve months, per its own API versioning documentation, so an integration left alone will eventually be running against a version that no longer exists. Separately, whole customisation surfaces get retired with notice: checkout.liquid and the Additional Scripts box on the order status page both went that way in the move to checkout extensibility. The information is public. The failure mode is that nobody on a merchant’s team is reading a developer changelog.
04
Will you build me a headless or Hydrogen storefront?
Not from scratch, if you are a small or mid-size merchant. Hydrogen is Shopify’s React framework for custom storefronts, built on React Router 7 and deployed to Oxygen, and it is a good tool for the stores it is aimed at. Going headless moves work off Shopify’s roadmap and onto your payroll: you lose the theme editor, you lose app blocks, you gain a deploy pipeline and a second codebase, and every app you add becomes an integration project. Our own rule of thumb — not an industry statistic — is that the payback does not work below roughly $5M USD a year in revenue. Above that, a fraction of a percent of conversion pays for a team, and the maths changes. Below it, you are buying a maintenance obligation with somebody else’s enthusiasm.
05
I already have a Hydrogen storefront. Can you help?
Yes, and this is the headless work we do take. We assess an existing headless storefront honestly: whether it can be maintained, what it is pinned to, what it would cost to keep current, and whether moving back to a Liquid theme would serve you better. If it is worth keeping, we maintain it — dependency and API-version upkeep, the Storefront API surface it depends on, and the deploy path. We will tell you plainly if the recommendation is to retire it.
06
Do you build public apps for the Shopify App Store?
No. We build custom apps installed on one store, with named access scopes and a pinned API version. A public listing is a product business with its own review process, support burden and roadmap, and it is not what we sell. If a public app already does what you need, the honest answer is to buy it, and we will say so.
07
Can you take over a store somebody else built?
Yes. It starts with the free Store Scan rather than with a quote, because we will not price work on a store we have not read. The scan is self-serve, takes about 90 seconds, needs no signup and no app install, and reports what is visible from the outside. From there the first paid step is work rather than a document: the $690 Fix Sprint fixes one named problem in 5 business days, and a larger remediation job is the $2,400 Restoration Sprint. Anything bigger is quoted as a named line item before it starts.
08
What is included in the $4,900 store build, and what is not?
From $4,900 covers 40 hours of build: one paid theme, up to 8 templates, up to 200 products imported, standard payments and shipping, two revision rounds, Online Store 2.0 structure with custom sections written as schemas, conversion tracking wired through customer events and verified against orders before launch, redirects for any changed URL, a written handover with the dated-surface inventory, and a 30-day bug warranty. What pushes it up: custom sections beyond those 8 templates, product data we have to clean, a custom app or integration, more than two revision rounds, content we have to write. Each is quoted as a named line item, before we start, at $120/hour. Most builds land between $4,900 and $7,700. Not included at all: brand identity design, copywriting, product photography, paid media, SEO, third-party app subscriptions and theme licences, and defects inside third-party apps.
09
What is the guarantee, exactly?
A 30-day bug-fix warranty on project work: defects in what we delivered are fixed at no charge for 30 days after delivery. If we miss an agreed delivery date, you get a 25% credit toward the next engagement — a credit, not a cash refund. We run a maximum of three concurrent projects, which is the reason the dates are meetable at all. The warranty and the credit exclude defects inside third-party apps, delays on your side such as access, approvals, content or decisions, and platform incidents. None of those are ours to control, so we do not price as though they are.
10
Who is this for, and who is it not for?
It is for a live Shopify store past product-market fit, roughly $40,000 to $400,000 USD a month, on Basic, Grow or Advanced, running a Liquid theme, with no in-house developer. It is not for pre-launch stores, and we do not take Shopify Plus enterprise bids, greenfield headless rebuilds for small merchants, paid media or SEO retainers, brand identity design, or dropshipping store spin-ups.
11
Can I see case studies?
No, because there are none. Carrtel has no published client results, and we are not going to invent any or dress up a portfolio with work that is not ours. What you can check instead: every price we charge is published in full, the free Store Scan runs against your own store before you pay anything, the scope and the exclusions are written down before you sign, and the guarantee is stated with its exclusions attached. That is what we ask you to judge us on until there is something real to show.

Estimate, not a promise

Do the maths with your own numbers.

Put your figures in and the arithmetic is printed underneath, one line at a time, with every rate we assumed shown as a control you can move. If you think an assumption is wrong, change it — the estimate is yours, not ours.

Your figures

Nothing is sent anywhere. This runs in your browser and we never see what you type.

Your revenue on a typical order, before shipping and tax.

Visits, not visitors — the sessions figure in your analytics.

Emails, chats and DMs a person currently has to answer.

Estimated — from your inputs

Revenue recovered

$717

per month — about 9.0 orders

Support hours saved

12.0

hours per month — about 120 messages

These are two different kinds of number, so we do not add them together into a single headline figure. Both are estimates produced by the arithmetic below from the figures you entered — not a result any store has reported to us.

The arithmetic

Abandoned checkout recovery

  1. 20,000 sessions × 4%= 800 checkouts started
  2. 800 × 70%= 560 abandoned
  3. 560 × 20%= 112 we may contact
  4. 112 × 8%= 9.0 orders back
  5. 9.0 × $80= $717 per month

Support message deflection

  1. 400 messages × 30%= 120 answered automatically
  2. 120 × 6 min ÷ 60= 12.0 hours per month

Every assumption, and where it comes from

We have set each of these at or below the published industry averages we could find, because an estimate you can disprove in thirty seconds is worth less than a modest one you can believe. Disagree with any of them and move it — the numbers above follow.

4%

Published storefront conversion averages sit in the low single digits; reaching checkout is a little more common than completing. Your own analytics will beat this guess — use it.

70%

Published industry averages cluster around seventy percent. We start at the bottom of that band rather than the top.

20%

Only the shoppers who left a phone number and agreed to be contacted. This is a consent limit, not a traffic limit, which is why it is a small fraction.

8%

Set below the recovery rates commonly published for email cart flows, because a call reaches far fewer people than a send-all email does.

30%

The repetitive ones: where is my order, what is the return policy, does this ship to me. Helpdesk vendors advertise higher; we do not.

6 min

Reading, looking the order up, writing back, and the switch of attention either side of it.

What the assistant does

When a shopper leaves a checkout having given you a phone number and agreed to be contacted, the assistant follows up in their own words — answers the question that stopped them, shipping cost, delivery date, sizing, returns — and sends them back to a live checkout link. The support side answers the repetitive messages from the same order data, and hands anything it should not be answering to a person.

Contact is limited to shoppers who consented to it, which is exactly why the contactable share above is a fraction rather than everyone who abandoned.

What this number is not

  • It is not a result. We have no merchant outcomes to report and we do not borrow anyone else's.
  • It does not separate the shoppers who would have come back on their own. Some of them would have. Treat the recovery figure as the optimistic end of a modest range.
  • It is not a quote. It excludes what the work costs — every price we charge is published in full on the pricing page.
  • It is in whatever currency you were thinking in. The model never converts and never assumes one.

Start at the free end

Read the store first, then decide what to build

The Store Integrity Scan reads your public storefront in about 90 seconds, with no signup and no app install. It will not tell you everything. It will tell you whether the theme is carrying scripts from apps you no longer have, and that is usually enough to know which conversation to have next.

Two ways in

Store Integrity Scan

Free, self-serve, no signup and no app install. About 90 seconds.

Run the free scanSee every price

Or email support@carrtelsolutions.com