Most people commissioning an online store evaluate proposals based on price and portfolio aesthetics. That's a mistake — and a fairly costly one. After building e-commerce projects (including a full marketplace with a custom settlement system), I keep seeing the same problems surface after launch, not before.
Here are five questions you should ask before signing any contract — and what you're actually looking for in the answers.
1. What platform will it be built on — and why that one specifically?
Every developer should have a concrete, well-reasoned answer to this question. Not "because that's what we do" or "because it's what we always use."
The difference between Shopify, WooCommerce, and a headless solution like Medusa.js isn't just about upfront cost — it's about what you can actually do in one, two, or five years. Shopify works great for straightforward retail, but any custom logic means paying for a plugin, a commission, or a full refactor. WooCommerce is flexible, but under heavy traffic it starts to buckle, and maintenance becomes its own separate project.
Medusa.js is an open-source e-commerce backend — modular, no licensing fees, full control over the codebase. Paired with Next.js on the frontend, it gives you an architecture you can grow without platform-imposed constraints. But that also means the developer needs to know what they're doing — there are no ready-made plugins for everything here.
If a developer can't explain this difference in terms of business value — not technical jargon — that's a red flag.
2. How does the payment system work — who actually holds the money, and when does it reach me?
Sounds simple. It isn't.
When building Artovnia — a marketplace for artists — the settlement system turned out to be one of the hardest parts of the entire project. The platform handles multiple sellers within a single transaction: funds need to be split, held until the return window closes, and commissions calculated automatically. This isn't "we'll add Stripe" — it's a dedicated financial system.
Medusa.js has built-in Stripe integration, but handling split payments, Stripe Connect, or delayed payouts requires custom backend logic. It's worth asking whether the developer understood this before starting the project — or whether they'll discover it along the way.
For a standard store the question is simpler, but still important: do payments go directly to you or through an intermediary? Are there delays? What are the transaction fees at different volumes? Are local payment methods like BLIK or P24 supported?
A bad payment system only reveals itself when the first refund comes in — or the first dispute with a customer.
3. After launch, will I be able to manage the store myself — without calling a developer?
This question is about the admin panel and CMS. It sounds obvious, but plenty of stores are handed over to clients with an interface so limited that changing a product description requires a "small fix" costing a few hundred zlotys.
Medusa.js has its own admin panel — functional, but by default limited to managing products, orders, and customers. If you need more (editing page content, managing a blog, landing pages), that requires either extending the Medusa panel or adding a separate CMS like Sanity or Contentful.
Ask specifically: can I add products myself? Create promotions and discount codes? Update images and descriptions? Manage inventory? Send newsletters to customers?
In Artovnia, the seller panel includes a rich text editor with SEO descriptions, a promotions system (discounts, free shipping, targeted offers for specific customers), abandoned cart detection, and a vacation mode. That level of functionality isn't standard — but it's worth knowing what you expect before you sign off on the project scope.
4. What happens when the store starts to grow?
Almost every developer will tell you the store is "scalable." Ask them how.
Specific questions: what does caching look like? What happens when 1,000 people hit the store simultaneously? Where is the backend hosted and how does it handle traffic spikes — say, Black Friday? Does the product search still perform well with a catalog of 10,000 items?
Medusa.js runs as a Node.js backend — it can be hosted on Railway, Render, AWS, or a self-managed VPS. But the platform itself doesn't solve scalability for you. You need a well-thought-out architecture: Redis for session and data caching, ISR (Incremental Static Regeneration) in Next.js for product pages, Algolia or Meilisearch for search at scale.
With Artovnia, I went through a backend optimization phase where some requests were taking several seconds — getting them under 100ms required deliberate architectural decisions: Redis, layered caching, ISR in Next.js, Algolia for search. The result: LCP ~1.4s on desktop, p99 for heavy queries ~300ms.
These aren't details for enthusiasts. This is the difference between a store that earns during a promotion and one that crashes exactly when it should be making money.
5. Who owns the code — and what happens after launch?
Two questions in one, because they're connected.
Code ownership: when the project is done, do you get full access to the repository? Is the code written in a way that another developer could pick it up and continue? Or are you locked into one person or one company?
Medusa.js as open-source gives you an advantage here — there's no vendor lock-in at the platform level. But lock-in can still happen at the implementation level: if the developer wrote custom modules without documentation, you're just as dependent on them as you would be with a closed platform.
Post-launch: who manages hosting? Who updates dependencies? What happens when a critical bug appears on a Saturday at 10 PM during an active campaign? Is there support, and on what terms?
No clear answers to these questions is a recipe for a dependency that, after a year, costs more than the project itself.
A good developer won't have any trouble answering these questions — in fact, they'll be glad you asked them. It means they're talking to someone who takes the project seriously.
Personally in my e-commerce implementations, I choose Medusa.js as a base for custom implementations.