Skip to main content
← Work

Shopify custom systems case study

MP Health: Squarespace to Shopify with a Custom Medical Inventory System

How a medical clinic moved to Shopify and connected each sellable IV treatment to the multiple inventory components it consumes, with POS, local discovery, and mobile UX in the same scope.

Updated August 202610 minSamuel Noriega
Samuel Noriega
By

Published

ShareXLinkedIn

Reading brief

What you will get from this guide

How a medical clinic moved to Shopify and connected each sellable IV treatment to the multiple inventory components it consumes, with POS, local discovery, and mobile UX in the same scope.

What this case demonstrates

How Shopify was adapted to a service business where one purchased treatment consumes several underlying inventory components and transactions also happen in clinic.

Who this is relevant for

Service businesses and specialty merchants evaluating Shopify where standard one-product/one-stock-unit inventory does not match the real operating model.

MP Health did not need Shopify to behave like a conventional retail catalog. The clinic sells IV treatment packages where one customer purchase can consume several underlying medical inventory components. A storefront that only decremented one finished product would show the wrong stock picture to the team.

The project migrated MP Health from Squarespace to Shopify in a recorded 4–6 week fixed-scope engagement, created custom inventory logic for IV packages, integrated the system with Shopify POS for in-clinic use, and included local SEO, schema markup, and mobile UX improvements.

Project outcomeRecorded result
Source platformSquarespace
DestinationShopify
Delivery window4–6 weeks
Inventory modelOne IV sale can deduct multiple component items in real time
In-clinic commerceShopify POS integrated
Acquisition layerLocal SEO and schema optimization
Customer experienceMobile UX improvements

No traffic, revenue, or conversion percentage is added to this case because those figures are not part of the verified project record. The value here is operational: the commerce system was adapted to how the clinic actually consumes inventory.

The core problem was inventory truth

Standard ecommerce inventory assumes a relatively simple relationship: sell one product, reduce the quantity of that product by one.

An IV treatment package can work differently. The item purchased by the customer is a service or treatment bundle, while the clinic may consume several underlying components to deliver it. Those components can also be shared by different treatments.

If the storefront only tracks the sellable package, the visible stock level can diverge from the physical supplies required to fulfil the next appointment.

That creates real operating problems:

  • a treatment may appear available while one required component is depleted;
  • staff may need to reconcile package sales against supplies manually;
  • online and in-clinic sales can create competing inventory records;
  • purchasing decisions become harder because the commerce layer does not reflect what is actually being consumed.

For MP Health, the migration therefore had to begin with the inventory relationship, not with the theme.

Why moving from Squarespace to Shopify mattered

Squarespace can serve a content-led website well, but MP Health needed a commerce system that could support custom inventory behavior and connect online transactions with in-clinic selling.

The move to Shopify created a stronger transaction and inventory foundation while still allowing the clinic's website to explain services, support local discovery, and work cleanly on mobile.

The decision was not “Shopify has more ecommerce features.” It was more specific: the destination needed to let the clinic model the gap between what a patient buys and what the business consumes to deliver that treatment.

That is the type of requirement that should determine a platform migration.

Mapping the treatment to its underlying components

The key custom behavior was the relationship between an IV treatment package and the inventory items it uses.

A customer may purchase one treatment, but the fulfilment event needs to update several component quantities. The commerce system therefore has to understand that the sellable item is not the entire inventory unit.

The custom logic created a real-time deduction model: when the relevant IV treatment is purchased, the defined underlying components are reduced accordingly.

This is operationally different from a cosmetic bundle. The purpose is not simply to display several products together. The purpose is to keep the stock record aligned with what the clinic physically uses.

That distinction matters because inventory accuracy is a service-availability issue. If a required component is unavailable, the clinic may not be able to deliver the treatment represented by the package.

One stock model across online and in-clinic sales

MP Health also needed Shopify POS for in-clinic use.

Without a connected point of sale, the business could end up with two partially independent transaction systems: one for online purchases and another for purchases or treatment activity at the clinic. That would weaken the value of the custom inventory logic because component consumption would need to be reconciled across channels.

Integrating Shopify POS brought in-clinic commerce into the same operating environment as the online storefront.

The customer-facing benefit is consistency. A patient can interact with the brand online or at the clinic while the team works from a more unified record of commerce activity.

The internal benefit is more important: the system has a better chance of reflecting what is actually available because transactions are not being split across unrelated inventory ledgers.

The migration had to preserve the service business, not mimic the old pages

A Squarespace-to-Shopify project can be mishandled if the goal becomes reproducing each page exactly in a new editor.

For MP Health, the useful migration question was what the new system needed to support after launch:

  1. treatments had to remain understandable to prospective customers;
  2. online purchasing needed to connect to the clinic's inventory reality;
  3. in-clinic transactions needed to participate in that same system;
  4. local search signals had to help nearby customers understand the business;
  5. mobile visitors needed a cleaner route through treatment information and action.

