Discord community & the future of Mercur

Mercur is entering a new phase of development: more open, more collaborative, and shaped directly with its community. We’re officially opening the Mercur Discord Community and sharing an update on where the platform is heading next.

Mercur is opening its Discord community

We’ve launched our Discord space to work more closely with builders, partners, and teams using Mercur in real marketplace projects. The goal is simple: listen earlier, gather real feedback, and evolve Mercur through ongoing dialogue rather than in isolation.

Discord will be the place where:

• ideas and early concepts are shared before they’re finalized,
• roadmap items and decisions are discussed openly,
• feedback directly influences how Mercur evolves,
• iteration happens faster – together with the community.

We’re fully embracing a build-in-public approach and invite you to be part of it from the inside.

What’s next for Mercur?

Alongside opening the community, we’ve published a new video sharing an honest look at where Mercur is heading. In the video, Greg, Viktor, and Jacob walk through the story behind Mercur: how the first version of the platform was built, what limitations they hit while working on real marketplace projects, and why they decided it was time to rethink Mercur from the ground up.

Key topics you'll discover

• Why the first version of Mercur was no longer enough for modern marketplace needs?
• What core mechanics are being redesigned and introduced in the new version?
• How client projects influenced architectural and product decisions?
• What kind of marketplaces Mercur is being built for and which ones it’s not?

You can find the video transcription below.

Transcription

Greg: Hi everyone. Today we would like to share with you what we are building here. My name is Greg, with me are Viktor and Jacob, and we are building Merkur, actually in a new version, because we've built it before, but now we would like to change something and create new mechanics, so we will share all our thoughts and plans for the future of the product. But before we start, we would like to start with why we built Mercur and then what Mercur is, because maybe some of you do not know it yet. So, getting started, why did we build Mercur?

Viktor: I remember I joined Rigby in 2023, and we were building the first marketplace. We were starting to build a marketplace on Medusa, their first version, so we have a really long history of building marketplaces, and we just built and built more marketplaces, and we just figured out that it will be really good to have a project that we can start on and build marketplaces on top of, because we had a lot of clients building marketplaces, right? And that's why we actually wanted to create the product like Mercur.

Greg: Yeah, exactly. So we just saw that all the time we reinvented the wheel. So we just wanted to create fundamental logic to create each marketplace faster, right? To speed up development. That was the main goal at the time. So what is Mercur? What was Mercur before, and what is Mercur today?

Viktor: Yeah, so right now it's like we've started it as a template. So it's just a scaffold project that you can build on top of. So you can just git clone the repository and start building the features on top of that. And right now what we're trying to build is more like a framework, I would say. So now you have a CLI, you have the separate vendor panel, and you have the admin panel with the built-in features and the built-in logic. So it's really handy for developers. Yeah.

Jacob: And also we are focusing very much on management panels and how easy the user can modify them, add things to the admin or vendor panel, because previously we knew that it was very, I would say, poorly done to extend those by default. And this is our main goal: to keep up the updates on our side and to make it easy for you to easy install them but still keep your changes and modifications to the panels on your side.

Viktor: Yeah, also I would like to add that it's really handy to have Medusa because you have all the calculation logic, all the modules, and all the models that guys from Medusa are actually made. And so there's no need to reinvent the wheel if there are some professional guys that already have figured out how to calculate certain things, or like orders, the workflows from all across the projects. It’s really handy to have it just as a start point to build on top of the marketplace.

Greg: Yeah, it would be stupid to not use Medusa as a core, right? Because, like, all logic is there.

Viktor: Yeah, it's also open source.

Greg: Exactly, exactly. If you want to build something similar from scratch, it would take years, right?

Viktor: Yeah, it would take long. It just would do the same thing as the guys from Medusa do, so what's the point of it?

Greg: Doesn't make sense. So what was the first version of Mercur? Right now our idea is completely different, I think. At that time it was more like a template for Medusa. Right now we feel it can be like a whole separate ecosystem, because marketplaces – huge topic actually—there are many types of marketplaces: B2C, B2B, services marketplaces, and many more. Sometimes these common projects are combined, like some complex ideas, multi-tenant, B2C, and B2B marketplace projects – all this logic at once.

Viktor: Yeah, yeah, yeah. We had, like, previously we just had the plugin for, like, Medusa, but we found out that we have a lot of, like, use cases and a lot of features across multiple use cases. And we just then realized that just having one plugin is not enough. So, because you want to have a foundation from which you can start, but there can be a lot of features. That's why just having one plugin, one closed box, is not enough to build a marketplace.

Greg: And do you remember, Jacob, what limitations we have seen while using this product, let’s say the template, during development?

