I’m Badii Boutar. I build online stores for clients, and The Merchant Engine is what I built for that work, now released under the MIT license. It is a complete store: an API, an admin dashboard, a storefront, and an installer that puts all of it on a Linux server you control. Version 1.0.0, the first public release, came out on 27 October 2026.
Before anything else, here is what it does not do. If one of these is a deal breaker, you can stop reading now and I won’t take it personally.
What it does not do yet
- Stripe is the only card provider so far. Cash on delivery, manual bank transfer and gift cards work with no credentials. Since v1.0.1 a shopper can also pay by card, embedded or on a hosted page, and you enter the Stripe keys in the admin. More providers plug in behind one interface, and the recipe for adding one is written. If you need a card provider other than Stripe on launch day, use Shopify.
- No Shopify import. You can export products from Shopify as a CSV, but Shopify’s own help page says “the images associated with each product aren’t included in the CSV file”. Moving a store means a script that loads the products through the admin API and fetches the images separately. I haven’t written that tool.
- The admin is in English. The storefront, the invoices and the emails work in Arabic, right to left. The admin dashboard has an Arabic editing tab on every text field, and that tab types right to left, but the dashboard itself is English and is not mirrored.
- One storefront layout. Colours, fonts and the logo come from the store settings. The layout itself is the same for every store. There are no themes to pick from.
- No upgrade command and no prebuilt images. An update is a re-run of the installer on a newer checkout, and the installer builds the images from source on your server.
- It’s young, and it’s one person. Shopify has a company behind it. This has me. Weigh that honestly before you put a client’s business on it.
The full list is on What you get.
Why I built it
A lot of my client work is for shops in North Africa and the Gulf. A store there almost always needs more than one language: Arabic, read right to left, next to French or English. In my experience, almost no platform has a clean answer for that. The shops also had to take cash on delivery and show prices with the right number of decimals, which is three for some currencies.
The other gap was search. Almost none of the platforms I worked with connected cleanly to Google Search Console, or seemed to care much whether the store could be found online at all. That work was always left for later, one store at a time.
So I always pictured one engine with all of this built in from the first install. I also wanted the client to own the code and the server, and to pay nothing per order to anyone.
That is what I built. It ships English, French and Arabic, and the storefront switches to right to left for Arabic. Cash on delivery is a payment method the owner turns on, with its name translated for each language. Money is formatted with the currency’s own symbol, separators and precision. For search, the API builds the sitemaps, robots.txt and llms.txt, sends changed pages to IndexNow, and resubmits the sitemap to Search Console when you connect it. The admin then shows the clicks and impressions Search Console reports. The setup is on Requirements.
What Shopify does better
I’d rather say this plainly than have you find it out later.
Shopify is a hosted product. Someone else keeps the servers up and deals with the outage at 3 a.m. It has its own payments and an app store that outside developers build for, and so many stores run on it that most questions already have an answer somewhere. If you want to sell this week and never think about a server, Shopify is the better choice.
You also can’t run Shopify yourself. Even the headless setup keeps the backend on Shopify. In their own words, “You build the frontend, and Shopify’s APIs handle the commerce underneath.” For most merchants that is fine. It matters when the client wants the code, or when the checkout has to work in a way Shopify does not allow. The old way to customise the checkout, checkout.liquid, was for Plus stores, and Shopify’s docs now say “checkout.liquid is now unsupported for the Information, Shipping, and Payment checkout steps.”
Where the money goes
I read Shopify’s pricing page on 29 October 2026. Paid yearly, Basic was $29 a month, Grow $79, Advanced $299, and Plus started at $2,300. Paying month to month costs more.
There is also a fee that is easy to miss. The pricing page says “Third-party transaction fees may apply when you use a third-party payment provider (instead of Shopify Payments).” That fee was 2% on Basic, going down to 0.2% on Plus. On a Basic store taking $10,000 a month through another card provider, 2% is $200 a month to Shopify, separate from what the provider itself charges.
Cash on delivery is different. Shopify treats it as a manual payment, and its manual payments page says “Common types of manual payments include cash on delivery (COD), money orders, and bank transfers.” The same page says manual payments carry no third-party transaction fee. So on Shopify, cash orders cost you the plan and nothing more.
The Merchant Engine costs nothing to download and charges nothing per order. There is no paid tier, no license key and no telemetry, and you can run it for as many client stores as you want.
That does not make it free to run. You pay for a server: the requirements page asks for a Linux box with two cores and four gigabytes of memory to build the images, and twenty gigabytes of free disk. You also need an S3-compatible bucket for images and a Resend domain for email. And you pay with your own time, because keeping it updated and backed up is now your job. A Shopify plan includes all of that, and it is a big part of what the monthly price buys. My comparison of the two, row by row, is on the Shopify alternative page.
What you get when you install it
Three applications and an installer.
The API is NestJS and Prisma on PostgreSQL and Redis, with one REST API for the catalogue, search, the cart, checkout, orders, payments, shipping zones, tax, promotions, gift cards, reviews, customers, staff and roles, and the store settings. Placing an order and adjusting stock require an idempotency key, so a retried request never places the same order twice or moves the same stock twice. It also sends the store’s email through Resend.
The admin is an Angular dashboard for the people who run the store. The storefront is server-rendered with Analog.js, and it reads the store’s brand, languages and currency when each page is requested. You can keep it, change it, or build your own storefront on the same API.
The installer is the part I’d look at first. It asks for every value the store needs and checks each integration live before it writes anything: it puts a test object in your bucket, sends a test email through your Resend domain, and checks your Turnstile secret with Cloudflare. Then it builds the images, creates the database, gets the TLS certificates, seeds the store and creates the owner account. If it fails halfway, you run it again and it picks up where it stopped. On a server it also sets up certificate renewal and a nightly database dump. Copy those dumps somewhere off the box, because a backup on the same disk as the store is not much of a backup.
Trying it
You don’t need a server to look at it. On a laptop with Docker Desktop, give Docker at least 4 GB of memory, clone the repo, and run:
./setup.sh --localOn Windows it is .\setup.ps1. The local profile has no TLS, keeps the mail on your machine and loads a demo catalogue. A first install took seven minutes on a Windows laptop, and a re-run took twenty-six seconds. The steps are on Install locally, and the server version is Install on a server.
The code is on GitHub. If you try it and something breaks, or a claim on this page turns out to be wrong, open an issue. It comes straight to me.