Building a Shopify app: what it takes to ship one merchants keep

If you run a courier, a payments service, a warehouse or a loyalty product, the merchants you want are already inside Shopify admin all day. An app puts your service where they work instead of asking them to copy order details into your portal. That is the whole argument for building one — and it is a good one.

It is also a different kind of project from a website. We built the Fez Delivery app for a Lagos courier: local and international deliveries, smart-locker options, live rates, labels and tracking, all inside the store admin. Here is what that work involves.

What a service app has to do well

• Show accurate rates when they matter. Rates depend on destination, weight and the merchant's own agreement with you, and the request comes with a short deadline. Slow or wrong here and the merchant uninstalls.
• Create the shipment from the order, with no re-typing: pickup location, contact, items, weight, delivery option.
• Produce the paperwork. Labels and manifests that print correctly, in bulk, on the printers people actually own.
• Report status back. Tracking and proof of delivery where both the merchant and the customer can see the same thing.
• Handle more than one location, because stores that grow ship from several places.

The parts teams underestimate

1. Authentication and sessions. OAuth, session tokens and embedded admin rules are prescribed by the platform, and they change. This is not where you innovate.
2. Webhooks and reconciliation. Orders get edited, cancelled and refunded. If your app only listens for creation, your records drift from the store's within a week.
3. API limits. Bulk actions across thousands of orders need queues and backoff, not loops.
4. Billing. Charges go through the platform's billing API, with plans, trials and upgrades handled the way it expects.
5. Review and requirements. The App Store has performance, privacy and data-handling requirements, and listings are checked before they go live. Build for those from the start rather than fixing them in week ten.
6. Support. Merchants write to you, not to Shopify. Budget for it.

The listing decides your installs

Your listing is a shop window: the name, the description a merchant scans in ten seconds, and screenshots of the real screens. One warning from experience — use test data in those screenshots. Real orders in a screenshot mean a customer's name, phone number and address are published in a public listing, which is both a privacy problem and an easy one to avoid.

Cost and timeline drivers

A single-purpose app with one integration is a small project. What extends it: the number of merchant-facing screens, how much configuration each store needs, whether you support multiple currencies and languages, how deeply you touch checkout, and how much of your own API already exists and is documented. If your service has no API yet, that work comes first — usually as a backend project before any app code is written.

Do you need an app or a store?

These are opposite jobs. If you are selling your own products, you want a store built well — start with Shopify or WooCommerce. If you provide a service that merchants plug in, you want an app. Logistics and fulfilment businesses in particular should read it as a distribution decision: see the logistics work we do.

Thinking about one? Tell us what merchants would use it for and we will scope it honestly, including what you can leave out of version one.

Selling into more than one country? See what a store needs to sell across the US–Canada border.