I run a stationery e-commerce store where we don’t pre-stock most of our inventory. Instead, we purchase from third-party suppliers after customer orders come in. It’s basically a just-in-time / backorder model.
The daily workflow looks like this: orders come in throughout the day, and once or twice a day I need to figure out exactly what to buy across all those pending orders. With 100+ orders and 500+ SKUs, this used to mean manually going through each order, tallying up quantities in a spreadsheet, checking if I already had surplus from a previous over-purchase, and then creating a buying list.
The biggest pain points were:
• Manually aggregating SKU quantities across dozens of orders
• Losing track of surplus items (bought 10, only needed 7, forgot about the extra 3 next time)
• Not knowing which orders were fully procured vs. still waiting
I ended up building a Shopify app to solve this for my own store, and it’s now on the App Store (SKU Procurement Planner) in case anyone has a similar workflow.
But I’m curious — how are other backorder / made-to-order stores handling this? Are you using spreadsheets? Some other tool? I’d love to hear how others manage this workflow.
It’s truly inspiring on how you turn the pain point into Solution. It’s way more important to figure out the solutions. And you did it. Your app is truly inspiring in term of saving a lot of time for the Merchants. Doing the things manually means you are killing growth.
Regarding your Question, most of the merchants still doing the things manually. Which means they are spending a lot of time on it to get the things done. But you prove that, this is possible without doing manually stuff.
Thanks for the kind words! Yeah, the manual spreadsheet process was really holding us back… especially once we started processing 100+ orders daily. The time spent just figuring out what to buy was taking hours that could have gone into actually growing the business.
That’s interesting that most merchants are still doing it manually. Do you see that a lot in your experience? I’m curious what the tipping point is where merchants start looking for a better solution. Is it order volume, SKU count, or something else?
edit: Sorry, I’m new to this format. I thought I replied to my own post.
This is a typical workflow for made to order shops, especially with large catalogs. Most vendors start on spreadsheets, then run into limits as their order volume grows. A functional set up is to tag unpurchased orders, export line items daily and then use Airtable or Google Sheets (with formulas you can find on the internet) to auto total SKUs and track overstock stock. You can also use Shopify Flow to set completed orders as fully procured after purchase quantities are matched. For supplier purchase lists, some stores go with bundles apps or inventory planners tailored for purchasing. Building your own tool is what makes sense here because traditional inventory applications are designed for stocked inventory not demand driven procurement workflows.
That’s a good point about SKU count being the bigger factor. Yeah, the app handles exactly that! you select your pending orders and it aggregates all the SKU quantities into one list so you can see exactly what to buy. It also tracks any surplus from previous over-purchases and deducts it automatically so you don’t re-buy stuff you already have. If you know any merchants struggling with this, feel free to point them to it!
Thanks for the detailed breakdown! The Airtable/Google Sheets + Shopify Flow approach is clever. That’s basically the same workflow I was running manually before building the app. The formulas get messy though once you’re dealing with surplus tracking across multiple purchasing rounds.
About the last point you mentioned? Traditional inventory apps are built for pre-stocked inventory, not demand-driven procurement. That’s exactly the gap I kept running into. Every “procurement” app on the App Store is really a purchase order tool that assumes you already know what to buy. The step before that, figuring out what to buy from your pending orders, is what nobody was solving.
Out of curiosity, are you running a made-to-order workflow yourself, or have you seen this pattern with other merchants?
Really smart solution — manual aggregation across 100+ orders sounds like a nightmare. I’ve seen other backorder stores try to hack this with Excel + pivot tables, but the surplus tracking always falls apart when things get busy.
A couple questions I’d be curious about:
How do you handle partial shipments? Say you buy 10 units of a SKU but only 7 are available from the supplier — does your app help split what’s ready vs. still pending?
Do you ever run into issues where two orders could share surplus from a previous over-purchase, or is that still somewhat manual?
We don’t run a backorder model ourselves, but I’ve helped a few clients look at tools like Zentail or Pipe17 for this — though those feel like overkill for a smaller store. Honestly, a purpose-built app like yours seems way more practical.
Thanks for sharing. and great job scratching your own itch first. That’s how the good apps start.
Great questions, and thank you very much for the kind words!
On partial shipments, the app handles this at the order level rather than the supplier shipment level. If you can only buy 7 out of 10 units, you’d adjust the quantity in the app and complete the session. That order gets tagged “Partially Purchased” in Shopify, and the next time you create a session, partially purchased orders are automatically pulled in and prioritized so the remaining items are front and center. It doesn’t track what the supplier shipped vs. what’s still incoming though. It tracks whether your purchasing decision fully covers the order demand.
On surplus sharing across orders, that’s fully automatic. The app has a Surplus Stock pool that saves any over-purchased quantities from previous sessions. When you create a new session, surplus is automatically allocated to matching SKUs before calculating what you still need to buy. So if two orders both need the same SKU and you have surplus from last week, it gets applied first. No manual tracking needed.
Interesting that you’ve looked at Zentail and Pipe17 for clients. You’re right that those are heavy for smaller backorder stores. This app was really built for the person who’s actually doing the daily purchasing, the operator sitting with supplier tabs open, figuring out what to order. It’s a procurement workflow tool, not a store management platform. Just “here are your orders, here’s exactly what you need to buy” and get on with it.
This is a great example of how different the workflow gets once you move to a demand-driven model instead of pre-stocked inventory.
The aggregation problem is obvious, but the tricky part always seems to be the state tracking — knowing what’s already been procured, what’s partially fulfilled, and what can be covered by surplus without double counting.
That’s where spreadsheets usually start to break down once volume picks up.
Curious how your app handles that over time especially when orders, supplier availability, and surplus are all changing at different points in the day?
You’re hitting on exactly the right problem!! State tracking is where spreadsheets fall apart first, the moment you have surplus from session A affecting what you need to buy in session B, and partially purchased orders carrying over between sessions, a spreadsheet can’t keep up reliably.
The app handles this through a session-based workflow. When you create a session, it takes a snapshot of your selected orders at that point in time. Within that session, everything is consistent. Surplus gets allocated, quantities are calculated, and you make your purchasing decisions. Nothing changes underneath you while you’re working.
When you complete the session, three things happen: orders get tagged (Purchased or Partially Purchased), any over-purchased quantities go into the Surplus Stock pool, and partially purchased orders become available for your next session. So the state is always clean at each step.
The key design choice was making sessions sequential. You can only have one active session at a time. This avoids the double-counting problem entirely. You’re never in a situation where two sessions are competing for the same surplus or tagging the same orders.
For changes happening throughout the day, new orders that come in after you’ve created a session just go into your next session. The current session only deals with orders you selected at import time. This keeps things predictable for the person doing the actual purchasing.
That’s a really clean way to handle it especially making sessions sequential to avoid double counting.
The snapshot approach makes a lot of sense from an operator perspective, since you don’t want things shifting underneath you while you’re deciding what to buy.
The interesting tradeoff is that you’re essentially choosing consistency within a session over real-time updates across sessions.
Curious how that plays out as volume grows do teams ever feel like they’re lagging slightly behind what’s actually happening (new orders, supplier changes), or does the session model still hold up well in practice?
Good question. You’re right that it’s a deliberate tradeoff. Consistency within a session over real-time updates across sessions. In practice, it holds up well for the stores this app is designed for.
I built this specifically for small to mid-sized operations. In our store, we typically run 1-2 sessions per day — morning and afternoon. New orders that come in between sessions just get picked up in the next one. For that rhythm, the lag is negligible because you’re never more than a few hours behind.
Where it would start to feel limiting is at very high volume. If you’re running thousands of SKUs across hundreds of orders and need near real-time procurement decisions, you’d probably want something heavier with live syncing and team-level concurrency. But at that scale you’re also probably looking at ERP-level tooling.
Honestly, I built this because I saw a gap for smaller backorder stores that don’t need enterprise procurement systems but have clearly outgrown spreadsheets. The operators doing daily purchasing at those stores just need a clear answer to “what do I need to buy right now” without the complexity of a full supply chain platform. That’s the sweet spot this lives in.
That makes a lot of sense, especially framing it as that middle ground between spreadsheets and full ERP systems.
The “what do I need to buy right now” question is really the core of it and for most teams, having a clear, stable answer at the right moment is more valuable than constantly chasing real-time updates.
Interesting how the tradeoff shifts with scale though smaller teams optimize for clarity and simplicity, while higher volume pushes toward concurrency and real-time coordination.
Curious if you’ve seen teams hit that transition point where the session model starts to feel limiting or if most stay comfortably in that daily rhythm?
So far the daily rhythm has worked well for the stores using it. Most backorder operations aren’t running procurement minute-by-minute — it’s usually a morning batch and sometimes an afternoon one. If a store ever outgrows that pattern, it’d be a good signal to explore more advanced tooling.
Appreciate the thoughtful questions! If you ever come across stores running this kind of workflow, happy to hear how they’re handling it.
That makes sense. At that scale, having a predictable rhythm is probably more important than optimizing for constant real-time movement.
Really appreciate you sharing the workflow details it’s been interesting seeing how different teams are solving this gap between spreadsheets and heavier systems.
The Real Operational Gap
For most backorder/made-to-order Shopify stores, the real issue is not inventory counting itself — it’s making purchasing decisions based on incoming orders without introducing enterprise-level complexity.
Why the Session-Based Approach Makes Sense
The session-based system is actually a reasonable compromise for smaller teams because procurement usually happens in batches anyway:
Morning/afternoon purchasing runs
Supplier cutoff schedules
Daily procurement cycles
In that type of workflow, slight delays in real-time inventory updates usually do not create major operational issues.
Where the Complexity Starts
The real challenges begin when stores start dealing with:
Multiple purchasers or team members
Supplier lead times
Partially received inventory
Allocation against open sales orders
Demand forecasting
Near real-time replenishment decisions
Shopify’s Limitation at Scale
At that point, Shopify alone starts showing its limits because it was never designed to function as a full procurement or logistics management platform.
Once merchants reach a certain level of operational complexity, most eventually introduce:
ERP systems
WMS platforms
Dedicated purchasing workflows
The Gap in the Shopify Ecosystem
For mid-sized Shopify merchants, there is still a massive gap between:
Running everything through spreadsheets
Implementing a full ERP
A simple procurement workflow focused on daily purchasing decisions rather than enterprise-level supply chain management.
This is a great breakdown of the landscape. You’ve described the exact gap that motivated me to build this: that middle ground between spreadsheets and full ERP that most backorder stores live in.
The session-based approach maps directly to how daily purchasing actually works in practice. Most operators aren’t making procurement decisions in real time. They’re batching it around supplier cutoffs and daily rhythms, exactly as you described.
That’s the interesting part the operational rhythm itself matters more than theoretical real-time capability for a lot of these stores.
Most smaller procurement teams optimize around:
• supplier cutoff windows
• purchasing batches
• staff availability
• and reducing decision fatigue
So having a stable “buy this now” workflow often matters more than constantly recalculating inventory every few seconds.
Where things seem to change is when procurement stops being a single daily operational task and becomes a coordination problem across multiple people, locations, and suppliers.
That’s usually the point where teams start feeling the tension between:
Shopify workflows,
specialized apps,
and full ERP systems.
Really appreciate you sharing how you approached that middle layer it’s a gap a lot more operators seem to be running into now.