Jacob: So from my side, I was basically previously doing the frontend stuff, so extending the base admin panel or the vendor. Because, for example, if you had a page built in the Medusa admin panel, you weren't able to modify it easily – change the table or basically remove this page, for example. And I know it was very painful to deal with this because you had to download all the code from the Medusa and inject it into your project and deal with, I don't know, 200 extra files. And right now I hope everything...

Greg: Yeah, it needs to work. It's something we need to solve. And I think we've got a great idea here. We will talk about it more at the moment. Marketplaces need a very complex admin panel and vendor, so customization is crucial.

Viktor: Customizations are really, like, really different based on the marketplace. Like you can have food marketplaces, and the whole hierarchy of the pages is different, and the nested structure is different. And you just need to have, like, a thing where you can, like, switch and customize everything you need, but you also need to have a thing that, alright, if we release a new feature, you just need to use the CLI and update the package, or, like, update the package and have new features or a new, like, box fix or something. Hope there will be no bug.

Greg: Great. So that's for sure one problem: customization of admin and vendor panels. But what other problems do we have that we tried to solve today with the new version?

Viktor: I would say like the backend stuff, because on the backend you just – in the first versions we just had like a whole template, a whole code that is really duplicated between all across the projects, all across the Mercur projects. And then if we fix some things or deliver some things, you just need to merge the changes from the template, from the Mercur repository, to your own project, which is a huge problem. So that's the first thing. And the whole admin customization.

Jacob: I think keeping your Mercur with the current updates of the Mercur.

Greg: That's something we even had some problems with internally. We built this product, but then we had problems updating it, so that's why we had to find some new approach to it, because maintenance is always like the most important part at the end. Great, so why are we talking today? We built it like one year ago, but what about it now? What do we want to change?

Viktor: Just overall the philosophy of it. We just want to change it from "All right, this is a template you can start from" to a commerce marketplace framework platform, I would say. To just have a foundation that we can really maintain in your project. So you have, like, a solid foundation that you can then easily update and introduce new features from our codebase to yours. So it's like a package that you can really customize, like as hell as you want. So really change most of the things, or change 20% of the things that you like to change.

Greg: Exactly. Because we see that even different types of marketplaces are really different. There are some common lists of features, right? This abstraction of the marketplace is usually maybe not the same but pretty similar. So we feel we can create, like, a foundation layer that will allow you to customize and to add logic on top of that for different marketplaces, like B2C, B2B, service marketplaces, and others.

Viktor: I want to get into details about what we do, I think, now, but I just want to say that we also want to allow people to have ownership of their code. As we said, marketplaces are really different, and just having one plugin is not enough. You need to customize pretty much most of the things, because the requirements are different.

Greg: Exactly, that's what we feel about building the products here in Rigby. So, like, keeping the logic closed in plugins doesn't make sense. It just doesn't work. Great. So how are you planning to make it real—this flexibility and fast, quick adjustments to different marketplace types?

Viktor: Yeah, like from my side, I would say from, like, the core backend side, because I'm mostly working on it, and Jacob works on the frontend stuff and the customizing layer, which is really hard to do. But from my side, we just had ideas, and we measured out these ideas. We talked to the Rigby team. What do they think? Because they're like the first ones that will be using that product. And they were the first ones to use the project previously. So we're just trying to create, like, a core foundation, like a plugin, which is really thin, which is really simple, that most of the marketplaces would like to have: seller modules, and some payout modules, and commission modules that most of the marketplaces have.

And we also would like to introduce a Shadcn CLI feature that you have basically blocks, which are basically files, which contain API logic, the modules, and the workflows, Medusa workflows, and stuff. You actually can, using the CLI, fetch all of that code into your codebase from the registers that we create. So there's a default registry and, like, community registries that other people, or you, can attribute – and we actually want you to contribute because it's really good for the community and it's really good for us.

Greg: Yeah, I think it's really unique, right? Because we all know Shadcn, but Shadcn is for backend framework – that's something I haven't heard before.

Viktor: Yeah, yeah. Really good, because I think frontend developers realized that the UI should be customizable, the same as we have in Rigby. We have the realization that the package should be really extendable and really customizable as hell as you want.

Greg: Exactly. Even with some simple logic, or in shadcn approach, some components, like buttons, and this atom part often need customization. Jacob, what about the admin and vendor panel? Because here we've got, I think, a great idea. It needs to be as flexible as the backend. And also I couldn't imagine being able to easily fetch logic for the backend but manually creating admin features and vendors. It needs to be connected; it needs to work together. So what are your ideas here?

Jacob: Okay, so the basic idea is to use the components. I will go more technically right here. And just by that, you can easily modify, for example, the product page and remove one core component from this.

Greg: Yes, of course. Like, we can only fetch to the customization layer only pages you customize, and even inside this page we do not need to worry about maintaining all components that are included in the page because we can just customize one selected component, or maybe add our own, or just remove this component.

