Someone has offered to build a service that imports product and listing data from shopping marketplaces in one country and displays it on a separate website for international customers. Because of geographic, payment, banking, and telephone restrictions, customers would create accounts on the intermediary site and purchase through it rather than buying directly from the original marketplace.
The system would have one main administrative account, multiple customer subaccounts, an automatically translated frontend, marketplace data synchronization, ordering and payment functionality, and a backend for managing users and purchases. The concept is similar to existing proxy-shopping services that let overseas customers buy from marketplaces they cannot access directly.
I am trying to estimate the budget before moving forward. What would be a realistic price range for development, and what would ongoing maintenance typically cost? I am also concerned about risks involving marketplace terms of service, scraping or API access, cross-border payments, taxes, consumer protection, customs, fraud, and handling customer funds. Are these concerns serious enough to require legal and compliance advice before development begins?
4 Answers
Do not assume that because similar services exist, the model is automatically safe or permitted. Ask the proposed developer exactly how the data will be obtained, whether official APIs or commercial agreements are available, who owns the marketplace account, how customer money is held, and who is liable when an item is unavailable, damaged, counterfeit, mispriced, or never delivered. Those answers will affect both the architecture and the cost.
The business model needs validation as well as technical planning. Customers may expect guarantees for shipping, authenticity, returns, and payment protection, and international delivery can create expensive support and refund obligations. Before commissioning a full platform, consider a limited manual or semi-automated pilot using one marketplace and a small set of customers. That can test demand and operational costs before investing in a large custom system.
There probably is no meaningful single price without a detailed specification. This is much more than a translated catalog: it may require marketplace integrations, data synchronization, inventory and price handling, customer accounts, payment processing, order placement, refunds, shipping, currency conversion, fraud controls, support tools, and security. A basic prototype might cost tens of thousands, while a reliable production platform could easily reach six figures. Maintenance would normally be an ongoing monthly cost, plus hosting, payment fees, third-party APIs, monitoring, bug fixes, and feature work.
The legal and compliance side should be investigated before anyone writes code. You may be operating across multiple jurisdictions and could be responsible for payments, refunds, consumer rights, privacy, customs, taxes, restricted goods, and disputes. You also need to confirm whether the marketplaces permit automated access, data reuse, account linking, and placing orders on behalf of customers. Existing companies may have negotiated agreements or processes that a new service cannot simply copy, so speaking with lawyers familiar with e-commerce, payments, privacy, and international trade is prudent.
That makes sense. I was focused mostly on the website itself, but the payment, ordering, and dispute processes may be the more complicated part. A small pilot could also reveal whether the margins are enough to cover support and international shipping issues.