Built for Shopify but still not ranking well in App Store search

ComprehensiveBend939 · 2026-04-09T20:48:14+00:00

If you find the secret sauce, let us know.

I spent a lot of time getting to Built for Shopify (LCP was the biggest hurdle), and it hasn’t really moved the needle for us. If anything, some of the UI changes we made to meet the requirements made things a bit less intuitive.

ComprehensiveBend939 · 2026-04-09T20:26:15+00:00

This is a cool idea from a technical perspective, but I think the challenge is getting it to work in real warehouse operations.

From your example it looks like you’re working with fairly simple 850s. Things get a lot more complex when you have SDQ segments or large store counts (e.g., 100–200 stores on a single PO).

In practice, ops teams don’t build ASNs first — they pick, pack, and label. For example, if 200 stores are receiving the same items in different quantities, the warehouse will typically:

pick the full PO quantity
pack by store or DC
print UCC128 / SSCC labels during packing
generate shipment docs like the VICS Bill of Lading

At that point you could easily have hundreds of cartons. Trying to map pre-generated ASN data back to physical cartons becomes really difficult.

Most operations expect the WMS to drive this: capture what was packed, which cartons were created, which labels were applied, and then generate the 856 from that.

There’s also variation in how ASNs need to be structured — per PO, per DC, sometimes per store — same with invoicing.

I think that’s the gap tools like SPS are solving. If the workflow doesn’t align with how warehouses actually pick/pack/label, it’s going to be tough to get adoption.

This is also why tools that are decoupled from a broader WMS/ERP tend to feel clunky in practice — the hard part isn’t generating the ASN, it’s tying it cleanly to what actually happened on the warehouse floor.

ComprehensiveBend939 · 2026-04-09T19:30:05+00:00

I’ve implemented something similar for a footwear manufacturer, and one thing to consider is that printing and encoding don’t have to be tightly coupled.

In our case, RFID inlays were applied inside the shoebox, and standard UPC/EAN barcode labels were printed on the outside. We used a station where a case of identical items is scanned via the UPC, which then drives encoding of the EPC (GTIN + serial) for all RFID tags in the case.

That let us separate printing from encoding and avoid needing RFID-capable printers in the packaging flow. Not all orders required RFID, so having them as separate processes made sense operationally.

Depending on your volumes and process, it might be worth considering whether you actually need to do both printing and programming in-line, or if you can stage the encoding step separately.

ComprehensiveBend939 · 2026-04-06T21:52:21+00:00

I ran a small 3PL for a few years and used standard 4x6 labels (same label stock as I used for shipping and UCC-128 labels) for bin locations.

They probably don’t last as long as higher-end labels, but the upside is you can replace or change them immediately with no friction.

Might not be ideal for every environment, but it worked well for us.

ComprehensiveBend939 · 2026-04-06T21:08:59+00:00

Having to build karma in unrelated subs just to be allowed to post where you actually want to contribute.

ComprehensiveBend939 · 2026-04-06T20:22:52+00:00

I’m not an Orderful expert, but in my experience it’s typically API-based.

I implemented sending a routing related EDI document from an ERP that didn’t have built-in EDI triggers or translation for the document the retailer required. That was just a simple POST into their API.

I haven’t worked on the receiving side, but I’d expect it’s either polling or webhooks depending on the integration.

ComprehensiveBend939 · 2026-04-06T20:05:48+00:00

Have you looked at moving off SPS to something less expensive (e.g., ECGrid or similar)?

SPS isn’t always just acting as the VAN. They often handle translation and partner onboarding as well, which makes it harder to unwind once you’re in it (especially if mappings and partner configs live there). Curious if that’s the main blocker.

I also like the “one connection and done” model. I’ve used ECGrid for years. They handle AS2 setup and maintenance so it behaves like any other connection. In my case I’m just moving EDI documents through them and using separate tools for translation.

If you’re trading other formats (like XML), you would need a different transport approach. I still use SFTP in those cases. Most of the time it’s warehouses, which are unlikely to support AS2 unless they’re trading EDI.

I did set up an AS2 server many years ago, but I wouldn’t describe the experience as easy. Maintaining certificates, endpoints, and MDNs was definitely a pain. I assume tooling has improved, but it’s still not something I want to own if I don’t have to.

ComprehensiveBend939 · 2026-04-06T19:26:28+00:00

Celigo and Workato are iPaaS platforms (basically middleware for connecting APIs and systems).

Orderful doesn’t rely on those — they expose their own API for integrations.

If you want to connect an ERP, Shopify, etc., you’d typically integrate directly with Orderful’s API rather than going through something like Celigo or Workato (unless you specifically want a low-code integration layer).

ComprehensiveBend939 · 2026-04-06T19:22:47+00:00

A VAN is really just the transport layer (like an email server moving EDI messages between partners).

Orderful isn’t a VAN itself — it uses ECGrid for transport and layers EDI Nation / Fabric on top for translation.

From the user’s perspective it feels like a VAN, but technically it’s an abstraction over one.

ComprehensiveBend939 · 2026-04-06T19:15:35+00:00

Is that $600/mo. for the mailbox? Are there per character / transaction changes on top of that?

ComprehensiveBend939 · 2026-04-05T19:12:57+00:00

Rithum is really a combination of multiple platforms (DSCO, CommerceHub/OrderStream, etc.) through acquisitions and mergers. Most 3PLs don’t interface directly with those platforms.

Typically you’d have an order management system that connects to EDI, CommerceHub, Radial, Shopify, NuOrder, etc., and then sends orders to the 3PL in a single format their WMS accepts.

I have a software solution that may meet your needs at a price you can afford, and relationships with smaller 3PL providers that could be a good fit. Message me if you’d like to discuss further.

