Will StoreTwin fit this client? A six-question check
Six yes-or-no questions about the client's setup. Every "no" below says plainly that we are the wrong tool and why - an unsuitable pilot costs you a week and costs us a review, so it is cheaper for both of us to find out here.
The six questions
1. Is there exactly one store that owns the catalogue?
Yes - Good. One store is edited by the team, the others receive. That is the model the whole app is built on.
No - We are the wrong tool. If both stores are edited and both must win sometimes, you need two-way sync with conflict rules - a different product with different risks.
2. Is it acceptable that edits made in the receiving store are overwritten on the synced fields?
Yes - Good. The source is the truth: a title changed in the receiving store goes back to the source value at the next check.
No - We are the wrong tool for those fields. If the receiving store must keep its own titles or descriptions, either exclude those products from the selection or expect the difference to be reported and repaired.
3. Can the client work without syncing orders and customers?
Yes - Good. The app never asks for those permissions at all, which also shortens the security review on the client side.
No - We are the wrong tool. Order forwarding between stores is a different category - look at apps built for supplier-retailer flows.
4. Does each store hold its own stock, or does another system close the loop?
Yes - Good. We copy stock numbers one way, per location, only for the locations you map.
No - We are the wrong tool. A sale in the receiving store does not reduce the source store's stock - there is no shared pool. That case needs pooled inventory: see the page on wholesale and retail stock.
5. Does the receiving store set its own prices?
Yes - Good. A price is set once, when a product is first created there, and never touched again.
No - Ask what exactly is needed. If prices must follow the source store on every change, we do not do that on purpose - a price is a decision, and overwriting it hourly undoes somebody's work.
6. Is it acceptable that images arrive when a product is first created, and later differences are reported rather than fixed?
Yes - Good. That is exactly what happens, and the report names which product differs.
No - Ask us first. Topping up images on an existing pair duplicates them, which is why we report instead - if this blocks the pilot, tell us the case and we will say honestly whether it is on our roadmap.
If every answer was yes
Then the pilot is a short one: install in both stores, pair them with a code, and leave the connection in checking-only mode for a few days. The app compares the catalogues hourly and fully once a day and names every difference by product and field - so the client can see what would have been copied before anything is written.
The audit is free on any catalogue size, including a catalogue that another sync app is keeping. That makes it usable as a second opinion on a setup you inherited: how the audit works.
What we ask from you in return
If a pilot fails, tell us why in one sentence. We keep a list of decisions we deliberately have not changed, with the exact signal that would bring each one back - a real client stumbling on one of them is that signal, and it beats any amount of internal debate.
Agency questions, including several stores at once: support@storetwin.app.
If the answers were yes, the free plan is enough for the whole pilot: it audits a catalogue of any size and syncs 25 products you pick.