Jacob: Yeah, we don't need to worry about touching the rest of the page after overriding the one component. We don't have to worry about the updates because we are using the core for the admin, and updating it won't destroy our custom logic for this. And also using the registry with this, we can also easily extend the page.

Viktor: Yeah, because at the end of the day the whole admin panel and the vendor panels are just pages, and pages are built with the parts, the parts of the pages like modules and like the information stuff. So each page has some parts, each page has some components, and you can just switch and replace each part, remove some parts, and introduce your parts. That's the thing about the extension, and we can really flex because no one did that before. We’re the first ones that really like this philosophy of just removing certain parts, certain parts of the pages, introducing your need, but keeping the core parts, like plugging them in, and just running npm install and having new features or new things added to your project.

Greg: You need to maintain only parts you customize. And we all know that today we need to code with AI. I mean, we don't need it, but we should. It's like almost standard today. Is it a good approach for the AI era? What do you think about this?

Viktor: Yeah, we just go with the AI, we go massive on the AI. I think it's really good to improve the speed and the iteration of velocity, even in the Mercur team, even in us, because we just really iterate. And for example, I like to use Claude Code a lot, and I know Jacob also does. Yeah, like the whole skills and the whole MCP, and I think the whole Mercur philosophy is really good with the AI era because you have a CLI, you can add blocks, and you can ship these parts of the codes, which AI can understand. And you can, like, say, "All right, I want to add a wishlist and make some customization to it," and so the Claude Code or some other AI agent fetches that block, and the agent knows how it works and the information about it. And you are also sure that this block works because it's not like AI slop code; it's actually built with us or some other part of the community, so you know it works. And the AI can build on top of the foundation the customization that you asked for, and I think it's really good. And you also have that foundation that we build, that thin foundation inside the panels and the core that is tested, that is built with the community, the community also built with it. So, you understand that this code is tested and this panel tested things, and you can introduce and can ship that inside your project.

Greg: So if I get you right, the whole registry is built with AI in mind.

Viktor: The AI knows exactly what you're introducing to, what you ship, what block you ship, what block has, and the stuff about it.

Greg: And as a developer, I need to look for some parts of logic in some documentations, or can I just use AI to find what I want to build, and it will automatically fetch logic that is similar or even exactly as I want?

Viktor: Yeah, AI agents love CLIs because in our CLI you have methods like lists and search, and you can actually search for certain blocks and, like I said, add them and see the information. So it's like you are actually doing nothing; you just say in your natural language what you're trying to do, and it knows stuff about the CLI and just utilizes this CLI.

Jacob: Or if you want to build something on your own, we will provide you with the skills for the agents. So just telling your agent: "I want to build some custom modules with the extension to the admin panel," the agent will know from the skills and also some cookbooks how to create the code and implement it to the Mercur.

Greg: But why do we need these blocks if we can just build with AI?

Viktor: First of all, because you don't have a "slop code thing," and you actually have maintenance from our side and from the community side, and you know it's tested. You know it has good architecture and good code and some other stuff. Yeah, so I think that's why you need to use, like, why you need to use Shadcn components if you can write your own components, right? It's like you have all the foundation because the user that did those components really had in mind how to properly do those components and properly do that code.

Greg: Yeah. Yeah. I think it is safe. Developers get a lot of tokens because they can just fetch this logic, and also they get like know-how, how something was built, and instructions for AI on how to develop it further and how to customize it. So it's like the approach we see on the market, where we give 80% of the logic ready, and 20% is the part you need to customize in your project. Sounds great. We've got a registry. Do we want to do it on our own? Or what are the expectations here?

Viktor: I think our expectation is to just engage the community in building registries, building their own registries. Like, for example, if you or some people that you know might, they have, like, I don't know, like a B2B marketplace or like B2B logic, they can, like, easily scaffold the GitHub repo and create their own registry, and other people can use it. Or like within your projects, you can actually create private registries, right? You can get your private registry and use it; for example, if you're an organization, you can create your own registry. Like, for example, if you do like B2B marketplaces or some food marketplaces, you can create your own registry and like only use it within your organization and have it under an API key. But yeah, we want developers to actually engage in our core default registry to have blocks, but also if you have some other ideas across multiple use cases, you can actually add your own registries. And we're trying to heavily engage the community to actually test the framework and test the ideas. We will see all of the reviews and all of the comments, and the Discord channel will create this all to just create better products and see what people are actually heading to so we can meet expectations and ship some other things, but also engage the community in shipping some other things.

Greg: We feel that we need to build it more in public. We need to build it more based on feedback from the community of other developers. We don't want to keep it only for ourselves. So that's why we're recording this video today to explain to you what our goal is and what's our mission here. And hopefully you can engage and help us to build it, right? Thank you. See you, bye!

This marks the beginning of a more transparent and collaborative chapter for Mercur. We’re excited to build what’s next – together with the community.