Medusa.js developer - ecommerce and marketplace builds
I build stores and marketplace platforms on Medusa.js: systems written for your selling model instead of bent to fit a hosted platform. The code and the data stay with you.
100%
ownership of the code and the data, handed over to you
Custom
modules written for your model instead of workarounds
Multi-vendor
stores and marketplaces on the same engine
Headless
a Next.js storefront, or whichever front end you pick
Pick your model
Same engine, two rollout scenarios. You do not need to decide upfront - we settle it in the first conversation.
Medusa.js store
One seller, one payment, full control over the selling logic.
- Your own pricing, promotion and tax logic
- A payment gateway chosen for your market
- Price history for the Omnibus Directive
- Migration from a hosted platform
Multi-vendor marketplace
Many sellers, split money, settlement rules of your own.
- Carts split into per-seller orders
- Configurable commissions and payout schedule
- Seller onboarding, panel and storefronts
- Refunds that reverse a completed transfer
What I build
Catalogue and selling
Variants and attributes · brands · product templates · moderated reviews · wishlists · price lists and promotions · price history with a 30-day low · abandoned carts with an automatic discount · newsletter and campaigns
Marketplace and sellers
Onboarding with a profile completeness meter · roles and team invitations · editable seller storefronts · approval flow for products and accounts · account lifecycle with a grace period and data anonymisation
Payments and settlement
A gateway chosen for the market and the model: Stripe, PayU, Przelewy24, BLIK, Klarna and others · for marketplaces, split payments usually via Stripe Connect · configurable commissions per seller, category and product type · payout schedule and hold window set to your returns policy · transfer reversal after a refund · penalties deducted from payouts · discounts and points funded by the platform rather than the seller · self-billing
Orders and logistics
Shipping cost split across sellers · shipping templates and carrier coverage · parcel tracking with customer notifications · delivery timeframes · return requests and their effect on settlement · reminders for orders waiting at a seller
EU market requirements
Price history for the Omnibus Directive · manufacturer and importer data for GPSR · DAC7 threshold tracking and reporting · EPR registrations with an eligibility check at onboarding, listing and checkout · data anonymisation that preserves the accounting trail · scope and depth matched to your market and model
Operations and support
Support tickets with attachments · messaging between platform participants · email notifications on events · configuration versioned in the database rather than in environment variables · an admin panel extended to cover all of it · maintenance and further development after launch, if you want me to stay on
Search and reliability
Product search on Algolia or Meilisearch · locks serialising financial operations · webhook event ledgers that discard repeats · batch queries instead of N+1 · separate cache, queue and workflow engine instances
Who is this for?
- The hosted platform has started getting in your way instead of helping
- Commissions, payouts or the seller model are your product
- Integrations with an ERP, a warehouse or another platform are a standing operational cost
- Regulatory requirements should be enforced by the system rather than by procedure and memory
- You count the whole cost: a higher plan plus apps often lands in the same range, except none of it stays yours
- You want the code on your side and the decisions with you
- Your model fits a hosted platform and nothing about it chafes
- You sell a dozen products and plan no unusual logic
- You need a store by next week
A store does not run alone
It has to talk to what you already use, and to what your customer expects. Below are the usual needs and what closes them.
Selling and money
You already sell on another platform
Shopify, WooCommerce, PrestaShop, Shoper, Etsy, BaseLinker. Products and stock agree in both directions, with no manual clicking.
The same layer handles ongoing sync and a one-off migration
Customers want to pay their own way
Cards, BLIK, Przelewy24, PayU, Klarna, instalments. The gateway is chosen for the market you sell in.
For marketplaces, split payments usually run through Stripe Connect
Invoices should issue themselves
Fakturownia and comparable systems. On a marketplace, automated seller settlement documents as well, and self-billing where the model calls for it.
Tax has to come out right
Calculation per jurisdiction, with tax codes mapped onto product categories.
Customers and support
Customers ask where the parcel is
17TRACK and tracking numbers in the panel. Status notifications go out on their own instead of landing in your inbox.
Someone has to find the product
Algolia or Meilisearch. Facets, sorting and as-you-type suggestions.
Signing in without yet another account
Google, Facebook, or plain email and password.
Email has to arrive
Transactional sending with retries, so an order confirmation is not lost to a brief provider outage.
Content and back office
You want to edit content without a developer
Sanity or Payload as the CMS. Banners, copy and landing pages stay on your side.
Images and files need somewhere to live
Storage with signed URLs, kept away from the database so the catalogue does not swell with photos.
Migrating WooCommerce, Shoper PrestaShop to Medusa.js
Is your store getting harder to update? More plugins, integrations that no longer fit together, and an outdated PHP version slow the roadmap down, and every larger change turns into extra work?
I migrate existing stores to Medusa.js, an e-commerce engine built on Node.js and TypeScript, with a dedicated Next.js storefront.
A migration can cover the product catalogue, variants, customers, order history, payments, shipping, integrations, and SEO redirects. The exact scope depends on the current platform and your business requirements.
Rather than recreating the constraints of the old system, we can design an architecture that fits where the store is heading. If your current platform still covers the model, updating it and tidying up the integrations may be the cheaper route.
Critical PHP vulnerabilities, 21 October 2026
On 21 October 2026 the PHP team disclosed two critical security vulnerabilities (CVE-2026-109618 and CVE-2026-109619) that can allow unauthenticated remote code execution.
Fixes were released for PHP 8.2, 8.3, 8.4, and 8.5. Older versions no longer get standard updates from the PHP project, although some vendors ship their own security patches and the PHP security team published minimal source backports for 7.4, 8.0, and 8.1. Running a version without official support is not the same as a confirmed vulnerability in your particular environment, so it is worth checking the actual setup with your hosting provider.
If your store still runs on an outdated environment, urgent updates come first. Updating the current platform can be the right answer on its own. If modernising it already requires significant changes to the application, a migration to a different architecture is worth considering as well. Vulnerabilities turn up in every environment, Node.js and Medusa.js included.
Problems solved in production
Each of these describes a decision taken on a running system, including what went wrong on the first attempt.
Medusa.js in production: what is under the hood of an online store
Two stores look the same, yet one costs ten times more. Real code, measurements, and load tests from the Artovnia marketplace show how a production Medusa.js architecture handles failures, payments, and traffic.Payments in Medusa.js: Building a Store vs. a Marketplace Are Two Completely Different Worlds
Integrating payments into a Medusa.js store takes hours. Doing the same for a marketplace takes weeks — and may end with a provider refusing to work with you. Here's why, and what to do about it.How I Built a Provider-Neutral Integration Hub for a Marketplace on Medusa.js (Starting with Shopify)
Craft sellers don't migrate their stores on demand. Artovnia had to find another way — instead of asking sellers to move, it simply syncs with what they already have. Here's what a provider-neutral integration hub on Medusa.js looks like with zero changes to the core.Cache invalidation is hard. In a marketplace, it gets really interesting.
Cache in a Medusa.js marketplace is a design problem about source of truth and invalidation. At Artovnia (Medusa.js) we solved Next.js issues: two-layer promotions cache, nested unstable_cache bypassing Data Cache, ISR storing skeleton-only HTML, recommendation fan-out, and broken splitChunks.Share & Save in a Medusa.js marketplace: sales attribution and dynamic seller commissions
Share & Save drops a seller's commission from 18% to 13% when that seller brought the customer in. Here is how signed click attribution, per-seller commission adjustments, double-charge protection, and a full audit trail work in a Medusa.js v2 marketplace.Marketplace Compliant with Regulations Without Building Amazon
How to translate GPSR, DSA, GDPR, BDO, and DAC7 obligations into a reasonable MVP, without designing infrastructure for millions of listings. A practical architectural overview for marketplace builders.How to Extend an Existing Online Store with a Marketplace
A marketplace layer can be added to an existing online store without replacing the underlying platform. Inventory synchronization across vendors is the most complex part of the integration. The store operator retains full control over orders and the customer experience.OAuth Was Supposed to Unify Onboarding. Four Platforms Forced Four Installation Models
Building an e-commerce integration hub for Artovnia, we discovered that OAuth being mentioned in documentation isn't enough. Each of the four platforms - WooCommerce, Shopify, Shoper, and PrestaShop - required a different installation and onboarding model.Marketplace guide: obligations and architecture
47 chapters across two tracks: operator obligations, from seller onboarding through GPSR, DSA and DAC7 to packaging compliance, and platform architecture from MVP to scale.
What I work with
Common questions
If a standard store covers your model, Shopify is cheaper and faster - I will say so. MedusaJS earns its cost when the commission logic, seller model, payout rules or integrations are the product, and a hosted platform makes you work around them.
Yes. Artovnia is a live multi-vendor marketplace on MedusaJS v2 with its own settlement system: Stripe Connect Express, split payments, delayed payouts tied to a 14-day returns policy, per-seller commission rules, a platform-funded loyalty programme and a referral system.
That is a large part of the work. The integration layer is provider-neutral - Shopify, WooCommerce and Shoper behind one abstraction, with OAuth, webhook handling, product and inventory synchronisation, retries and idempotency so repeated deliveries do not corrupt data.
I implement the requirements in the system - seller onboarding data, DSA reporting and traceability, GPSR product information, DAC7 reporting, payouts and VAT documents. That is engineering, not legal advice; the operational guide on this site documents how the pieces fit together.
You do. MedusaJS is open source, the implementation is yours, and the deployment runs on infrastructure you control.
Tell me what your commerce has to do
We do not start with the stack. We start with where the money flows and who is responsible for what.