Multi-Supplier Tyre E-commerce Platform + Supplier Integration Engine

We are preparing the launch of a new online tyre store and are looking for an experienced senior developer or small development team to build the e-commerce platform together with a custom multi-supplier integration system (“Supplier Integration Engine”). The main objective is to create a scalable e-commerce platform where products, prices, stock and orders can be automatically synchronized with multiple tyre suppliers. ## 1. Project Overview The platform will initially work with 2–3 suppliers and approximately 50,000–75,000 products. Different suppliers provide their data through different methods, including: * REST API * CSV * XML * FTP/SFTP The system should be designed so that additional suppliers can be integrated later without rebuilding the platform. The project consists of two main components: 1. Customer-facing e-commerce store 2. Central Supplier Integration Engine Basic flow: Suppliers → Supplier Integration Engine → E-commerce Store Order flow: Customer → Store → Supplier Integration Engine → Selected Supplier We are open to alternative architectures if the developer can recommend and justify a better approach. ## 2. E-commerce Store The online store should provide the standard functionality required for selling tyres online, including: * large product catalogue; * tyre search by size; * filters by brand, season, dimensions and other tyre specifications; * product pages; * stock/availability; * shopping cart and checkout; * customer accounts; * payment integration; * shipping integration; * order management; * invoicing; * order status and tracking; * transactional emails; * SEO-friendly product/category structure. We are open to using an established e-commerce platform such as WooCommerce, PrestaShop, Shopware or another suitable solution. A custom solution may also be proposed if there is a clear technical or commercial advantage. We expect the developer to recommend the most appropriate approach. ## 3. Supplier Integration Engine This is a key part of the project. The Engine should automatically retrieve and synchronize supplier information such as: * EAN; * supplier SKU; * brand; * model; * tyre dimensions and specifications; * purchase price; * stock; * product images; * EU label / EPREL information where available; * DOT/year information where available; * other supplier-specific product information. Synchronization frequency should be configurable depending on the supplier, for example every 15, 30 or 60 minutes. ## 4. Multiple Suppliers for the Same Product The same tyre/EAN may be available from several suppliers. For example: Supplier A: Purchase price: €65 Stock: 30 Supplier B: Purchase price: €62 Stock: 5 Supplier C: Purchase price: €68 Stock: 100 The customer should see only one product in the store. Internally, the system must retain the separate supplier offers, including each supplier's: * SKU; * purchase price; * stock; * logistics information; * other relevant supplier-specific data. EAN should be the primary matching identifier when available. ## 5. Automatic Supplier Selection The system should automatically determine the preferred supplier for an order. Selection should support configurable rules based on factors such as: * purchase price; * available stock; * shipping cost; * applicable surcharges; * delivery time; * supplier priority; * other configurable logistics/commercial rules. The objective is to select the supplier based on real landed cost and availability rather than purchase price alone. ## 6. Automatic Pricing The platform should support automatic selling-price calculation based on configurable rules such as: * percentage markup; * fixed markup; * minimum margin; * different rules by brand/category/price range; * price rounding rules. Selling prices should be automatically recalculated when relevant supplier costs change. ## 7. Order Automation When a customer places an order, the system should determine the appropriate supplier and transmit the order using the integration method supported by that supplier. Depending on the supplier, this may be through API, XML or another automated method. The system should also support split orders. For example: Customer Order #1001 → 2 tyres ordered from Supplier A → 2 tyres ordered from Supplier B The customer should still see one store order while the system manages the supplier orders internally. ## 8. Order Status and Tracking Where supported by the supplier integration, the system should retrieve: * supplier order status; * shipment status; * AWB/tracking number. This information should be synchronized back to the e-commerce store and communicated to the customer. The system should support multiple shipments/tracking numbers for the same customer order. ## 9. Administration and Monitoring We would like a practical administration interface for the integration system. It should allow us to monitor: * suppliers; * last synchronization; * supplier/feed status; * number of products/offers; * synchronization errors; * orders and supplier orders. Where practical, we would also like to configure: * supplier priority; * shipping/surcharge rules; * pricing rules; * synchronization intervals; * enable/disable supplier. The system should include appropriate logging, retry mechanisms and error handling for situations such as unavailable supplier APIs, invalid feeds, stock changes, price changes or failed orders. ## 10. Scale and Future Expansion Initial implementation: * 2–3 suppliers; * approximately 50,000–75,000 products. The architecture should support future expansion to additional suppliers and a larger catalogue without requiring the core system to be rebuilt. Please note that the number of supplier offers may be considerably higher than the number of unique products because the same EAN can exist at multiple suppliers. The supplier integration architecture should therefore be modular and scalable. ## 11. MVP and Development Approach We are interested in launching an MVP as efficiently as possible. We are open to a phased implementation if this provides a better balance between development time, cost and functionality. For example, the initial phase could include the core architecture and one or more supplier integrations, with additional suppliers and advanced functionality added in subsequent phases. However, the core architecture should be designed from the beginning for multiple suppliers. ## 12. What We Expect From the Developer We are not committed to a specific technology stack. We would like the developer to review the requirements and recommend the most appropriate architecture rather than simply implement a predefined stack. Please include in your proposal: 1. Your recommended architecture and technology stack. 2. Which e-commerce platform you would recommend and why. 3. How you would structure the Supplier Integration Engine. 4. Your estimated development time for the MVP. 5. Your realistic fixed-price estimate for the MVP. 6. If you recommend a phased implementation, the estimated scope, cost and timeline for each phase. 7. Suggested project milestones. 8. Examples of similar e-commerce, supplier integration, API or inventory synchronization projects you have completed. 9. Your availability for ongoing maintenance/support after launch and the approximate cost/rate. We have intentionally not specified a fixed budget at this stage because we would like to receive realistic estimates based on the proposed architecture and implementation approach. Our priority is to build a reliable foundation that can be launched relatively quickly and expanded over time, rather than over-engineering the first version.