Those requirements turn a website migration into an operating-system change.

A 4–6 week fixed-scope delivery

Shopify's Partner Directory records the project as completed in a 4–6 week fixed-scope engagement.

A defined scope was particularly important because custom inventory work can expand quickly if every clinical or administrative workflow is treated as part of the ecommerce rebuild.

The project centered the requirements that directly affected the Shopify operation: migration, treatment/package inventory behavior, POS integration, local SEO, schema, and mobile UX.

That bounded approach makes the timeline more meaningful. It describes a specific commercial implementation rather than an open-ended digital transformation claim.

Local SEO was part of the customer journey

MP Health is a clinic, so customer acquisition is geographically different from a national ecommerce brand.

A prospective customer may search for a treatment and location together, compare nearby options, check credibility, then decide whether to book, buy, call, or visit. The storefront therefore needs to communicate both the service and the local business context clearly.

The project included local SEO optimization and schema markup as explicit workstreams.

The role of structured data was to reinforce visible business and service information in a machine-readable form. It was not a shortcut to rankings. The more important work was ensuring that the site's content, location context, service information, and technical signals agreed with one another.

For a clinic, that alignment helps search engines and customers answer the same basic questions: what is offered, where it is offered, and what action should happen next.

Mobile UX mattered because local intent is often mobile intent

The project also included mobile UX improvements.

That matters for a clinic because local searches frequently happen on a phone. A prospective customer may be comparing services while away from a desktop, checking details shortly before visiting, or moving between a search result, map listing, and the clinic website.

The mobile experience therefore needs to reduce friction around the information that drives action. Treatment explanations, availability context, trust signals, and calls to action should not be buried under a desktop-first layout.

The goal was not simply to make Squarespace pages responsive inside Shopify. It was to make the new commerce experience easier to use in the context where customers are likely to encounter it.

The custom logic was designed around a business rule

Custom development is most valuable when it represents a rule the business cannot safely ignore.

In this case, the rule was simple to state but important to implement: selling one IV treatment must deduct the multiple inventory components required to deliver it.

That is a better reason for custom code than adding novelty to the storefront. The feature exists because the standard one-product/one-stock-unit assumption does not match the clinic's operation.

The implementation creates a clearer relationship between commerce events and inventory events. It reduces the amount of knowledge that staff must carry manually outside the system.

What the project changed for MP Health

The verified result is not a vanity metric. It is a more coherent operational model.

After the migration, the Shopify environment could support:

  • a treatment storefront on a commerce-focused platform;
  • component-level inventory deductions tied to IV package purchases;
  • in-clinic transactions through Shopify POS;
  • local SEO and schema improvements around customer discovery;
  • a mobile experience refined for the new storefront;
  • a completed migration inside the recorded 4–6 week scope.

That combination connected the website more closely to the way the clinic delivers its services.

Why we are not attaching an invented revenue lift

A case study does not need a percentage to be commercially useful.

For MP Health, the strongest evidence published in Shopify's Partner Directory is the project scope and the operating capability delivered. We do not have a verified post-launch traffic, revenue, or conversion figure in the source used for this case, so we do not add one.

The customer result is that Shopify was made to represent a non-standard inventory model and to connect that model with clinic POS activity.

For another business with a similar problem, that evidence may be more relevant than a generic conversion claim.

What this case does and does not prove

This case demonstrates that Shopify can be adapted to a service business where the sellable package and the consumed inventory units are not the same thing, and that the storefront and POS can be designed around one commerce environment.

It does not imply that Shopify should replace a medical practice-management system, clinical record system, or regulated healthcare workflow. The case is specifically about ecommerce, inventory logic, POS, local discovery, and storefront UX.

It also does not mean every component-inventory model can be implemented identically. The right architecture depends on how packages, components, refunds, adjustments, substitutions, and stock ownership work in the specific business.

What a similar service business should define first

Before moving a non-standard service catalog to Shopify, the team should document the inventory rule in plain language.

Ask:

  1. What does the customer buy?
  2. What physical items are actually consumed when that purchase is fulfilled?
  3. Can those components be shared across several sellable services?
  4. Which transactions happen online and which happen in person?
  5. Which system should be authoritative for inventory after each transaction?

MP Health's migration worked because the implementation was oriented around that business rule. Shopify was not asked to force the clinic into a standard retail model; the commerce layer was adapted to the operation the clinic already needed to run.

Sources and evidence

Public references and project data used to validate the context, scope, and published outcomes in this case study.

Continue exploring

Commerce that matches operations

Model the business rule before choosing the app stack.

We scope the inventory relationship, transaction channels, system ownership, failure cases, and storefront requirements before custom Shopify development begins.

Request a systems scope
ShareXLinkedIn
On this page