We’re building Ever Works in public. Some things may be incomplete, missing, or broken while we continue improving the platform.We’re building Ever Works in public — expect a few rough edges.
Compare · Store builders
Open-source headless commerce platform
Medusa is the open-source commerce engine a store gets built on — MIT modules for cart, payments, orders and inventory, a durable workflow engine, a managed cloud, and a browser build surface. Ever Works researches a topic, writes the content, generates the site and keeps it running on a schedule; its Store builder is coming soon.
Medusa is an open-source headless commerce platform: cart, payments, orders, inventory with reservations, fulfillment, tax, regions and promotions ship as MIT-licensed modules you can read and change, alongside a customizable admin, a durable workflow engine for multi-step business processes, a Next.js starter storefront, and a managed cloud whose per-branch preview environments start on the entry plan. Since Bloom arrived in November 2025 it is no longer developer-only — you can describe a store in the browser, have it deployed through their cloud, point it at a product page or an image to pull that product into the catalog, and pull the source down into your own repository whenever you want it. What no surface of theirs does is decide what to sell: the agents run in a developer’s editor while the developer watches, and Bloom captures a catalog that already exists somewhere rather than originating one. Ever Works comes at this from the other end — its agents research a topic, write the content, generate the site from a template you own, deploy it, and then keep it fresh on a schedule, with content and code committed to your own Git. Be clear about the state of play, though: the Ever Works Store builder is coming soon, so there is no storefront, product model or checkout today, and Medusa wins every transactional row on this page outright. Where the two meet is more likely to be integration than displacement — the Store builder’s plan already names a self-hostable open-source commerce backend as one of the backends a Store will connect to, which is exactly Medusa’s shape.
Both products now have a prompt-to-thing surface, so the honest distinction is what each one starts from. Bloom builds from what you give it: a description of the store you already have in mind, and products extracted from a page or an image you point it at — real catalog capture, and it should not be dismissed, but capture is not origination. Ever Works starts from the topic. Its standard pipeline analyzes the domain, discovers entries through web search, extracts and deduplicates them, assigns categories and tags, validates each source for reachability and quality, captures screenshots, and then writes the descriptions, SEO metadata and item-vs-item comparison pages before generating the site to present them. That pipeline is deepest for directory-style content, which is where it has run longest; Blog, Website and Landing Page Works are wired end to end but still ride the same items pipeline while dedicated post and landing-copy writers catch up. Commerce-shaped research — products, suppliers, margin signals — is part of the Store builder plan, not something shipping today.
Medusa’s agent tooling is build-time assistance: the skill packages and the documentation MCP server make the codebase legible to a coding assistant running in a developer’s editor, on a developer’s machine, while that developer is watching. Nothing described keeps acting on the store when nobody is there. Ever Works is built the other way round. Named, persistent Agents have their own scope, schedule and budget; scheduled updates re-run the generation pipeline on seven cadences from hourly to monthly, with a 15-minute retry and an automatic pause after repeated failures; source validation re-checks every item’s URL and proposes a replacement when a source has gone bad; community pull requests are processed hourly; and the website layer is compared with its upstream template and updated for you. Around that loop sit spend caps enforced before each AI call, quality gates that send weak work back instead of to you, a configurable merge policy, and a branch and private checkout per Task — the governance that makes unattended work reviewable. One thing Medusa has here that Ever Works does not: a durable, resumable engine for multi-step business processes. Ever Works has workers, tasks and gates, not compensating workflows.
Medusa is honestly open: the core and its modules are MIT, which is more permissive than AGPL for anyone embedding or reselling, and self-hosting costs nothing in license fees. The gate is elsewhere — role-based access control and SSO are proprietary Enterprise materials usable only under a separate commercial agreement, while audit logs, bring-your-own-cloud and SLAs are line items on the top cloud plan. Ever Works is AGPLv3 with no feature held behind a paid tier: the per-Work roles it ships — Owner, Manager, Editor and Viewer with a full permission matrix — are in the same open repository as everything else. It documents no SSO, SAML or OIDC of its own, so enterprise identity is a capability Medusa has and Ever Works does not, licensed or otherwise. On ownership, Bloom exports code to your repository on request; Ever Works commits continuously to three repositories per Work in your own GitHub account — data, Markdown and website — so listings, taxonomy, comparisons and the Knowledge Base are commits you can diff and revert, while product data in a Medusa store lives in its PostgreSQL database. The runtime self-hosts on Docker Compose or Kubernetes, runs on the AI provider you choose from 11 provider plugins including local models through Ollama, LM Studio and vLLM, carries 102 plugin packages, and exposes itself through an MCP server and a CLI.
Medusa sells a commerce framework to a team that already knows what it wants to sell. Ever Works sells the layer above that: a Mission keeps proposing Ideas, accepted Ideas become Works generated from prebuilt templates, named Agents with budgets and heartbeats keep each Work moving, Teams and Work Members share it, and a per-Work Knowledge Base gives every run institutional context instead of a cold start. Today those Works are websites, blogs, directories, landing pages and awesome-list repos — the Store builder is coming soon, and its planned shape is a Store Work built from a commerce template, staffed by Merchandiser, Copywriter and Analyst Agents, with the catalog researched and the product copy written. Worth saying plainly: that plan names a self-hostable open-source commerce backend as one of the backends a Store will connect to, so when it lands, running a Medusa backend underneath an Ever Works Store is a more sensible posture than replacing it. Until then the two are not really competing for the same buyer.
Ever Works vs Medusa, head to head.
| Feature | Ever Works | Medusa |
|---|---|---|
| Prompt → working app/site | ✓ | Bloom, in the browser |
| Researches the topic for you | ✓ | Extracts products you point it at |
| Writes the content (copy, posts, SEO) | Directory data today; posts rolling out | Captures existing product copy |
| Generated code from a template base | ✓ | Scaffold + starter storefront |
| Ongoing autonomous maintenance | Scheduled | In-editor agent sessions |
| Content version-controlled in Git | ✓ | Catalog in PostgreSQL |
| Code in your Git | ✓ | ✓ |
| Open source | AGPLv3, no paid tier | MIT; RBAC/SSO commercial |
| Self-hostable runtime | ✓ | ✓ |
| No vendor lock-in | ✓ | ✓ |
| Storefront, catalog and checkout | Planned | ✓ |
| Product, variant, price and stock model | Planned | ✓ |
| Orders, payments, tax and fulfillment | Planned | ✓ |
| Durable multi-step workflow engine | – | ✓ |
Choose Medusa whenever you are actually selling something. It is the better pick if you need cart, checkout, payments, orders, inventory, tax, regions or B2B pricing working today, if you have a developer or an agency to build and operate the store, if you want commerce logic you can read and extend without forking core, if multi-step order processes with retries matter to you, and if you would rather pay for compute on a managed cloud — or only your own infrastructure costs, self-hosting on Node and PostgreSQL — than a share of your revenue. Bloom makes the first version reachable without a dev team, and the code comes back to your repository, so the developer dependency is now about operating and extending the store rather than starting it. Ever Works has none of this today: its Store builder is coming soon, and there is no product model, storefront template or checkout in the product yet.
Visit Medusa ↗Ever Works already researches a topic, writes the content, generates the Next.js code, deploys it, and keeps re-running on the cadence you set — all in your own Git. The Store builder (storefront, catalog, checkout) is on the way, and the sites the runtime generates today already carry subscription checkout, per-plan gating, sponsor ads and promo codes.