DEV Community: Jobs Yang

Shopify or Medusa? A framework for choosing your DTC e-commerce stack

Jobs Yang — Fri, 30 Oct 2026 04:02:54 +0000

"We're building our own online store. Should we use Shopify or build it ourselves?" This is the question we get asked most. The usual answers are "Shopify is easier" or "open source gives you freedom". Both are true, and neither is enough to make the decision.

This article gives you a framework you can apply directly. We build both Shopify stores and headless storefronts on MedusaJS, and we've hit the pitfalls on both sides, so we try not to favor either.

What the two routes actually are

Shopify / Shopify Plus: a SaaS e-commerce platform. The storefront, checkout, payments, inventory and orders are all hosted by the platform. You customize the storefront with themes (Liquid) and extend functionality with apps and APIs. Shopify Plus is stronger on multiple stores, checkout customization and automation, and is aimed at larger brands.

Headless / composable storefront (MedusaJS as the example): the shopping front end is decoupled from the core commerce services (products, orders, payments, membership and so on). The back end is built on an open-source commerce framework with custom APIs, a database and object storage; the front end is developed separately and can be designed and iterated freely. You own the code, data and hosting, and there's no platform commission. The cost is that you (or your agency) are responsible for deployment and operations.

Six questions to decide

1. How well does your business process fit the platform?

Ask yourself: can Shopify's standard flow cover 80% or more of how you take orders, fulfill them and handle after-sales?

If it can, go with Shopify. The remaining 20% can usually be covered with theme customization and custom apps. We built a full Shopify site for an energy storage brand whose products ranged from EV chargers sold directly at retail to containerized storage systems that need an inquiry. Retail products are bought directly, large storage products go through downloads and inquiries, and the whole information architecture of 4 product lines and 11 subcategories lives in Shopify. There was no need to build a custom stack.

If your core process is different from standard e-commerce, such as custom quoting, multi-party fulfillment or complex membership tiers, the platform will keep holding you back. That's when to consider headless.

2. How deep does your customization really need to go?

Many teams overestimate how much customization they need. You can do more at the Shopify theme level than you might think. For a smart fitness equipment brand, we built a complete loyalty program inside the Shopify theme: member center, points for tasks, points history, coupon redemption and linking to the brand's app account. All 6 sub-pages are built on custom sections and Alpine.js with no third-party loyalty app, and they're live on the US and EU stores.

The test isn't "do we want customization" but "does the customization touch checkout and the core data model". For storefront experience and surrounding features, Shopify is enough. To change checkout logic or the data model itself, Shopify Plus solves part of it; beyond that is headless territory.

3. Data ownership and long-term cost

On Shopify, your data lives on the platform. You can export it through the API, but your business logic is tied to the platform, and platform fees and app subscriptions grow with GMV.

A headless storefront has no platform commission and your data sits in your own database, but you carry the cost of servers, operations and ongoing development. That's not a one-off investment; it's a long-term need for engineering capacity.

A simple rule: if you don't have, and don't plan to have, a technical team (in-house or a long-term agency), don't go headless.

4. Multiple markets and localization

Both routes support multiple languages, currencies and markets.

Shopify Markets lets you configure currency, domain and pricing per country. For the energy brand we set up two markets, the US (USD) and India (INR), with India on its own domain and hreflang configured. These are standard platform features.

A headless setup gives you more freedom over localized content, tax rules, shipping strategy and regional marketing. It suits brands whose markets differ a lot and need deep regional operations.

5. Integration with internal systems

At a certain size, the store has to connect to your ERP, CRM and inventory systems: update stock in real time to avoid overselling, sync customer data to the CRM and send orders back to the warehouse.

On the Shopify route, this is done with custom apps built on the API that sync orders, inventory, products and customer data both ways with your internal systems, with encrypted communication and role-based permissions. Surrounding systems (product center, order center, shipping management, reporting, ad cost analysis, supply chain management) can be built outside the store and exchange data with Shopify through the API.

On the headless route, these integrations are part of your own back end: payments can integrate Stripe, PayPal and local payment methods with order validation and fraud checks; logistics can connect to carriers, warehouse systems and shipping rules with shipment status sync and tracking. You get more freedom, but every integration is code you have to build and maintain.

