MDStore: building a marketplace for artists and makers

Portfolio materials present MDStore as a marketplace for art, handmade products and digital creations. Its documented structure includes creator pages, product approval and custom requests with offers. This guide explains decisions such a product needs without inferring sales from the existence of its features.

Decide who sells and who answers

A conventional shop usually has one team controlling the catalogue. Marketplace creators have different products, lead times and availability. Before designing screens, define who enters the sale, receives payment and resolves questions about delivery or products that do not match their description.

Describe buyer, creator and administrator roles. For each, record permitted actions and visible information. Customers should understand who delivers the product and where to get help. Explanations must agree across product pages, orders and platform terms reviewed for the actual operating model.

Build one creator's complete journey

In a hypothetical exercise, a ceramicist wants to publish a mug. They complete a profile, upload the product and submit it for review. An administrator approves it or requests specific corrections. Rejection without explanation blocks collaboration and produces repeated support questions.

Separate profiles from products. Biography, technique and creator identity can support many works, while dimensions, pricing and stock belong to the item. MDStore documentation emphasises verified creators and approved products. Explain what verification actually checks without turning it into an absolute safety guarantee.

Model the information before designing the gallery

Use stable identifiers for creators, products, variants, requests and orders. Changing a photograph or title should not create a different product in a buyer's history. Preserve relationships between records and define what happens to existing orders when a creator deactivates their profile.

Separate publication status from commercial availability. An approved product may be sold, temporarily withdrawn or in production. An item under review should not appear available. This distinction separates editorial decisions from inventory and makes catalogue status clearer to creators and support staff.

Organise search around the objects themselves

Group products by type, use and characteristics shoppers understand. For art, technique and size may matter; functional objects may need material and purpose. Avoid presenting a filter as useful when most products lack the corresponding information.

Begin with a few categories and representative examples. Test searches with and without diacritics, alternative wording and no results. Empty results should let people change the query or return to a category. Do not fill the page with unrelated suggestions simply to avoid empty space.

For addresses and filters, consult Google's ecommerce URL guidance. Categories, creator pages and products need distinct purposes. Avoid generating indexable pages for every accidental filter combination without an independent benefit for visitors.

Separate direct purchasing from custom work

A stocked mug can have a known price and dispatch time. A personalised set needs quantity, colour and scheduling details. Do not use the same “Buy” button if the immediate next step is actually negotiating an offer. The label should describe what happens when pressed.

MDStore's documented workflow allows requests, offers and counteroffers. Preserve the accepted version and its conditions so subsequent edits do not rewrite the original agreement. Define when work begins, what needs approval and how to handle changes requested after acceptance.

Make order states understandable to both sides

Buyers and creators need to understand the order journey. “Processing” can conceal review, waiting for payment or production. Choose sufficiently precise states and explain who makes the next transition and what notification follows, so both parties share the same understanding.

• Request receipt confirms that information was saved.
• Offer acceptance fixes the agreed version of conditions.
• Payment confirmation follows verification of the transaction.
• Dispatch indicates actual handover for transport.
• Closure preserves the history needed by support.

Do not confirm payment from a click or a return to a page. For digital products, define access delivery and download failures. For physical objects, explain packaging and communication responsibility. Each product type introduces different operational situations that need decisions before launch.

Protect data and make moderation manageable

Creators should see information needed for their orders without accessing other creators' customers. Administrators need review tools and history, but privileged access should be limited. Hiding a button in the interface does not sufficiently protect the underlying data.

Create clear reasons for requesting corrections or withdrawing products, and provide a route to challenge decisions. Moderation requires time and responsibility, not just an “approved” label. Review images, descriptions, availability and brand use before problems reach buyers with already accepted orders.

Launch with a small group of creators

Test publication, corrections, purchasing and custom requests using fictional data. Include withdrawn products, two buyers interested in a unique item and failed notifications. Participants should continue without understanding the technical architecture or requiring a developer for every exception.

Measure approved products, answered requests and confirmed orders rather than registrations alone. Nonessential tracking requires consent. Expand the MDStore project when the team can maintain catalogue quality and resolve exceptions: marketplace growth depends on coordinating both sides of the transaction.