Marketplace Development for Startups and Businesses
I design and build marketplace platforms and multi-vendor systems on Medusa.js — for entrepreneurs, startups, and businesses that want to create their own sales ecosystem, not just another online store. This is product development, not website development.
Production
marketplace running on Medusa.js
100%
code ownership — yours, not ours
0
per-transaction platform fees
API-first
integrates with any system
Problems I solve
You want to build, but every agency you talk to starts with a quote before understanding your business logic
You haven't decided how commissions work, who pays out whom, and when
Seller onboarding, verification, and approval flows are undefined — and they affect the entire architecture
You need split payments, but don't know which payment provider supports your model
What you get
Every project element is carefully refined. I turn ideas into solid, scalable solutions, ensuring the highest quality at every stage.
Medusa.js backend configured for multi-vendor logic — commissions, payouts, seller accounts
Buyer-facing storefront — product/service listings, search, cart, checkout
Vendor panel — seller onboarding, product management, order handling
Payment integration with split payments or commission logic (if in scope)
Admin panel — moderation, user management, platform settings
Hosting, deployment, and infrastructure setup
Git repository and full access handed over to you
Handover, documentation, and training session
Process
Business model analysis — commission structure, user roles, legal responsibility, payout model. No code until the business logic is clear.
Market participant mapping — who are the buyers, who are the sellers, what does each side need from the platform
Process design — onboarding flows, order lifecycle, moderation, dispute handling, payment flows
MVP scope definition — what goes into version one, what is deferred, what is the minimum viable platform
Architecture and estimate — technical proposal and a concrete price for the agreed scope
Implementation, testing, deployment, and product roadmap for future development
How this service works in practice
I run my own marketplace — and that changes everything
I actively develop and maintain a production marketplace on Medusa.js. Not a demo. Not a side project. A live platform with real sellers, real buyers, and real transactions.
That means I've encountered problems that don't appear in tutorials or documentation:
- Real sellers who don't follow the onboarding flow as designed — and the edge cases that creates
- Real orders that expose gaps in the commission logic you thought was complete
- Real user errors that break flows you assumed were obvious
- Real business decisions made mid-development — and how they forced architectural changes
- Maintaining and evolving a live system over months — not just launching and walking away
I designed the architecture. I made the product decisions. I wrote the code. I handle the maintenance. I know what breaks and why — because I've already broken it myself.
When you hire me to build your marketplace, you're not paying for someone to learn on your project. You're getting someone who has already paid that tuition.
The hard part isn't the technology
Marketplace platforms fail not because of bad code, but because of unresolved business decisions that get pushed into the architecture at the wrong time. The technology is solvable. The process design is where most projects get stuck.
Decisions that must be made before writing a line of code
These are not technical questions. They are business and legal questions that directly determine how the system is built. Getting them wrong early means rebuilding later.
- Who is the legal seller — the platform or the vendor? This determines VAT, invoicing, and liability.
- Who issues the invoice to the buyer? Who issues the invoice to the platform?
- Who handles returns and complaints — and what does the process look like technically?
- How is commission calculated — flat fee, percentage, tiered, per-category, or dynamic?
- When are sellers paid out — immediately, weekly, after a hold period, after buyer confirmation?
- How does seller onboarding work — self-registration, manual approval, identity verification, document upload?
- Are sellers verified before they can list? What does verification involve?
- How are listings published — immediately, after moderation, after admin approval?
- What user roles exist — buyer, seller, admin, moderator, support? What can each role do?
- What happens when a dispute arises between buyer and seller? Who arbitrates?
I work through these questions with you before any architecture is proposed. The answers shape the system.
The most common mistakes in marketplace development
These aren't hypothetical. They're patterns I've seen repeatedly — and some I've made myself.
- Building everything before validating the market. A full-featured platform nobody uses is an expensive lesson. Start with the minimum that lets you test whether buyers and sellers actually show up.
- Poorly designed commission model. Changing commission logic after launch is painful — it touches payments, invoicing, seller agreements, and reporting. Get it right before you build it.
- No payout strategy. When do sellers get paid? What happens if a buyer requests a refund after payout? These questions need answers before the payment integration is built.
- Underestimating moderation. Every marketplace eventually has bad actors — fake listings, fraudulent sellers, policy violations. Moderation tools are not a nice-to-have. They're infrastructure.
- Ignoring legal structure until it's too late. Who is the legal seller? Who handles VAT? These decisions affect the payment architecture. Discovering them after launch means rebuilding core flows.
- Choosing technology that's hard to extend. A marketplace evolves constantly. If the codebase can't be changed without breaking everything, growth becomes a rewrite.
What I design and build
Not a list of features. These are areas of responsibility — each one requiring its own design decisions.
Payments and settlements
The most complex part of any marketplace. Money flows in one direction from the buyer, then splits across the platform and multiple sellers — with refunds, holds, and commission deductions along the way.
- Split payments — funds routed to sellers automatically, minus platform commission
- Commission logic — flat, percentage, tiered, per-category, or custom rules
- Payout schedules — immediate, weekly, on-demand, or after hold periods
- Refunds — who initiates, who absorbs the cost, how it flows back through the system
Sellers and onboarding
How sellers join, get verified, and operate on the platform determines the quality of your supply side. A poorly designed onboarding flow is one of the most common sources of operational problems.
- Onboarding flows — registration, document upload, identity verification, approval
- Status management — pending, active, suspended, rejected
- Permissions and roles — what each seller account can and cannot do
- Vendor panel — product management, order handling, earnings, analytics
Orders, commissions, and moderation
The operational core of the platform — how orders flow, how commissions are applied, and how the platform maintains quality control.
- Split orders — one buyer order divided into sub-orders per seller
- Commission application — calculated and recorded at the order level
- Content moderation — listing review, approval queues, flagging
- Dispute handling — tools for managing complaints between buyers and sellers
Technical architecture — for founders and technical stakeholders
Founders buy scalability, reliability, and maintainability. Here's how the architecture delivers those — and which technologies make it possible.
Performance
Marketplace storefronts can have thousands of listing pages. Without a deliberate caching strategy, every page load hits the database. Redis handles session management and high-traffic listing pages. Static generation with revalidation keeps pages fast without sacrificing freshness.
SEO
Marketplace SEO is not the same as store SEO. Category pages, seller profile pages, and listing pages each need their own indexing strategy, canonical handling, and structured data. Next.js with SSR ensures every page is indexable. This is not an afterthought — it's built into the architecture from the start.
Scalability
Financial operations — payouts, commission calculations, notification dispatch — run asynchronously via job queues. Synchronous processing of money is a reliability risk. PostgreSQL handles the relational complexity of seller-order-commission relationships with transactions and constraints that matter when real money is involved.
Architecture
Headless and API-first. The storefront, vendor panel, and admin panel are separate applications consuming the same Medusa.js API. Each part can be replaced or extended independently. Custom commission logic, seller accounts, and payout rules are built as native modules — not plugins bolted on top of a system that wasn't designed for them.
Stack: Medusa.js, Next.js, PostgreSQL, Redis, TypeScript.
Legal and business considerations
I don't give legal advice. But I've built a marketplace, and I know that the architecture is often determined by legal and business decisions made before the first line of code. These are the areas that need to be resolved — with your lawyer and accountant — before the system design is finalized.
- Terms of service — who is responsible for what, and how disputes are resolved
- UE regulations for e-commerce
- Commission policy — how it is calculated, when it is charged, and how it is disclosed to sellers
- Platform liability — what the platform is and is not responsible for in transactions between buyers and sellers
- Invoicing and VAT — who issues documents, in which jurisdiction, and how the system handles it
- Returns and complaints — the process must be defined before it can be built into the system
- GDPR — data collected from buyers and sellers, consent flows, data retention, and deletion requests
- Seller verification — KYC requirements, document collection, and what happens if a seller fails verification
The system architecture often depends directly on these decisions. A marketplace where the platform is the legal seller requires a completely different payment flow than one where each vendor sells independently. I design sysems that comply with all regulations.
You work directly with the person building it
AppCrates is not an agency. There is no project manager between you and the developer. You talk directly to the person who designs the architecture, writes the code, and makes the technical decisions. Faster feedback, clearer answers, no information lost in translation.
Frequently asked questions
Yes — and that's usually the right approach. An MVP marketplace focuses on the core loop: sellers can list, buyers can purchase, payments work. Everything else — advanced moderation, analytics, complex commission tiers — comes in later iterations. Starting lean reduces risk and lets you validate the business model before investing in the full platform.
Yes. Medusa.js is API-first and modular, which makes it well-suited for marketplace logic: multiple seller accounts, custom commission structures, split payments, and independent product catalogs per vendor. It's not a plug-and-play marketplace tool — it requires custom development — but that's exactly what gives you the flexibility a real marketplace needs.
It depends heavily on scope: number of user roles, commission model complexity, payment provider, moderation requirements, and whether you need a custom vendor panel or can start with a simpler one. I'll give you a concrete estimate after an initial discovery call — not a vague range.
A focused MVP — core listings, checkout, basic vendor panel, payments — typically takes 6–10 weeks. A full platform with custom features, advanced commission logic, and third-party integrations can take 3–6 months. The timeline depends on scope, not on how fast I can work.
Yes — and I'd recommend it. Marketplace products evolve based on real user feedback. Building everything upfront is expensive and often results in features nobody uses. I help you define a solid MVP, launch it, and then plan the next stages based on what actually matters.
Not entirely. Medusa.js provides a solid foundation — commerce primitives, API layer, database structure. What gets built from scratch is the marketplace-specific logic: commission models, seller accounts, payout rules, vendor panel, moderation flows. You're not starting from zero, but you're not buying a pre-built marketplace either. The result is a system that fits your business model exactly.
The more clarity you have, the more accurate the estimate. Useful things to think through: your commission model (how the platform earns), who your sellers are and how they onboard, whether you need split payments or handle payouts manually, what user roles exist, and whether you have a sense of MVP scope vs. full platform. You don't need all of this figured out — part of the discovery call is working through it together.
Yes. Commission logic is one of the things Medusa.js handles well with custom development. Flat fees, percentage commissions, tiered structures, per-category rates — all of these are buildable. We define the model during the discovery phase.
Yes. The full codebase is yours. You're not licensing access to a platform — you own the software.
Yes. At handover you receive the Git repository, all credentials, hosting access, and admin panel access. Nothing is locked behind my accounts.
Yes. The codebase is built on standard technologies — Medusa.js, TypeScript, Next.js. Any competent developer can pick it up. I'll provide documentation to make that transition as smooth as possible.
Yes. Medusa.js supports multiple payment providers — Stripe, PayU, Przelewy24, and others. The choice of provider often depends on your commission model and whether you need split payments at the payment processor level or handle splits in the application layer.
Yes. The vendor panel is a separate frontend application. It can be built to match your exact seller workflows — product management, order handling, earnings tracking, and whatever else your sellers need to operate on the platform.
If you want to see how this looks in practice
If you are at this stage, you are probably wondering how this works in practice or whether it makes sense for you. Below you will find concrete examples and topics that expand on this direction.
Other services
Related areas
Related projects
Real implementations
Related articles
Topics I expand on
Ready to get started?
Let's talk about your project. Free consultation, no obligations.