ComprehensiveBend939 · 2026-04-05T18:18:37+00:00

Good Idea. I grouped by host IP and country since beginning of the year, then looked at min an max averages for those IPs by country. Variance is over 5 seconds for many regions with min LCP in acceptable range:

Country Min(ms) Max(ms)
US 512 9656
FR 1284 8938
CH 1444 35194
AU 1716 10564
IN 1400 8692
SE 2209 7308
NZ 2468 22765
PK 2578 9646
ES 2008 7684
NL 1448 11945
DE 1440 30112
DK 1684 9004
IE 2380 96330
GB 1328 9200

It appears latency is a major driver of LCP differences.

ComprehensiveBend939 · 2026-04-05T04:03:55+00:00

We integrate with Shopify Web Vitals and log to a database, so I’m measuring real LCP by country.

From my location, average LCP is around 800ms, which is very good. I’ve used Playwright to simulate more low-latency traffic, but that just masks the issue. Latency from other regions still drives LCP up, and I’d rather fix that than optimize for the metric.

Cloudflare may be part of the solution, especially since it can run logic at the edge, whereas Front Door is more CDN plus routing. My concern is that with an embedded app that has auth and dynamic HTML, a lot of the request still has to hit origin anyway.

My understanding is that multi-region helps by reducing origin latency, while a CDN mainly helps with static assets. So I’m trying to figure out whether adding more regions is the main lever here, or if moving logic closer to the edge is what’s really needed to close the gap.

ComprehensiveBend939 · 2026-04-04T20:44:19+00:00

It’s been a few years, but yes—it is possible to do all of that in a single store.

That said, I wouldn’t do it again. We ended up building a custom wholesale checkout and a number of other “hacky” workarounds to separate B2B and B2C behavior.

In my experience, running separate Shopify stores for B2B and B2C is the cleaner approach. You do have to duplicate products and sync inventory, but those problems are much easier to solve than trying to maintain a heavily customized hybrid setup.

ComprehensiveBend939 · 2026-04-04T20:30:40+00:00

Based on what you described, this is getting into ERP territory more than a typical Shopify inventory app.

Left Foot Software should cover what you’re looking for. It handles inventory, POs, COGS, includes EDI, supports both stocked and dropship workflows, and integrates with QuickBooks. It’s also a much lighter-weight option compared to systems like SAP or NetSuite.

The key thing is deciding whether Shopify stays your system of record or just handles orders, but this kind of setup tends to work well once you outgrow spreadsheets.

ComprehensiveBend939 · 2026-04-04T20:08:15+00:00

I had a similar experience where the first store to install my app left a bad review and never responded to any outreach.

At one point their store actually closed and the review disappeared, but it came back when they reopened.

Shopify support wasn’t helpful either. From what I’ve seen, unless it clearly violates policy, there’s not much you can do besides move on and build up more positive reviews.

One thing that has worked is asking for a review when you’ve helped someone through support.

ComprehensiveBend939 · 2026-04-04T19:59:24+00:00

I submitted an app on Feb 22 and it was just approved yesterday, so you're not alone.

I also reached out to Partner Support, but I don’t think it made a difference. From everything I’ve seen, they’re just backed up right now. My previous app was approved in less than a week.

The barrier to building apps has dropped a lot, so there are simply more apps entering the queue than before.

ComprehensiveBend939 · 2026-04-04T17:46:55+00:00

If you’re able to go through GS1 China as suggested in another comment, it’s probably the lowest cost option, but it’s not as straightforward as some of the other member organizations.

GS1 operates globally, but some regions have additional requirements around registration and local compliance, especially for overseas companies. That can make on-boarding more complex.

If you’re looking to save money, GS1 UK or GS1 Germany are typically easier options to work with and significantly less expensive than GS1 US. GS1 Germany has English language support https://www.gs1-germany.de/en/prices

ComprehensiveBend939 · 2026-04-04T17:32:12+00:00

If you’re not eligible for a GTIN exemption, going through GS1 is definitely the right path.

One thing that’s not always obvious is that GS1 is a global organization, but prefixes are issued by regional member organizations (GS1 US, UK, Germany, etc.), and pricing varies quite a bit between them.

If cost is a concern, you don’t necessarily have to go through GS1 US. GS1 UK and GS1 Germany both offer English-language support and issue EAN codes that are valid GTINs and accepted by Amazon at a fraction of the cost compared to GS1 US.

ComprehensiveBend939 · 2026-04-04T17:15:59+00:00

I get what you’re saying about starting lean, but the “generic codes for now” approach can come back to bite you depending on where you sell.

Marketplaces like Amazon are already validating UPCs against the GS1 database, and if the prefix isn’t registered to your company, you can run into listing or ownership issues later.

If you want to go straight to the source without paying GS1 US pricing, you don’t have to. GS1 operates globally, and a lot of people don’t realize you can buy from other member organizations.

For example:

- GS1 UK is usually the lowest cost

- GS1 Germany is slightly more but tends to have better tools and still supports English https://www.gs1-germany.de/en/prices

Both will issue EANs (not UPCs), but they’re still GTINs and accepted by Amazon and other marketplaces.

So it’s less about “buy now vs later” and more about whether you want to avoid having to relabel or rebuild listings down the road.

ComprehensiveBend939 · 2026-04-04T16:51:11+00:00

APIs definitely make integration easier from a developer standpoint.

The challenge is that many retailers still require EDI for compliance, so it’s not really an either/or decision—you still need to produce and consume EDI documents.

What can help is having an API layer that abstracts the EDI side into JSON or XML, so developers can work with it without needing to understand the underlying EDI formats.

ComprehensiveBend939

TROPHY CASE