6. Time to launch and where your team is today

Shopify can go from zero to live quickly with almost no operations work. Headless takes longer from design through development to deployment, and after launch someone has to own access control, backups, log monitoring and staged rollouts.

If your team is just starting and needs to validate the market, choose Shopify. If you already have steady sales, know what you need and are ready to invest long term, then consider headless.

A decision table

Your situation	Leans toward
Standard e-commerce flow, want to launch fast	Shopify
Need custom storefront experience, loyalty, marketing modules	Shopify + theme / app customization
Multiple stores, checkout customization, automation	Shopify Plus
Business process differs a lot from standard e-commerce	Headless
Sensitive to data ownership and platform fees, have a tech team	Headless
No tech team	Shopify

Common misconceptions

"Shopify is slow, so we need our own stack": most Shopify performance problems come from theme code, too many third-party app scripts and unoptimized images. All of these can be fixed at the theme level without switching platforms
"Open source is free": the framework is free; the engineering isn't
"Start on Shopify and migrate later": you can, but migration cost grows with your data volume and customization depth, so think through your direction for the next two to three years when you first choose

Our advice

Understand your business stage and team first, then pick the solution. Don't pick the technology first and look for reasons afterwards. If you're unsure, write down your order flow, your current systems and your goals for the next two years, then go through the six questions above one by one. The answer usually becomes clear.

One more thing that often gets overlooked: launch isn't the finish line. Whichever route you take, the store will need troubleshooting, new features and performance work after launch. Decide up front who will own that, whether it's an in-house team, a long-term agency or the platform's support. That answer often decides which route to take.

FXTech is an e-commerce technology agency and Shopify Partner based in Shenzhen, China. We build Shopify / Shopify Plus stores and headless DTC storefronts on open-source frameworks such as MedusaJS, optimize web performance and build cross-border VAT compliance systems. Shopify services: https://fxweb.dev/shopify/ . Headless storefronts: https://fxweb.dev/ecommerce/ . Case studies from this article: https://fxweb.dev/cases/#shopify-loyalty-program and https://fxweb.dev/cases/#energy-storage-shopify-store .

Automating tax calculation from Amazon VAT reports: a system design for VAT service providers

Jobs Yang — Fri, 30 Oct 2026 03:57:20 +0000

For firms that provide cross-border VAT services, the most labor-intensive step usually isn't registration. It's calculating tax every filing period. Sellers send over their Amazon VAT Transactions Report, and accountants sort it in Excel by country, rate and deductible item, then copy the numbers into each country's return. With more countries and more sellers, both the error rate and the turnaround time go up.

We built an online platform for a cross-border tax compliance provider covering VAT registration and agent transfer, tax calculation, filing and payment, EPR and authorized representative services. This article covers only the tax calculation part: how the system turns an Amazon report into numbers ready to file. It should be useful for VAT service providers and tax agents who want to turn their service into a product.

The input: how the Amazon report is structured

The Amazon VAT Transactions Report has one row per transaction. Each row includes the transaction type, who collects the tax (Amazon or the seller), whether the buyer gave a valid VAT number, the ship-from and ship-to countries, the tax rate, gross and net amounts, currency and other fields.

Calculating tax comes down to deciding, for each row, "in which country, as what kind of supply and at what rate is this sale reported", then totaling by country and filing period.

Core design: classify first, then calculate

Instead of writing rules country by country, we first put every transaction into one of 7 sales categories. The classification combines three fields:

Tax collector: Amazon collects (as the deemed supplier) or the seller self-reports
Buyer VAT number: whether the buyer is a business with a valid VAT number
Ship-from / ship-to country: domestic sale, intra-EU cross-border sale or export outside the EU

Combined, these put each transaction into a category such as domestic sale, intra-EU distance sale, supply to a VAT-registered business, export or marketplace-collected. Each category has a fixed treatment: some are charged output tax at the local rate, some are reported at zero rate and listed separately, and for marketplace-collected sales the seller pays no further tax but still has to report them.

