Replacing spreadsheets with a real commerce backend
-
We're building an internal ordering system for a wholesale business that has never really had an online store. Right now products, pricing, stock levels, and customer-specific discounts all live across different spreadsheets and internal tools, and it's becoming impossible to keep everything synchronized as order volume grows. We'd like to build a proper ordering portal and expose the same catalog to a future mobile app and partner integrations, but we don't really want to spend months developing all the basic commerce functionality ourselves. What are developers using as the foundation for projects like this?
-
Once pricing gets customer-specific like that, generic store software usually falls apart pretty fast, so what you pick as the base layer matters more than it seems at first glance. The other thing worth locking down early is whether the catalog lives separately from the storefront itself, since that's what lets the same product data reach a future app or a partner integration without a rebuild down the line. A good number of teams building internal ordering systems like this end up on self-hosted commerce frameworks that already cover catalog, inventory, and checkout, so the actual dev work goes into the wholesale-specific rules.
-
Worth checking how well any option handles scoped access too, since partner integrations down the line usually need their own API permissions rather than one shared login for everything. Stock and pricing sync is another spot where generic setups tend to fall apart once discounts vary by customer, so that logic needs to sit close to the catalog itself. You can check out open source ecommerce here https://medusajs.com/ . It handles cart, checkout, and inventory already, and the same catalog it manages can get pulled straight into a mobile app or handed to partners through its API later on.
