Private dashboards, product logic and integrations built around a real merchant workflow—not custom software for its own sake.
Every custom app is a permanent maintenance liability. It has to be worth one.
Most requests that arrive as “we need an app” are really requests to work around a catalogue, theme or process problem, and there is usually a cheaper way.
Before anything is built, the same three questions get asked. Can the catalogue be modelled differently so the requirement disappears? Can a metafield, a metaobject or a theme section carry it? Is there an established app on the Shopify App Store that already does this, maintained by someone whose entire business is keeping it working against platform changes?
If any of those is a yes, that is the recommendation, and it is usually the recommendation. A monthly subscription to a mature app is almost always cheaper over three years than owning code that has to be re-tested every time Shopify deprecates an API version.
What survives that filter is a narrow category: product, order or operating logic that Shopify has no native concept of, where the rules are specific to how this business works and cannot be forced into a general-purpose subscription.
The right surface depends on whether the problem sits with the customer, the merchant or the operation.
Scoping an app means naming which of these it needs. Each one adds review surface, testing surface and maintenance, so the list is kept as short as the requirement allows.
A focused interface for staff work Shopify admin was not designed to carry: production planning, packing, stock controls, labels or merchant-specific review queues.
Admin GraphQL, OAuth, signed webhooks and scheduled synchronisation move the right products, orders and inventory between Shopify and the private tool, with ownership and failure handling stated.
Bundle components, box multipliers, delivery dates, production quantities and stock write-back are translated explicitly rather than hidden in staff memory or a spreadsheet.
Where the customer journey needs it, theme app extensions, metafields and Shopify Functions put the interface and logic in the platform instead of bolting fragile scripts onto a theme.
The fewer of these a requirement needs, the better the answer is.
Private software for the work that starts after a cheesecake order is placed.
For Cheshire Cheesecakes, we built a private Shopify-connected operations dashboard that interprets bundle orders and delivery dates, then turns them into the information the kitchen needs to make and pack the order.
The app reads Shopify locations, products, variants, inventory and orders through Admin GraphQL. It separates actual bake units from bundle wrappers, delivery lines, add-ons and personalisation, then resolves box sizes and flavours into the quantities the kitchen works with.
Delivery and dispatch dates become daily and weekly bake lists, packing sheets and a four-week view of booked demand. Recipe data produces ingredient requirements and unit costs, while configurable print controls produce product labels with ingredients, allergens, nutrition, storage and batch details supplied by the merchant.
When staff enter finished stock, the app translates that count back into availability for mapped single products and box variants. New, changed and cancelled orders are handled through signed webhooks, with a scheduled full sync as the fallback rather than the only line of defence.
This is repository evidence of implemented capability, not a claim about saved time, reduced waste or commercial results. Those outcomes are not published without merchant-approved proof.
Three columns, because the answer is usually not the first one.
| Requirement | Usually the right answer | Why |
|---|---|---|
| Reviews, loyalty, subscriptions, back-in-stock | An established App Store app | Mature products with dedicated teams maintaining them against platform changes. Rebuilding one trades a known fee for an unknown liability. |
| Specification data, filtering, richer product content | Metafields, metaobjects and theme work | Native structures the storefront, the admin and search can all read. No app, no subscription, no upgrade risk. |
| A configurable bundle that must ship as its components | A custom app with a Cart Transform function | Shopify has no native concept of a configured box, and the warehouse needs component-level line items to pick against. |
| Orders that must become production, packing or labelling work | A private Shopify-connected operations app | The workflow belongs behind the storefront and needs merchant-specific rules, staff controls and outputs rather than another theme screen. |
| Pricing, stock or fulfilment rules specific to the business | A custom app, or the back-office system | If the rule belongs to the business rather than the storefront, it should live where every other system can reach it, not inside a theme. |
| Connecting Shopify to another system you already run | An integration, not an app | A data flow between two systems is scoped around ownership and failure handling, which is a different project with a different shape. |
Where the honest answer is an existing app, that is what we will say, and there is no charge for saying it.
App projects fail in the specification, not in the implementation.
These are answered in writing, because each one is expensive to change once the data model exists and merchants have configured against it.
The last two are the ones most often skipped. An app nobody can deploy and nobody can test is a store outage waiting for a platform update.
Custom apps do not sit still. Platforms move underneath them.
Shopify versions and deprecates its APIs on its own schedule. A custom app is only as safe as the arrangement for keeping it current, and that arrangement is agreed before the first line is written rather than discovered at the first breakage.
The code, the repository, the Partner account and the deployment path belong to the client. Nothing is held in an account only we can reach, and nothing about leaving is designed to be inconvenient.
Maintenance is a named responsibility, which can be ours through ongoing capacity, an internal team’s, or a third party’s. What it cannot be is unassigned. An app with no maintenance owner works perfectly until the quarter it does not.
The Cheshire Cheesecakes build, drawn as one system rather than described as one.
Shopify
Shopify storeLocations, products, variants, inventory and ordersShopify to Private operations app
Read through Admin GraphQL, with signed webhooks for new, changed and cancelled orders and a scheduled full sync as the fallback.
Private operations app back to Shopify
Finished stock entered by staff is written back as availability for mapped single products and box variants.
Private operations app
Private operations app to Kitchen operations
Delivery and dispatch dates resolved into what the kitchen has to make and pack.
Kitchen operations
This is repository evidence of implemented capability. No claim is made here about saved time, reduced waste or commercial results.
Published starting figures in GBP and USD, excluding VAT.
Scoped after the selling model is written down
One bounded piece
£1,500$2,000
One bounded improvement: landing pages, a template rebuild, an analytics implementation, or a build-readiness review credited against a larger project.
Fixed price
Plus, B2B, multi-market
From £8,000From $10,500
Shopify Plus, B2B, multi-market, multi-language, custom integrations or headless work. These configurations are sized after discovery, not instant-priced.
Starting price · scoped after discovery
Maintenance against platform changes
Per month
From £1,250From $1,650
A live improvement programme on one site. You set the priorities each month, we work the queue in order, and the month closes with what changed and what it did.
Starting price
Per month
From £3,000From $4,000
Continuous delivery across an agreed portfolio, with planning ahead of the work rather than a queue you have to keep feeding.
Starting price
App work is scoped after the selling model, the surfaces and the fulfilment requirement are agreed. A published figure before that would be a guess, and app guesses are wrong in one direction only.
A custom or private app is installed on your store only, so it skips App Store review and can be shaped entirely around how you trade. A public app is a product sold to many merchants, which is a different business with listing requirements, support obligations and a review process attached.
It can, which is why the surfaces are kept minimal. Theme app extensions load as part of the theme, and Shopify Functions run inside the platform rather than as an external call at checkout. Anything that would put a network round trip in the buying path gets challenged before it is built.
Usually, starting with a review of the code, the data model and the deployment path. Inheriting an app without that review is how a small change turns into an unplanned rebuild, so the review is a short bounded piece of work on its own.
Because that gets checked first. Bundles, mix-and-match and product personalisation all have established App Store options, and for most catalogues one of them fits. Bespoke work earns its place when the configuration rules and the fulfilment requirement are specific enough that no existing mapping holds.
What the customer does, what the team has to do next, and which rules are unique to the business. That is usually enough to say whether this is custom software, an integration or an existing subscription.