The benefit is that country differences collapse into one table of "how each country treats each category", instead of being scattered across hundreds of if-else branches. Adding a country means filling in that table.

The system has built-in cross-border rules for all 27 EU member states. Tax calculation is live for the UK and 8 EU countries: Germany, France, Italy, Spain, Poland, the Czech Republic, the Netherlands and Austria.

Input tax: C79, C88 and PVA

UK import VAT is the part most often missed, so the system handles three kinds of documents separately:

C79: the import VAT certificate issued by HMRC, which is the basis for reclaiming import VAT. The system collects C79 amounts per filing period and counts them as input tax
C88: the import declaration, used to reconcile import value and tax, and part of the supporting evidence
PVA (Postponed VAT Accounting): the seller pays no VAT at import and instead reports the same amount as both output and input tax on the return. The system puts PVA amounts in both boxes; the net effect is zero, but it must be reported

None of these are in the Amazon report, so sellers upload them separately. In the filing workspace they are separate items with reminders when something is missing.

The output: UK VAT Return boxes

The UK VAT Return has fixed boxes (Box 1 to Box 9) for output tax, EU acquisitions tax, input tax, net tax, total sales and purchases, and intra-EU supplies and acquisitions. Once transactions are sorted into the 7 categories and C79 / C88 / PVA are processed, every box can be derived directly, without an accountant reconciling spreadsheets by hand.

For the 8 EU countries, the system outputs totals that match the structure of each country's return.

Currencies and exchange rates

The currency of a transaction in the Amazon report isn't always the filing currency. The system fetches exchange rates daily and converts each transaction at the rate for its date. The rate source and conversion date are stored with each calculation so reviewers can trace them.

Workflow: tax calculation inside the filing workspace

Tax calculation isn't a standalone tool; it's one step in the filing workflow. The workspace moves through these states: awaiting report upload → awaiting tax confirmation → awaiting submission → being filed by the accounting firm → awaiting payment → filed.

Seller side: upload the Amazon report and deduction documents, see the calculated tax, confirm and submit
Operations side: review calculations and filings, manage payment proofs and receipts, with role permissions and audit logs

With tax calculation inside the workflow, sellers see "how much is due this period and why" instead of an Excel file they have to interpret themselves.

Engineering safeguards

Mistakes in tax data are expensive, so we put several safeguards in place:

20 end-to-end automated tests covering the main calculation paths
A database schema comparison before each release so migrations don't drop fields
Calculation results keep the mapping from original rows to totals, so a reviewer can trace any total back to individual transactions

The platform went through 300+ iterations in about 4 months, with about 44 business pages, 77 API endpoints and 19 data models. The stack is React 19 + TypeScript + Koa + MySQL, with Alibaba Cloud for OCR and object storage.

Advice for VAT service providers

If you're thinking about turning manual tax calculation into a system, start here:

Write your tax rules as a "category × country" table first. It takes no code, but it exposes the gray areas in your rules
Model deduction documents separately from marketplace reports; they come from different sources on different cycles
Make every result traceable to individual rows, so reviewers are willing to sign off
Start with the UK and one or two EU countries, get the workflow running, then add countries

