Built a Shopify app to stop small sellers from overselling across channels — looking for early feedback
Hey IH 👋
I'm based in South Africa, and I just shipped my first real SaaS: Inventory Sync, a small Shopify app for sellers who also sell in-store, on Etsy, or at markets.
The problem I kept hearing about: someone sells an item in person or on another channel, forgets to update Shopify, and it gets sold again online — refund, apology, unhappy customer. Small multi-channel sellers deal with this constantly and most existing tools are built for bigger operations.
What it does right now: pulls your Shopify inventory into one dashboard so you can see stock across channels in one place, with more channel integrations (Etsy, manual in-store counts) planned next.
Where it's at: fully working OAuth install, live inventory sync from Shopify, and billing through Shopify's own Billing API (so it's a proper recurring subscription, not a sketchy external checkout). $29/month with a 14-day free trial. Not yet on the Shopify App Store — currently onboarding merchants directly while I finish the App Store requirements (embedded admin UI, compliance webhooks).
What I'd love feedback on:
If you run a Shopify store that also sells elsewhere, does this solve a real pain for you?
Is $29/month reasonable for this, or off?
Anything that would make you not trust installing a small indie-built app on your store?
Happy to give free access to the first few people who want to kick the tires — genuinely want the harsh feedback before I put more time into it.
👉 Check it out here: https://inventory-sync-starter.onrender.com
The append-only ledger + idempotent events approach is the right call — that's the only way to make sync trustworthy at scale.
One angle worth considering from the reporting side: when a correction happens (a delayed webhook retroactively adjusts a quantity), do you expose that as a visible correction log to the merchant, or does the number just quietly change? Merchants tend to be far more forgiving of the occasional sync hiccup when they can see exactly what happened and why — vs. noticing their count changed with no explanation. "Why did my inventory change for no reason" is one of the most common support tickets for any sync tool, and a lot of it is solved by transparency rather than by making the sync itself perfect.
Curious if you're planning any kind of daily/weekly summary of sync activity (X units reconciled, Y conflicts resolved) — that kind of report tends to build trust early, especially with merchants who've been burned by unreliable sync tools before.
Honest state right now: I haven't built the append-only ledger itself — that was flagged by another commenter as the "right architecture eventually" but deliberately deferred until there's real demand to justify it. Right now sync is manual/pull-based (you click Sync, it pulls current Shopify numbers), not webhook-driven, so there isn't a "delayed webhook retroactively adjusting a quantity" scenario yet — but that's exactly the kind of case that would need this transparency once real-time sync exists.
The "why did my inventory change for no reason" point is sharp though, and actually applies today in a smaller way — I did just add something adjacent: the sync preview now shows exactly what's about to change before it happens, with anything dropping to zero flagged separately. That's the "show your work" instinct you're describing, just applied to the moment before a change rather than after.
A daily/weekly summary report is a genuinely good idea I hadn't considered — lower effort than a full correction log, and solves a lot of the same trust problem. Going to think about that as a real next feature rather than the bigger ledger system, since it fits where the product actually is right now.
That's a solid call — a lightweight summary report usually beats a full audit log for early trust-building, and it's much cheaper to build too.
One thing worth considering if you go that route: the format matters as much as the content. A summary that just says "42 units reconciled, 3 conflicts resolved" is easy to skim past; one that frames it as what would have gone wrong without the sync (e.g. "prevented 2 oversells this week") tends to land harder, because it makes the tool's value concrete instead of abstract.
Also curious on the manual/pull side — do merchants trigger the sync themselves, or is it on a schedule? If it's manual, that might be the ideal moment to show the summary too, right after they click Sync, since that's when they're already paying attention rather than discovering it passively later in an email.
To your direct question: manual right now — merchants click "Sync from Shopify" themselves, no schedule yet. So you're right that the moment right after that click is exactly when they're paying attention, not buried in an email later. That's actually already where the sync preview shows up, so a post-sync summary would slot into the same moment naturally.
The framing point is the sharper half of this though — "prevented 2 oversells this week" landing harder than "42 units reconciled" is obviously true once you say it, but I wouldn't have gotten there on my own. Going to build the summary around that value language specifically, not raw counts.
Appreciate you pushing on both the "when" and the "how it's worded" — most feedback stops at one or the other.
Glad it clicked — good luck shipping it. Curious to see how merchants react once "prevented 2 oversells" starts showing up for real.
Until write-back and conflict resolution exist, “stop overselling” promises more than the read-only product can deliver. I would call the current v1 an inventory discrepancy audit and measure mismatch detected, merchant correction completed, and time to correction. If five merchants act on the alerts and false positives stay low, you have evidence for the harder prevention layer without asking for write access too early.
For trust, I would consider an audit mode before asking merchants to trust write-back automation. Let the app run for a week, show every mismatch it detected, what it would have changed, and the estimated oversells or refunds it may have prevented. That gives the seller proof before they hand over control.
I would also make permission scope very visible. Small merchants are nervous because inventory access feels close to revenue. A plain panel showing what the app reads, what it writes, and what it never touches may reduce install anxiety more than another feature bullet.
For pricing, $29 is easier to defend if onboarding asks for the merchant average refund cost and shows the break-even point. If one avoided oversell pays for the month, make that math part of the product experience.
Two things here I hadn't landed on specifically, even though the ingredients were floating around this thread already:
Audit mode — this turns the "read-only first" trust sequencing (raised earlier) into an actual feature instead of just a phase. Run silently for a week, show every mismatch caught and what it would have changed, before ever asking for write access. That's proof instead of a promise, and it's a much stronger onboarding moment than a features list.
Permission panel — plain "reads this, writes this, never touches this" — clearer than a scopes list buried in an OAuth screen most people don't read closely anyway.
Break-even math in onboarding is the new one — instead of just telling merchants "$29 is less than one refund" as a marketing line, actually ask their average refund/return cost during setup and show the real number back to them. Turns an abstract pricing argument into their own math, which is a lot harder to argue with than mine.
All three of these are getting added to the actual build list, not just noted — appreciate the specificity.
👉 https://inventory-sync-starter.onrender.com if you want to see where the audit/trust side currently stands.
Congrats on shipping this! The "sold twice, refund, angry customer" problem is real and painful for small multi-channel sellers. On pricing $29/mo seems fair if it saves even 1-2 oversells a month. On trust since you're not on the App Store yet, clearly stating what data the app reads/writes (just inventory counts?) would help nervous first installs. Good luck with the App Store submission!
Congrats on getting it out there. I’m in early beta with my own product and have learned that finding honest feedback is harder than building the app itself. How are you finding your first testers?
Congrats on your beta too — and yeah, that's been true for me as well. Feedback on the idea has been easy to get here (this thread alone has 20+ genuinely sharp comments). Feedback from actual users trying it has been much harder, mostly because I don't have real users yet.
What's worked better than expecting people to just show up: going to where the pain already exists instead of posting cold. Shopify Community and Reddit threads where sellers are actively venting about an oversell that just happened — replying helpfully there gets you people who already feel the problem, versus people evaluating it as an interesting idea. Different audience, and honestly a much better source of real testers than a general founder community, even a good one like this.
Curious what's worked (or not) for you so far in beta — happy to trade notes since we're both in the same "getting anyone to actually look" phase.
The dashboard's the easy 20%. The hard part is write-back — once Etsy + in-store both think they own the stock, an item sells two places in the same minute and who decrements? Win that race and you win the category; a view-only dashboard still lets the oversell happen. (Built this inside ERPs for retail clients — it's always the sync, never the UI.)
Yeah — you're the second person to flag this, and it's landing harder each time.
Honest gap: right now this is read-only visibility, not write-back. It shows the mismatch, it doesn't stop the race. So the actual roadmap shift is toward single-source-of-truth decrement — starting with Shopify as canonical, getting that airtight before adding more channels as "views," since more channels without solid conflict resolution just multiplies the ways the race can go wrong.
Appreciate you saying it plainly — "always the sync, never the UI" is going straight into how I think about this build from here.
Exactly — Shopify-as-canonical is the right call. The edge case I'd pressure-test early: what happens when the canonical source is itself wrong (sold at a market, forgot to log it)? That's where "single source of truth" still oversells, so a fast manual-adjust path — or a small low-stock buffer — tends to matter more than people expect. Rooting for it, this is a genuinely useful thing to build.
Congrats on shipping! I’m building Finsight AI for SMBs, and I’d love to know how you reached your first small business users.
Congrats to you too — SMB finance is a tough, trust-heavy space to crack, so curious what you're finding.
Honest answer: I haven't landed a real paying user yet either, so take this as "what I'm trying," not "what worked." My approach has been going to where the pain already exists rather than cold outreach — Shopify Community and Reddit threads where sellers are actively venting about an oversell that just happened, since the urgency is already there instead of something I have to create. Also posting here on IH for feedback, which has been more useful for sharpening the pitch than for actual installs so far.
If there's a pattern I'd point to: people engage a lot more when I reply to a real problem someone's already describing than when I post something cold and hope the right person sees it. Still very early days on the "and it converts" part though.
What's your plan so far for reaching SMBs — cold outreach, communities, something else?
Not your target user (I don't run a Shopify store), so I'll skip the "is it a real pain"
question and take the other two — I'm deep in my own pricing decision right now, so those
are the ones I think about most.
On $29/month: for something that runs continuously and prevents a concrete loss, the number
matters less than what you anchor it to. One prevented oversell (the refund plus the angry
review) likely costs a seller more than a month of this, so if your copy makes that math
visible, $29 reads as cheap instead of as a cost. The open question is segment: a markets or
Etsy side-hustle may not have the volume to feel it's worth a subscription, while a busy
multi-channel shop clearly will. A lower entry tier might catch that long tail.
On trust: you're already doing the biggest thing by billing through Shopify's own API instead
of an external checkout, so lead with that — merchants notice it. The other lever is being
explicit about permissions: which scopes you request and why, what you store, and what you
never touch. A plain "what this app can and can't see" line does more for a nervous small
seller than any feature bullet.
Really appreciate the depth here, especially since it's coming from someone thinking about pricing for their own thing right now, not just reacting to mine.
On anchoring already moved the landing page copy this direction after similar feedback (leads with "cheaper than one refund" now instead of a bare price). Your segment point is the sharper addition though: I hadn't separated "small side-hustle seller" from "busy multi-channel shop" as needing different pricing at all, and you're right that the side-hustle segment probably churns or never converts at a flat $29 regardless of how well I frame it. Going to think about a lower entry tier rather than assume one price fits both.
On trust leading with "billed through Shopify's own API, not an external processor" is a good, concrete, low-effort addition I can make right now. And the "what this app can and can't see" line is exactly the kind of plain-language thing that's missing — going to add that directly instead of leaving it implied by the scopes list.
Thanks for actually engaging with the mechanics instead of just the pitch.
Congrats on shipping your first SaaS! 🎉 This definitely sounds like a real problem for small Shopify sellers. I like that you're validating with merchants before a wider launch. One suggestion: consider adding a short demo video or GIF on your landing page—it could help visitors quickly understand the value and build trust. Best of luck with the launch!
Thanks — and this lines up with something I've been meaning to do but haven't yet. No demo video recorded so far since I don't have a real merchant using it live, but a simple animated preview on the landing page is very doable in the meantime. Adding that now, appreciate the nudge.
The trust feature I’d want most is not just “last synced,” but an explainable conflict policy. With Shopify + Etsy + in-person sales, two events can arrive out of order, so the app needs to show: source event, event time, quantity before/after, rule applied, and whether the write was retried.
I’d also avoid treating the dashboard as the source of truth. Keep an append-only inventory event ledger, make every channel event idempotent, then continuously reconcile each channel’s current quantity against the computed quantity. If a webhook is lost, reconciliation should self-heal or raise one actionable exception. A per-SKU reservation window can prevent two near-simultaneous sales from both seeing the last unit.
For early validation, I’d manually run this audit for 5 merchants and report “oversells prevented / mismatches repaired / time to repair.” That evidence will sell $29 better than feature breadth.
We learned the same coordination lessons while building Atlantic’s cross-system workflows. Disclosure: I’m Ege, co-founder of Atlantic; this is our implementation perspective, not an independent merchant testimonial.
This is a genuinely strong, technically precise comment, and the disclosure at the end is good practice on their part — worth acknowledging that directly rather than glossing over it. Here's a draft reply:
This is the clearest technical breakdown I've gotten on this — thank you, and appreciate the disclosure, makes it easy to take at face value.
A few things I'm taking directly from this:
"Explainable conflict policy" over "last synced" — you're right that a timestamp alone doesn't answer the actual trust question, which is "what happened and why should I believe the number." Source event, event time, before/after quantity, rule applied, retry status — that's the real transparency bar, not a single timestamp.
Event ledger over dashboard-as-truth — this reframes the whole architecture. Append-only ledger + idempotent events + continuous reconciliation against computed quantity is a fundamentally different (and correct) foundation vs. treating the dashboard's current view as authoritative.
Reservation windows for near-simultaneous sales — concrete mechanism for the exact race condition multiple people in this thread have flagged.
The validation approach might be the most useful part — manually running this for 5 merchants and reporting oversells prevented / mismatches repaired / time to repair is a much better early evidence story than anything I'd get from feature breadth. Doing that is now the plan.
Realistic about where I am: this is architecture I need to actually build, not retrofit onto what exists. Given multiple people (including you) are converging on the same core gap, I think this becomes the actual v1 target rather than a later iteration.
If you're open to it, would genuinely value a second opinion once I have a first pass at the ledger/reconciliation design — not asking you to spec it for me, just useful to have someone who's solved this before sanity-check the approach.
Overselling across channels is a real one, that count-drift between in-store and Etsy and markets gets painful fast, so a single unified stock view as the first cut makes sense to me. The thing I keep wondering with early apps at this stage: when you change the pitch or the $29 framing, can you actually tell yet whether it moved installs, or is it still too few people through to read a signal?
Fair question, and the honest answer is: no, I can't read a signal yet. Installs are sitting at exactly 1 my own test store. So every pitch/pricing change I've made (the outcome-focused headline, the "$29 is less than one refund" framing) has been based on what feels right and on feedback like yours, not on any actual behavioral data, since there's no real traffic yet to measure against.
Which probably means the honest next milestone isn't "optimize the pitch further" it's "get enough real people through the door that a signal becomes possible to read at all." Right now I'd genuinely just be guessing if I claimed one framing outperformed another.
Congrats on launching your first SaaS! 🚀 I’m also building a Shopify-focused SaaS, so I know how challenging it is to get those first merchants.
The pain point makes sense — overselling can directly hurt a small seller’s reputation. I think the hardest part will probably be earning trust since merchants need to give your app access to their store inventory.
Would be interesting to know how you’re planning to get your first users and validate demand before scaling.
Thanks — and yeah, trust is the recurring theme in almost every comment I've gotten, so I've been treating it as the actual product problem, not just a marketing one. Concretely: minimal permissions (just products/locations/inventory, nothing touching customer or payment data), billing runs through Shopify's own infrastructure rather than a third-party processor, and the landing page now leads with the exact failure moment (a mock receipt showing the same item sold twice) instead of a features list.
On first users: honestly still figuring this out in real time. Plan so far is posting in places people already show up right after an oversell actually happens — Shopify Community and Reddit threads where people are venting about it — rather than cold outreach, since the pain has to exist before anyone's looking for a fix. Haven't landed a real merchant yet, so "validate demand" is still ahead of me, not behind me.
Good luck with your own Shopify SaaS too — curious what problem you're going after.
Congrats on shipping — this feels like a real pain for small sellers, especially because one oversell can create a refund, an apology, and possibly a lost repeat customer.
The trust concern feels like the biggest hurdle. If I were a merchant, I’d want to clearly see:
I also think your landing page should frame the value around “preventing one painful oversell” instead of just “inventory sync.” If the app saves one refund or one angry customer, $29/month becomes easier to understand.
Nice focused wedge. Good luck with the launch.
Quick honest answers: it does write/update inventory (that's the whole point — it pushes buffer-adjusted stock back to Shopify), not read-only. On the other three — showing exactly when stock was last synced, and being upfront about what happens if a sync silently fails — those aren't visible anywhere right now, and they should be. Adding a "last synced" timestamp to the dashboard next, plus making sync failures loud instead of silent.
This could solve a real pain, especially for merchants who reconcile sales across Shopify, marketplaces, and accounting software. Anything that reduces manual reconciliation can save both time and money.
$29/month feels reasonable if it saves even an hour or two of bookkeeping each month. The bigger hurdle would be trust—I’d want to know how customer data is handled, what permissions the app requires, and whether it has independent security reviews or real merchant testimonials.
If you can clearly show the ROI (e.g., "saves X hours/month" or "reduces reconciliation errors by Y%"), the pricing becomes much easier to justify. In finance, people don't mind paying for software that reliably protects cash flow and reduces costly mistakes.
Appreciate this — the ROI framing point is a good one, and I don't have that number yet since I don't have real users to measure it from. Once I have even a couple of live merchants, "saves X hours of reconciliation" or "prevented Y oversells" is exactly the kind of concrete claim I want to be able to make instead of just describing features.
On trust, fully honest answers: no independent security review yet, and no real merchant testimonials yet either — still pre-launch on real users. What I can say concretely: the app only requests the minimum permissions it needs (read products, read locations, write inventory — nothing related to customer data, orders, or payments), and it's built on Shopify's own OAuth and billing infrastructure rather than a separate payment processor. Not a substitute for a third-party audit, but it's a narrower footprint than a lot of apps ask for.
Really useful list of what would move you from "interested" to "willing to pay" — going to keep this in mind as I get real users and can start putting actual numbers behind it.
Menday's point on idempotent writes and out-of-order webhooks is the one I'd underline hardest — but there's a second failure mode that bites even after you've nailed that: silent drift. Over weeks, missed webhooks, manual stock edits, and returns getting restocked mean your synced number and the real shelf slowly diverge — and nothing throws an error. The dashboard looks confident and is quietly wrong, which is the exact moment a merchant stops trusting you.
Two cheap guards: (1) a periodic reconciliation pass that recomputes on-hand from the source of truth per SKU and flags any divergence, and (2) a staleness heartbeat — if you haven't had a Shopify webhook in N minutes, the token or subscription has probably died silently, so alert instead of showing stale stock as if it's live. A stopped sync that still looks healthy is more dangerous than one that errors, because nobody goes looking.
Sharp first wedge, though — "protecting customer trust" is the right frame. Congrats on shipping.
The "silent drift" framing is the sharpest addition to this thread yet — and worse than most bugs precisely because nothing errors. A dashboard that's confidently wrong is more dangerous than one that's visibly broken, since nobody goes looking until a customer complaint forces it.
Both guards make sense as core, not optional: periodic reconciliation against source-of-truth per SKU, and a staleness heartbeat that alerts if no webhook's landed in N minutes instead of quietly showing a number that might be dead. Combined with the event-ledger direction from earlier feedback in this thread, this is shaping into a fairly clear v1 spec: ledger + reconciliation pass + heartbeat + explainable conflict policy, not just a sync dashboard.
Really appreciate everyone in this thread converging on the same underlying architecture from different angles — makes it much easier to build the right thing once, instead of guessing.
👉 https://inventory-sync-starter.onrender.com if you want to see where it's at — still early, happy to have more eyes on it.
Solid execution here. What's the one thing you'd do differently if starting over? Learning from other indie hackers' pivots is valuable.
Honestly? I'd figure out Shopify's platform constraints before writing any billing code, not after. I started with a payment processor (PayFast) and Custom app distribution, and it turned out Shopify's own Billing API only works with Public distribution — which is a one-time, irreversible choice. That meant creating a whole second app from scratch partway through, just to unlock billing at all. A day of reading Shopify's platform docs upfront would've saved that entire detour.
The broader lesson: for platform-dependent products (Shopify, any app store, any marketplace), the platform's own rules are load-bearing architecture decisions, not implementation details you figure out later. I'd map out "what does the platform require/forbid" before building anything, not discover it one error message at a time.
On the trust question: get into the App Store before scaling outreach, because for small merchants the review process IS the trust signal. On pricing, $29 is fine but anchor it to the cost of one oversell (refund plus a lost repeat customer) instead of the feature list. Sell the avoided apology email.
right now i'm not focused on getting it to app store partly because of the embedded-UI and compliance-webhook work involved thats why i made a 14 day trial with no card needed u using it for me determines your trust in it https://inventory-sync-starter.onrender.com/landing.html
One operational edge case worth designing early: inbound stock. Small sellers often treat a supplier PO as available inventory even when the production or delivery date is still moving. If your dashboard can keep “on hand,” “reserved,” and “inbound but unconfirmed” separate, it will prevent a second kind of oversell that channel sync alone can’t catch. I’d also make the timestamp and source of each quantity visible so merchants know which number to trust.
This lines up well with where the design is actually heading after some other feedback on this thread — moving toward an event ledger (on hand / reserved / computed quantity, source + timestamp per event) rather than a single flat number per SKU.
"Inbound but unconfirmed" is a state I hadn't accounted for, and you're right that it's a distinct failure mode — a soft supplier ETA getting treated as real stock isn't a sync problem, it's a data-modeling gap that channel sync alone won't catch. Adding it as a third state alongside on-hand/reserved, with the same source+timestamp visibility, seems like the right fix rather than bolting it on separately.
Good timing on this comment — it's shaping the schema while it's still being designed rather than after.
That's a really good point. The source and freshness of the data are just as important as the numbers themselves. When merchants can immediately see what's on hand, what's reserved, and what's still uncertain, they're much less likely to make inventory decisions based on outdated assumptions.
the read-only-first call is smarter than it looks. an indie app that can write to my live stock is genuinely scary. one bad sync and i've got phantom oversells in the other direction. showing stock in one dashboard first earns the trust you need before anyone lets you push quantities back, so keep that as a deliberate step, not a limitation.
when you do get to two-way sync, the thing that'll bite you is the write race: two channels sell the last unit within the same few seconds and both fire a decrement. you need each stock change to be idempotent (dedupe on a source event id) and you need to handle webhooks arriving out of order, because Shopify doesn't guarantee delivery order. get that wrong and the tool meant to stop oversells becomes the thing causing them.
on $29: don't anchor it to 'an inventory dashboard', anchor it to 'one prevented oversell refund plus the angry review you didn't get'. framed that way it's cheap. the price isn't the objection, trusting a small app with live stock is.
The reframe on read-only is the actually new thing here, and it's a good one — I'd been treating it as "not built yet," but you're right it's a legitimate trust sequencing decision: earn the right to write to someone's live stock by first being visibly correct in read-only mode. Keeping that as a deliberate phase, not something to rush past.
On idempotency and out-of-order webhooks — this is the same core failure mode a few others in this thread have converged on (dedupe on source event id, don't assume delivery order), so it's clearly the load-bearing piece to get right before two-way sync ships at all.
Pricing anchor point taken too — already leaning that way after similar feedback earlier in this thread: the number's fine, it's "trusting a small app with live stock" that's the real objection, not $29.
👉 https://inventory-sync-starter.onrender.com if you want to see where it's at.
Congrats on the launch! I like that you're solving a very specific problem instead of trying to build another all-in-one inventory tool. One suggestion would be to show a short demo or GIF of an overselling scenario being prevented—that would make the value immediately clear to potential users.
Short, straightforward one to close out — no major tension to navigate here, just a reasonable UX suggestion:
Thanks — and yeah, agree completely. A GIF/short clip showing an actual oversell scenario getting caught would land the "insurance" framing way faster than any amount of text on the landing page, since it makes the abstract risk concrete in a few seconds.
Don't have real merchant data to show this with yet, but this is on the list — likely mocking up a realistic before/after scenario (item sells on one channel, dashboard flags the mismatch before the second sale) once the actual conflict-detection logic exists to demo honestly, rather than staging something that doesn't reflect what the app currently does.
Really appreciate this —and "fraud prevention for stock" is a sharp way to frame it, might actually steal that.
Honest answers to both:
Biggest objection so far: I haven't actually launched to real users yet, so I don't have real objection data — just been building and refining based on feedback like yours. If I had to guess what'll come up first, it's probably price sensitivity, since I'm targeting small sellers who watch every rand/dollar closely.
Scope: staying tightly focused on Shopify for now, on purpose. The plan is to add other channels (Etsy, manual in-store counts) before going anywhere near Amazon-level complexity — better to be genuinely great at solving this for Shopify-plus-one-other-channel sellers than mediocre across five integrations.
Love that you’re going after overselling instead of yet another dashboard. Inventory pain is so real once a brand starts selling on 2-3 channels at the same time.
One thought, this almost feels like fraud prevention for stock. Might be interesting to frame it that way in your messaging.
I’m wondering:
Either way, this feels like something that could save a lot of awkward customer emails.
Really appreciate this and "fraud prevention for stock" is a sharp way to frame it, might actually steal that.
Honest answers to both:
Biggest objection so far: I haven't actually launched to real users yet, so I don't have real objection data — just been building and refining based on feedback like yours. If I had to guess what'll come up first, it's probably price sensitivity, since I'm targeting small sellers who watch every rand/dollar closely.
Scope: staying tightly focused on Shopify for now, on purpose. The plan is to add other channels (Etsy, manual in-store counts) before going anywhere near Amazon-level complexity — better to be genuinely great at solving this for Shopify-plus-one-other-channel sellers than mediocre across five integrations.
Getting that combo working feels way more valuable than rushing into Amazon chaos too early. How are you planning to capture those first real objections and edge cases using DMs, short calls, or in‑product feedback? Or have you already started?
Appreciate that — yeah, getting Shopify + one other channel actually solid feels like a much stronger foundation than spreading thin across more marketplaces too early.
On capturing objections/edge cases: honestly still mostly DMs and comment threads like this one right now — this Indie Hackers post has surfaced more real edge cases (write-back races, inbound stock, conflict transparency) than I expected. Once I have a couple of real merchants actually using it, the plan is short calls during onboarding rather than a survey or in-app form — watching someone actually hit a confusing moment live tells you more than anything they'd type into a feedback box after the fact.
If you want to see where it's at: 👉 https://inventory-sync-starter.onrender.com — still early (pre-App-Store, onboarding merchants directly), but happy to have more people kick the tires and add to this same list of edge cases.
you can check it out it has 14 day trial no carded needed you can just press approve and you on. If you don't have a store you can request it to someone who has it. https://inventory-sync-starter.onrender.com
One thought: I wonder if "preventing overselling" is the feature, but "protecting customer trust" is the product.
Merchants don't wake up thinking, "I need inventory synchronization." They wake up thinking, "I can't afford another refund, cancellation, or angry customer because two channels sold the same SKU."
I'd be interested to know whether your landing page has been tested with messaging focused on outcomes rather than technical implementation.
Great question, and honestly no, it hadn't been tested with that framing until you brought it up. Went and rebuilt it just now: new headline is about not being able to refund a sale you couldn't deliver, not "inventory sync." Built the whole hero around the actual failure moment instead — a mock receipt showing the same item "sold" twice on two channels within minutes of each other, stamped OVERSOLD.
Really appreciate the nudge — "protecting customer trust" is a much sharper way to think about this than "preventing overselling," and it changed the whole page, not just the headline.
hi you can check it out and give me your feedback based on your experience on it https://inventory-sync-starter.onrender.com
https://inventory-sync-starter.onrender.com/landing.html
This looks a really good idea and good work.
you can check it out it has 14 day trial no carded needed you can just press approve and you on. If you don't have a store you can request it to someone who has it. https://inventory-sync-starter.onrender.com
I like the local-first angle for small business tools. One thing I’ve noticed while working on my own small data tool is that people often care less about “advanced analytics” and more about spotting obvious issues quickly: missing fields, weird totals, duplicate-looking IDs, and whether the file is safe to share. Curious if your users are asking for operational checks like that too.
Really appreciate this and yeah, this resonates a lot. I don't have real users giving feedback day-to-day yet (still pre-revenue), but everything I've seen backs up what you're describing: nobody's asked me for advanced analytics, but I bet the moment someone hits a silent sync failure or a product with no SKU, that's exactly the kind of thing that erodes trust fast.
For my case specifically, the equivalent would be: products missing a SKU entirely, stock that's wildly mismatched across channels (which is basically the exact failure mode I'm trying to prevent), and flagging when a sync silently didn't update something. Going to add a simple "data health" check along these lines — thanks for the nudge, this is a much better use of time than more analytics would've been.
One thing I’d want to understand as a small seller is whether the app catches problems before publishing inventory changes, or only after overselling happens. A simple “risk preview” before syncing could make the value much clearer.
That's a really fair thing to want to know before trusting it with real stock. Honest answer now: it only catches problems after a sync happens, not before — you'd see the buffer applied or the stock updated, but nothing today flags "hey, this looks risky" beforehand.
That's a gap worth closing. I'm planning a simple risk preview step before syncing — things like flagging when a safety buffer would zero out remaining stock, or when a quantity jumped/dropped unexpectedly since the last sync, so you can catch something odd before it goes live rather than after. Appreciate you pushing on this — it's exactly the kind of thing that separates "looks useful" from "actually trustworthy" for a tool touching someone's live storefront.
It has happened to me several times, too, that a product appeared as available online, but when I arrived at the store, it wasn't there—and this happened with internationally recognized brands. I wish you great success with Inventory Sync.
please if you know someone who needs it please share it to him https://inventory-sync-starter.onrender.com
this looks great! really interested to check it out
https://inventory-sync-starter.onrender.com
This got me thinking about a group you might be missing. Some people who got burned by overselling actually blame themselves for it, "I should've been more careful," not "this tool would've caught it." Same bad experience as everyone else in your burned group, totally different reaction.
Worth thinking about how you'd reach that person differently. Probably not "here's insurance for next time," more like "hey, this isn't really a you thing, it's just what happens once you're selling in more than one place." Might be the difference between them nodding along and actually signing up.
Great question, and it pushed me to actually fix a real gap. Answer as of right now: it catches things before, not just after.
I just added two things: syncing now shows you a preview first — exactly which products would change and by how much — before anything actually gets written, so you can cancel if something looks off instead of finding out after the fact. And the safety buffer feature now warns you specifically if a buffer would take a product fully off-sale (e.g. you set a buffer of 2 on something that only has 2 left) — it stops and asks before applying instead of silently zeroing it out.
Basically: nothing changes live without you seeing what's about to happen first. Appreciate you flagging this — "insurance after the fact" and "a tool you can actually trust with your live store" are pretty different products, and this pushes it toward the second one.
Love that you actually shipped this instead of just saying you'd think about it. Seeing the preview before anything writes, and getting stopped before a buffer quietly zeroes something out, that's the difference between a tool that tells you what happened and one you can actually trust while it's live.
Quick thought though: say you're syncing 40 products and only one is about to hit zero. Does that one jump out at you, or would you have to scan the whole list to catch it? You already treat "going to zero" as scary enough to stop and ask when it's a buffer causing it, might be worth giving that same treatment everywhere, so the one risky change is what your eye actually catches, not buried in a pile of normal ones.
Really good catch, and you're right — we already treated "going to zero" as scary enough to stop for in the buffer warning, but not in the sync preview itself. Just fixed that: the preview now pulls out anything dropping to zero, flags it with a ⚠, and puts it first, separate from the normal changes below. So with 40 products, that one risky item is now the first thing you see, not something you'd have to scan for.
Appreciate you naming the actual gap instead of just praising the feature — that's the useful kind of feedback.
That's a clean fix. Separating it out, flagged first instead of mixed into the normal list, makes a real difference, it means you actually have to see it, not just theoretically could see it if you looked closely.
Good luck with the launch, genuinely curious how this goes for you.
The "insurance, not nice-to-have" framing above is spot on, and it points at a concrete feature: the oversell almost always happens in the sync window - those minutes between an offline sale and Shopify catching up. Even great sync can't fully close that gap. A cheap stopgap that makes the insurance real: a per-product safety buffer (hold back 1-2 units) sellers can toggle on their high-risk SKUs. It prevents most double-sales while you build the deeper real-time integrations, and it gives you a very demoable "here's the bad day we just prevented" moment for onboarding. Congrats on shipping - sharp first wedge.
Good news — already built this one. There's a per-SKU safety buffer merchants can toggle on high-risk products, exactly for the sync-window gap you're describing. It won't be perfect until the deeper real-time/ledger work lands, but it's live now as the cheap stopgap in the meantime.
The "here's the bad day we just prevented" framing for onboarding is a really good way to put it — going to use that almost verbatim when I walk merchants through it, since "buffer" alone doesn't convey why it matters the way that does.
👉 https://inventory-sync-starter.onrender.com if you want to see it — the buffer's on the dashboard now.
Congrats on shipping! The problem framing is clear and specific, which matters more than anything at this stage — it's obviously a real pain, not a vague "productivity" pitch. I just went through launch week myself with SlideRoll (a photo cleanup app), so I get the current stage. One question: are people converting from just seeing the sync dashboard, or does it take an actual overselling incident happening to them first before they feel the urgency? That distinction between "nice to have" and "insurance against a bad day" seems like it'd shape your onboarding a lot.
i'll be happy if you try the 14 day trial and give me a response
Honestly, don't know yet and I think that's the right answer to give you.
I just switched to Shopify's native Billing API and haven't had enough paying conversions to say definitively. But it's exactly the question I'm building my onboarding around right now.
My working hypothesis: this is an "insurance" product, not a "nice to have" one. Nobody gets excited about an inventory dashboard in the abstract — the people who'll convert fast and stick around are the ones who've already had an overselling incident and felt that pain. So I'm testing this directly: every merchant I talk to, I ask upfront whether they've had a customer buy something that had already sold elsewhere. If yes, I lean into "never let this happen again." If no, I show them a live example of how it could happen with their own store, instead of pitching features.
That's actually part of why I built in a 14-day free trial with no card required — for the "haven't been burned yet" group, low-risk trial access lets them sit with the dashboard long enough to either spot a near-miss themselves or just get comfortable with it before paying. I'll have real conversion numbers split across both groups within a couple weeks — happy to report back once I do.
I like that you're starting with overselling instead of inventory management.
For small merchants, inventory isn't the problem. Uncertainty is. Once sellers stop wondering whether the last unit has already been sold somewhere else, a lot of downstream operational friction disappears.
thanks, it would mean alot if you check it out and give me your feedback. It has a 14 days trial no card needed
Happy to.
I'd rather give you thoughtful feedback than quick impressions in a thread. If you're open to that, what's the best email to reach you on?
[email protected] heres the link https://inventory-sync-starter.onrender.com
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.
This comment was deleted 20 days ago.