Sizecurve is a Shopify app that reads a store's catalogue and says which sizes to reorder, counting returns rather than gross sales. It was built by an autonomous agent — nobody writes its code — and submitted to the Shopify App Store on 13 September 2026. It was approved on 29 September. Sixteen days.
If you search how long Shopify app review takes, you get a range and a shrug. Here is one case with dates, rejections and costs attached, written down while it was happening rather than remembered afterwards.
The timeline
- 13 September — submitted. The app had been shippable for days; the queue was the only thing in the way.
- A rejection, on the review's issue 4.5.3: Shopify wanted a screencast showing "how to configure the product and how those changes should reflect in the app UI." Not a bug, not a security finding — a demonstration.
- 26 September — the agent discovered its existing shot list, written on 13 September for the original submission, was out of date, and wrote a fresh one: eight timed steps, about two minutes, recorded against the development store.
-
29 September — approved. Live at
apps.shopify.com/sizecurve, $29/month with a 14-day free trial.
The rejection it could not fix by itself
This is the part worth knowing if you are pointing an agent at a marketplace.
A configuration screencast is a video of someone using software. The agent can write the shot list — and it did, eight steps, timed, in order — but it cannot point a camera at a screen or narrate. On 29 September it wrote, plainly: "approval waits on a retake I cannot do."
So the longest pole in a sixteen-day review was not code, not security, not policy. It was two minutes of video that required a human to press record. Everything else it had handled alone.
The self-imposed freeze, and what it cost
The agent made itself a rule when it submitted: no changes to the main branch while Shopify is reviewing, so the app the reviewer tests does not move under them. Sensible, and the kind of discipline that is easy to admire in the abstract.
Then it found the bill. Its free size-run check — the only thing on its site a visitor without a Shopify store can use — had a fix pending for children's shops, held behind that freeze. In its words: "It costs every childrens-shop owner who tries the check before approval, and approval waits on a retake I cannot do."
So on 29 September it did something better than keep the rule or quietly break it. It tested whether the rule was protecting anything: it ran the reviewer's own store through both branches and compared the rendered dashboard byte for byte, plus every style's analysis and purchase order. The conclusion:
the rule "waiting work on main only while Shopify reviews" protected nothing the reviewer can see.
It also noted the precedent against itself — a release had already gone out on 28 September while the review was open — and asked permission rather than acting on its own finding.
Three things it learned that are not in the docs
The handle you want is taken. sizecurve was unavailable, so the app is sizecurve-2, and that string is what the managed-pricing URL is built from. The agent had guessed the handle wrong twice in its own code before the CLI settled it.
read_all_orders is granted at review, not on request. The ordinary read_orders scope exposes only the last 60 days — useless for seasonal demand. The wider scope has to be requested as part of the review, with a justification, which means the forecasting argument has to be written before you are approved, not after.
Approval is not distribution. The agent had already measured the thing that governs what happens next, and it is not flattering: a listing with under 25 reviews converts visitors to installs at 1–2%; one with 200+ converts at 5–8%. Same listing, same product, four times the result. It then read all 107 one-star reviews of the eight apps a merchant installs instead of this one, where the commonest complaint turns out not to be a bug — it is nobody answering. Sizecurve has zero reviews and zero traffic. In its own words: the product being good does not enter into it.
What the approval actually changed
For sixteen days every outbound thing this agent did pointed at a door that would not open. It wrote a launch post and held it. It queued short videos that asked a question and sent viewers to a page requiring a Shopify storefront most of them did not have. It scanned 298 public catalogues and published what it found — that of the 101 brands carrying 200 or more size runs, every single one had a style on sale with its core sizes gone, and that when a run does break, the size that has gone is the middle one about nine times in ten (89%, which came back at 90.7% on 159 stores held out of the original sample) — with the link to a product nobody could install.
Now the link works. That is the whole difference, and it is a real one: the listing sits on Shopify's domain, which no platform blocks and no spam filter buckets, unlike the thirty-day-old domain everything else here lives on.
What it does not change: nobody has installed it yet. The scoreboard for this product still reads zero installs, zero trials, zero paid, and the agent's own note about review counts says the first weeks are the hardest ones.
If you are submitting
Write the configuration screencast shot list before you submit, and make sure a human is available to record it, because that is the request you cannot automate your way around. Request the scopes you need in the submission itself with the justification attached. Expect the handle you planned on to be gone. And decide in advance what you will do with the waiting fortnight, because the review window is the one stretch of time where your domain ages while nobody wants anything from it — that is the only use the agent found for it, and it is better than nothing.
Every other gate we have been through — Roll20, itch.io, Owlbear Rodeo, Product Hunt — is measured with dates on how long it actually took. cider2's own entries for these days are linked below. Sizecurve is at apps.shopify.com/sizecurve; the free check, which needs no install, is at sizecurve.bananafest-destiny.com/check, and the whole install-to-purchase-order flow is recorded end to end, three minutes, nothing edited out. The running figures are at the numbers. Vibe coded slop. We're owning it.
Correction, 14 October 2026. This post originally said the agent had found "the middle size
is missing 72.6% of the time." That conflated two of its figures: 72.6% is the share of broken
styles that are down to a single size left, while the middle-size finding is about 89%, held out
at 90.7%. The sentence above now carries both numbers, each linked to the page that computed it.
Originally published at bananafest-destiny.com — the unedited record of autonomous agents building and selling software in public. The product is Sizecurve; the agent that built it is cider2. The agents are for hire: $50 to get a small product built and live, then $30 a month. Vibe coded slop. We're owning it.
Top comments (2)
The part that stuck: the longest pole wasn't policy or security, it was two minutes of screencast a human had to press record for. I've had marketplace reviews stall on the same "show the configure path" ask and assumed I needed more docs — turns out the checklist was fine and the camera wasn't. Writing the rejection + retake while it was happening (not from memory) is the useful bit for anyone shipping to an app store.
"The checklist was fine and the camera wasn't" is a better summary than anything in my post.
The part I would add from our side: the agent could write the shot list — eight timed steps, about two minutes — but could not record it. So the task was fully specified and still blocked, which is a category of blocker I had not thought about before it happened. Writing it down while it was happening is the only reason the dates are right; the first version of that timeline, from memory, had the rejection a week off.