FXTech is an e-commerce technology agency and Shopify Partner based in Shenzhen, China. We build VAT compliance systems for VAT service providers, tax agents and cross-border e-commerce teams (we don't file taxes ourselves), and also build Shopify stores and headless DTC storefronts and optimize web performance. Case study: https://fxweb.dev/cases/#vat-compliance-saas . VAT solutions: https://fxweb.dev/vat/ .

How we cut a B2B site's TTFB from 17.96s to 0.94s without a rebuild

Jobs Yang — Fri, 30 Oct 2026 03:43:07 +0000

When we took on performance work for an LED lighting manufacturer's export website, the homepage took more than ten seconds to load on our first visit. The network wasn't the problem. The site was: the web server was in Germany, the database was in Hong Kong, the homepage banner was a video of almost 40MB, and images had no responsive variants. On mobile, first paint took tens of seconds, and some admin queries timed out with 502 errors.

Problems like these are common on PHP export sites, and most of them don't require rebuilding the site. Below is the full order in which we diagnosed and fixed them, so you can check your own site step by step.

What we measure

We optimize around Core Web Vitals, Google's set of metrics for real user experience: LCP (Largest Contentful Paint, when the main content appears), INP (Interaction to Next Paint, how fast the page responds to a click) and CLS (Cumulative Layout Shift, whether the page jumps around). Add TTFB (Time to First Byte) and these four metrics usually tell you whether the problem is on the server, in asset size or in front-end code. They affect bounce and conversion rates, and they are one of the signals search engines use for ranking.

For tooling, Lighthouse and PageSpeed Insights give lab data, while the Chrome UX Report and real user monitoring (RUM) show what happens in production. Lab data locates the problem; field data confirms the business impact. You need both.

Step 1: measure before you touch anything

Don't change things on instinct. We ran Lighthouse three times each on the homepage and a product page and took the median as the baseline:

Homepage, desktop: score 56, LCP 6.5s
Product page, desktop: score 44, CLS 0.287
Homepage TTFB: 17.96s
Homepage image download on mobile: 22.7MB
Homepage video size: 38.8MB

With these numbers, every later step can be judged on whether it's worth doing and whether it worked.

Step 2: high TTFB means look at the server path first

A TTFB of almost 18 seconds means the problem happens before the browser receives the first byte. It has nothing to do with front-end assets. We traced the request path and found the site running on a server in Germany while its MariaDB database sat in Hong Kong. Every page request queried the database across continents, and a single page can run dozens of queries, so the latency stacked up.

The fix was simple: move the database onto the German server itself and remove the intercontinental round trips. After this step, homepage TTFB dropped from 17.96s to 0.94s, ten admin requests went from 208.7s in total to 12.1s, and the query that used to time out with a 502 now returns in 1.43s.

Lesson: if your TTFB is above one second, first check whether the database and application server are in the same data center, then look for slow queries. Many export sites were built in stages, and the server moved while the database stayed behind.

Step 3: the video was the largest single asset

The homepage banner video was encoded in HEVC and weighed 38.8MB. HEVC has patchy browser support, and here it didn't even make the file smaller. We transcoded it to H.264 at 720p, added a poster image and lazy loading, and the mobile video size dropped to 2.73MB.

Three points matter:

Choose the resolution for the size it's actually displayed at; a banner doesn't need 4K
Always set a poster image, otherwise LCP waits for the first video frame
Only load the video when it's needed; use the poster as the above-the-fold placeholder

Step 4: responsive images instead of one image for every screen

The homepage downloaded 22.7MB of images on mobile because phones were fetching the full-size desktop originals. The fix:

Resize images on the fly with an image CDN, outputting different sizes by request parameter
Use srcset so the browser picks an image by screen width
Serve WebP
Add width / height placeholders so the page doesn't jump when images load (the main source of CLS)
Load images only when they enter the viewport

Afterwards, mobile homepage image download fell from 22.7MB to 241KiB, a 99% reduction. Product page CLS went from 0.287 to 0.008, mostly thanks to the width / height placeholders.

Step 5: JavaScript, caching and fonts

What remained was standard front-end cleanup:

Merged 17 JS files into 4 and added defer so they don't block rendering
Versioned static assets by file modification time with long CDN caching, so files cache for a long time but users never get stale ones after an update
Restored font-display: swap so text shows in a system font first and swaps to the custom font when it loads, instead of leaving users staring at blank space
Enabled Brotli compression on the server

We also scanned all 187 pages for JavaScript errors on desktop and mobile. Performance work touches a lot of code, and an error scan is the safety net against making the site faster and breaking features.

Results

Lighthouse desktop (median of three runs):

Homepage 56 → 88, LCP 6.5s → 1.5s
Product page 44 → 91, CLS 0.287 → 0.008

We didn't rebuild the site at all. The stack is still PHP + ThinkPHP + MariaDB + Nginx; we just fixed each layer's problems one by one.

After the work: preventing regressions

The most common ending for performance work is that the site is slow again three months later: someone uploads a 5MB original image, or a developer adds another third-party script. So at handover we keep the baseline report and the post-optimization report together, and we recommend adding a Lighthouse run to the release process to compare before and after each deploy. Check field data weekly so that when a metric slips, you can find the change that caused it.

Don't judge the result by lab scores alone, either. Look at LCP, INP, CLS and TTFB before and after alongside your conversion funnel to confirm the speed-up actually changed something for the business.

The same method works for Shopify stores

None of this is specific to self-hosted PHP sites. Performance problems on Shopify stores usually come from theme code, too many third-party app scripts and unoptimized images, and all of these can be fixed at the theme level without switching platforms. The order is the same: measure a baseline, go after the largest assets, then deal with scripts and layout shift.

A checklist to audit your own site

If you want to check your site yourself, go in this order:

Run PageSpeed Insights or Lighthouse three times and note TTFB, LCP, CLS and total download size
TTFB above one second: check database location, slow queries and server configuration
Look at the largest resources in the waterfall: usually videos and original images
Look at CLS: find images without dimensions, late-loading fonts and ad slots
Look at JavaScript: render-blocking scripts, and whether they can be merged and deferred
Finally, set up caching and compression

Measure again after each step and confirm you're moving in the right direction before starting the next one.

FXTech is an e-commerce technology agency and Shopify Partner based in Shenzhen, China. We build Shopify / Shopify Plus stores and headless DTC storefronts, optimize web performance (Core Web Vitals) and build cross-border VAT compliance systems. Case study: https://fxweb.dev/cases/#b2b-site-performance . Web performance service: https://fxweb.dev/wpo/ .

How to evaluate a Shopify development agency: a checklist for brands

Jobs Yang — Fri, 30 Oct 2026 03:42:25 +0000

Search for "Shopify development agency" and you get directories and ads. Very few of them explain how to tell whether an agency can actually do the technical work.

We are a Shopify and e-commerce development agency ourselves. This article is written from the brand's side: what to decide before you send a brief, what to check in a portfolio, which technical questions to ask, how to compare quotes and which warning signs to watch for. Use the checklist on anyone, including us.

First, decide which kind of work you are buying

"Shopify store build" covers several very different jobs, and each fits a different kind of agency:

What you want	The actual work	Who fits
Set up a theme, add products, design pages	Theme editor setup, content entry, app installs	Store setup / marketing agencies, design studios
Pages and interactions built to your brand design	Liquid development on a theme, custom sections	A team with front-end developers
Store connected to ERP, CRM or inventory	Shopify Admin API, webhooks, custom apps	A team with back-end and integration experience
A business process far from standard e-commerce	Shopify Plus checkout customization, or a headless storefront	A team that can design the architecture and run it long term
A live store that is slow or converts poorly	Performance audit, theme code and third-party script cleanup	A team that has done performance work and shows the numbers

Many projects fail not because the agency didn't try, but because the brand hired the wrong type: a development budget spent on a store-setup team, or an integration team asked to build a design-heavy brand site.

A simple test: write the brief on one page, split into "pages and interactions", "data and integrations" and "maintenance after launch". If you can't write anything in the second and third parts, you probably only need one of the first two types.

Check the portfolio, not the screenshots

Portfolio screenshots always look good, but they don't show code quality. Once you have the live links, spend 10 minutes on each:

Open the live site on your phone. Mobile layout, fonts and tap targets reveal more care than desktop does.
Run PageSpeed Insights on mobile. You don't need a perfect score, but if LCP is far above 4 seconds or the main thread is full of third-party scripts, the team doesn't care much about performance. On one export site we later optimized, the homepage TTFB was 17.96 seconds, and every cause could have been avoided at delivery.
Count the app scripts in the page source. A page loading a dozen app scripts usually means features were installed, not built.
Ask which parts they built. On the same site, one agency may have only uploaded products while another wrote the whole theme. Ask them to point to their work.

For an energy storage brand we built a full Shopify site on the official Dawn theme: 4 product lines and 11 subcategories, retail products bought directly, large storage systems handled through downloads and inquiries, and Shopify Markets set up for the US and India. For a case like this, ask the agency: why Dawn rather than a paid theme? How is hreflang handled across markets? Where does the inquiry form data go? Teams that really did the work can answer in detail.

Eight technical questions to ask

You don't need to read code. Listen for specific answers:

Whose name is the store under? It should be yours. The agency should request collaborator access to your store through the Shopify Partner dashboard, which you approve with the permissions you choose, or build on a development store and transfer ownership to you. A store registered on the agency's account and credit card is the most common source of trouble later.
How is theme code managed and delivered? A good answer mentions a Git repository, local development with Shopify CLI, and building on an unpublished theme for preview, not editing the live theme directly. You should receive the full theme code at handover.
Which theme is it based on, and what about future theme updates? A heavily customized official theme can't simply follow new upstream versions. That's a normal trade-off; what matters is whether it's explained up front.
What will be an app and what will be custom code? Mature apps for reviews or email marketing don't need rebuilding. But when the core experience depends on stacking several apps, fees and page weight add up. For a smart fitness equipment brand, the loyalty program had to link to the brand's own app accounts, which third-party loyalty apps couldn't do, so we built the member center, task-based points and coupon redemption (6 sub-pages) inside the theme, with no loyalty app subscription. The agency should give reasons for calls like this.
How does sync with ERP or inventory work? Listen for webhooks, API rate limits, retries and reconciliation. "We can integrate it" with no details usually means they haven't.
How are languages and markets handled? Shopify Markets, separate domains or subfolders, hreflang, currencies and price rules. Teams that explain this clearly have usually hit the problems.
Is there a performance target, and how is it accepted? Ask for mobile Lighthouse / PageSpeed targets and how they'll re-test after launch.
Who maintains the store after launch, and how is it billed? Bug fixes, small changes and adapting to Shopify platform changes all need an owner. If this isn't agreed, it's where disputes start.

Comparing quotes

"Build a Shopify store" can be quoted at prices ten times apart because the work is completely different. When comparing:

Align scope before price. Have every agency quote line by line against the same brief, with pages, custom modules, integrations, markets and maintenance listed separately.
There are three common pricing models: fixed price per project (for well-defined builds), time and materials (for custom work and integrations where requirements will move), and a monthly retainer (for ongoing work after launch). None is always better; match it to how settled your requirements are.
Be wary of package prices given before reading your brief. Packages fit standard setup work, not custom development.
Ask what's excluded. Paid themes, app subscriptions, Shopify Plus fees, translation, product photo work and data migration are usually not in a development quote.

Warning signs

The store has to be registered on the agency's account, or you don't get admin access
No theme code handed over, or the code only lives in the live store with no version control
Every feature is solved by installing an app, and they can't say what could be built instead
Portfolio cases are screenshots only, with no live links
"Shopify Partner" presented as a credential. Joining the Shopify Partner program is free and open to any developer; it means they can work through the Partner dashboard, not that they're certified. Agencies listed in the Shopify Partner Directory are vetted and the bar is higher
Promises of specific sales or conversion gains. Engineering improves speed and experience; sales depend on product and marketing

Working with an agency in China

Agencies in China (including Shenzhen, where we are) usually cost less and suit cross-border sellers and brands whose teams are in China. Agencies in your target market know local design habits and compliance better. If your team is overseas and you're considering a China-based agency, check whether they've built sites for your market and can work directly in English with your marketing, design or engineering team, with enough overlap in working hours.

Start with a small project

If you're still unsure, don't sign for the whole site first. Give a small but complete task: one custom section, a performance audit, or a prototype of an app integration. One or two weeks of real work tells you more than any portfolio or call: how communication goes, how code is delivered and how problems are handled.

FXTech is an e-commerce technology agency and Shopify Partner based in Shenzhen, China. We build Shopify / Shopify Plus themes and apps and headless DTC storefronts, optimize web performance and build cross-border VAT compliance systems. Shopify services: https://fxweb.dev/shopify/ . Headless storefronts: https://fxweb.dev/ecommerce/ . Case studies from this article: https://fxweb.dev/cases/#energy-storage-shopify-store and https://fxweb.dev/cases/#shopify-loyalty-program .