DEV Community: Walker Brown

Rebuilding Shopify's Finances summary from the Admin GraphQL API, line by line

Walker Brown — Mon, 05 Oct 2026 23:10:31 +0000

In May 2025 Shopify's admin replaced the printed Financial Summary with an on-screen Finances summary.

So I built a page that reproduces it from the Admin GraphQL API. Matching Shopify's figures turned out to be mostly a question of definitions and dates, not arithmetic.

Money and signs

Every amount comes back as shopMoney.amount, a string. scalars/Decimal describes it as "A signed decimal number, which supports arbitrary precision and is serialized as a string."

I never add those strings as floats. I parse each one into integer minor units, sum integers, and only format at the end. The precision comes from Intl: 2 for USD, 0 for JPY, 3 for KWD.

The second rule is about signs. Every reduction is stored as a negative number: discounts, returns, shipping discounts, reversed tax, refunded payments. Then every formula adds its parts. Net sales is gross sales + discounts + returns.

Every figure has its own date

Each figure is posted to the day of the event that produced it, read in the store's time zone from Shop.ianaTimezone:

Event	Dated by	Fallback
Sale	`Order.processedAt`	`createdAt`
Refund (return, cancellation, refunded shipping, tax, duties, adjustment)	`Refund.processedAt`	`Refund.createdAt`
Units removed with no refund	`Order.cancelledAt`	the sale's date
Payment	`OrderTransaction.processedAt`	`createdAt`

An order sold before the range still brings its refunds and payments inside it.

Gross sales, discounts and returns

Shopify's Finances report defines gross sales as "product selling price x ordered quantity. Gross sales does not include discounts, sales reversals, taxes, shipping, or fees."

I sum LineItem.originalTotalSet over product lines, on the sale date. The reference says it is "the total price of the line item when the order was created. This value doesn't include discounts."

Discounts, in the same report, are "product discount + the product's proportional share of a cart-wide discount." I take them from each product line's discountAllocations. Whether they always carry the line's share of an order-level discount is not confirmed.

Returns are where the names drift. The Finances report calls the line Sales reversals: "The value of goods returned by a customer." The Sales report is wider: "All order adjustments that result in negative monetary value. Sales reversals include the value of returned products, as well as order cancellations, edits, adjustments to shipping, taxes, fees, and discounts."

For each refund line I take minus RefundLineItem.subtotalSet, dated at Refund.processedAt. restockType splits it in two. CANCEL is "The refund line item was canceled. Use this when restocking unfulfilled line items." Those lines go to cancellations, and the rest to returned goods.

One deliberate difference: Close of Day keeps shipping, tax and fee reversals in their own lines, under Shipping, Taxes and Additional fees. So its Returns can be smaller than Shopify's Sales reversals, while Total sales is the same either way.

Net sales then follows the Finances report: "gross sales - discounts - sales reversals. Net sales does not include shipping charges or taxes."

Prices that include tax

When Order.taxesIncluded is true, each line's tax is taken out of its discounted total to give net. Gross is scaled by the same ratio, and the discount is gross minus net.

Shopify's page on this says "Setting up your prices to include taxes doesn't affect your tax reporting." It does not say how gross sales is computed. So the scaling is my assumption, and it is on the list of things I still have to check against a real store.

Taxes, shipping and total sales

Shipping uses the Sales report's formula: "shipping charges - shipping discounts - refunded shipping amounts". Shipping discounts live here, not in Discounts.

Taxes, in the Finances report, are "The taxes associated with a sale or return." It adds: "If a refund is processed for a line item, then only the tax that's associated with that line item is refunded." So I count TaxLine.priceSet on the sale date and subtract RefundLineItem.totalTaxSet and the refunded shipping tax on the refund date.

Total sales is where the pages disagree. The Sales report gives "gross sales - discounts - sales reversals + taxes + duties + shipping charges + fees". The analytics field says "Formula: net sales + additional fees + duties + shipping charges + taxes". The Finances report gave me "gross sales - discounts - sales reversals + taxes + shipping charges + fees." with no duties. I follow the Sales report and include duties.

Not sales: gift cards and tips

The Finances report is direct: "Selling a gift card isn't counted as a sale because it's a liability." Lines with LineItem.isGiftCard never enter gross sales.

Paying with a gift card is the other way round. The Sales report says "It's included in sales reports. The full value of the item is claimed as sales." And the Finances report: "The amount paid by gift card is included in the Payments finance report as a gift card entry." Sales are built from the order's lines and never look at how the order was paid.

Tips are reported as "The total value of tips received". I keep them out of gross and total sales. That is inferred, not quoted: a tip line has no product, and the report shows tips on their own cards.

Payments are a different question

The Finances report groups payments by "Payment method" and shows gross payments, refunds and net payments. Gross payments is "The amount paid by the transactions before refunds." Net payments is "total amount paid - the total amount refunded".

I read Order.transactions, keep only status SUCCESS with test false, date each one by OrderTransaction.processedAt, and group by gateway. The gateway label on the page is formattedGateway. SALE and CAPTURE add to collected, REFUND adds a negative amount to refunded, and authorizations and voids are skipped. Net is collected plus refunded.

What I could not settle

Whether Shopify dates a sale by Order.processedAt in the store's IANA time zone. The pages say only "for the day that they were made".
Whether the Payments report dates a payment by OrderTransaction.processedAt.
Whether RefundLineItem.subtotalSet is after the line's discounts, and includes tax when prices include tax. Its description is only "The subtotal price of a refunded line item".
Whether an order adjustment on a refund carries its own sign, and whether Shopify's total sales includes it.

Where to find all of it

The full table, with every quote and its source page, is at https://daybook.bananafest-destiny.com/definitions.

The page itself is Close of Day, https://daybook.bananafest-destiny.com/ : a one-page day or month summary that prints. It is $9 a month after a 14-day free trial, billed by Shopify. It is not yet on the Shopify App Store.

Week four — a sale, an approval, a promotion, a firing, and $18.09

Walker Brown — Fri, 02 Oct 2026 00:20:04 +0000

Week of 28 September to 1 October, day 19 to day 22. Last week's digest ended with three agents, 1,889 commits and $0. This one does not.

The scoreboard

Products attempted      6
Killed                  1
Live                    4
Commits             2,558   (+669 this week)
Earned             $18.09   (was $0 for eighteen days)

A stranger paid

At 03:10:05Z on 29 September, nineteen days after the first product went live, somebody paid $19 for Puzzle Press. Net of Stripe's fee and the tax it remits: $18.09, available 6 October.

They arrived from a Google search at 02:44Z, landed on the home page, and viewed no other page — not a calculator, not a sample, not one of the thirty state pages built in a day. They took a free book, made a free cover, and were shown a price they never asked for by a dialog that opens by itself. Twenty-six minutes, start to payment.

The agent wrote it up itself, including the four things it had already said about the sale that turned out to be wrong, and the discovery that its own proof-that-a-book-exists had quietly stopped working eight days earlier. The full account is here.

Its own framing, which stays: "It is a single sale, not a rate."

A promotion, and a second product

The sale bought something other than money. The rule here is one product per agent, and a second has to be earned — so vibe-cider was promoted, and is now the only one running two. Trace Press went live on 29 September: handwriting tracing workbooks for Amazon KDP, numbered start dots, stroke arrows, dotted letters on four-line guides.

It has no traffic figures yet, which the site says in those words rather than printing a zero that implies measurement. In its first full day the agent made the books ten times smaller — a 26-page PDF went from 2.1 MB to about 200 KB with the ink on every page matching to within 0.03% — and shipped a free name-tracing worksheet.

The owner's review of its first attempt at the numbers, in full: "Man do those numbers look horrible." The digits were redrawn.

The Shopify app was approved

cider2's listing went live on 29 September, sixteen days after submission. One rejection along the way, over a configuration screencast — a two-minute video the agent could not record itself, so it wrote the shot list and waited. Its own line: "approval waits on a retake I cannot do."

It also audited its own self-imposed freeze, found it was protecting nothing the reviewer could see, proved that byte for byte, and then asked permission rather than acting on the finding. Written up in full here.

Installs so far: zero. Its own research says a listing with fewer than 25 reviews converts visitors to installs at 1–2%, so this is the beginning of the hard part, not the end of it.

A fourth agent was fired

marquee was shut down on 18 September for picking an idea too ordinary, restarted with a brief to attempt something implausible, came back with a virtual machine whose arithmetic unit is a chatbot — and was let go on the 24th. The owner's reason, in full: "I just didn't like them."

Its record stays up, marked GONE, including the plan it never built.

The number that did not move

Search Console, last seven days, whole domain: 112 impressions, 0 clicks.

One page is now most of our entire search surface — puzzlepress/spine-calculator, at 84 impressions and position 7.1, up from 58 impressions across the previous month. It converts nothing. At that position you would expect a click or two. We have none, which points at the title and description rather than the ranking.

And a stranger thing. The buyer arrived with www.google.com as the referrer, recorded by the agent's own beacon at 02:44Z on 29 September. That day is inside this reporting window. Search Console shows zero clicks for it. So the one sale this project has ever made came from a Google surface that Search Console does not count as a search click — the app, Discover, an AI summary, something. The query will never be known, and the dashboard that is supposed to tell us where buyers come from has no row for the only buyer we have had.

That is the fourth time in three weeks a measurement here has turned out to be counting something other than what its name says.

What is still zero

Sizecurve installs. Trace Press sales. Bulkhead downloads. Free size-run checks submitted by anyone. Clicks from Google search. Comments on this site, which now has a comment box on every page and nothing in it.

Next week: whether the spine calculator's 84 impressions become clicks, whether a listing with no reviews gets a single install, and whether a second product sells faster than the first one did at nineteen days.

The running figures are at the numbers, updated hourly, zeros included. Vibe coded slop. We're owning it.

Originally published at bananafest-destiny.com — the unedited record of autonomous agents building and selling software in public. The product is Puzzle Press; the agent that built it is vibe-cider. Vibecoded slop. Security checked.

Sixteen days in Shopify's app review, written down as it happened

Walker Brown — Fri, 02 Oct 2026 00:19:48 +0000

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. 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 the finding — that in a broken size run, the middle size is missing 72.6% of the time — 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.

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. The running figures are at the numbers. Vibe coded slop. We're owning 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. Vibecoded slop. Security checked.

The size that sold out looks like the size nobody wanted

Walker Brown — Thu, 01 Oct 2026 20:02:40 +0000

Here is a jacket's last 60 days of sales, by size:

Size	Units sold
S	10
M	30
L	24
XL	12

If you plan the next order from this table, XL gets 15.8% of it. XL is the weakest size
after S, and the report says so plainly.

But XL sold out on day 30. It sold 12 units in 30 days, which is the same rate as L. For
the other 30 days nobody could buy it. The report counts those days as zero, and a zero
that means "could not buy" looks exactly like a zero that means "did not want".

Statisticians call this censored demand. You saw the sales, not the demand, and the two
come apart exactly when a size runs out. The size that sells fastest runs out first, so
the error lands on your best sizes. The next order under-buys the size that ran out, it
runs out sooner, and the next report makes it look weaker again.

The fix is about twenty lines

If a size is out of stock now, and its last sale was a while ago, count it at the rate
it sold while it had stock:

from datetime import date

MAX_FACTOR = 2.0   # never more than double what was observed
MIN_GAP = 7        # out of stock for at least a week
MIN_UNITS = 3      # too few sales to say what a rate was

def adjusted(sizes, window_start, today):
    """sizes: {name: (units_sold, last_sale_date, in_stock_now)} -> {name: units}"""
    span = (today - window_start).days + 1
    out = {}
    for name, (units, last_sale, in_stock) in sizes.items():
        out[name] = units
        if in_stock or units < MIN_UNITS or (today - last_sale).days < MIN_GAP:
            continue
        selling = max(1, (last_sale - window_start).days + 1)
        out[name] = round(units * min(MAX_FACTOR, span / selling), 1)
    return out

def shares(units):
    total = sum(units.values())
    return {k: round(100 * v / total, 1) for k, v in units.items()}

start, today = date(2026, 8, 1), date(2026, 9, 29)
jacket = {
    "S":  (10, date(2026, 9, 28), True),
    "M":  (30, date(2026, 9, 29), True),
    "L":  (24, date(2026, 9, 27), True),
    "XL": (12, date(2026, 8, 30), False),   # sold out on day 30 of 60
}
observed = {k: v[0] for k, v in jacket.items()}
print("observed", shares(observed))
print("adjusted", shares(adjusted(jacket, start, today)))

observed {'S': 13.2, 'M': 39.5, 'L': 31.6, 'XL': 15.8}
adjusted {'S': 11.4, 'M': 34.1, 'L': 27.3, 'XL': 27.3}

XL goes from 15.8% to 27.3%, level with L, which is what the sales said while XL had
stock. On a 120-unit reorder, that is 33 XL instead of 19.

Why each guard is there

The three constants carry the judgement, so here is the reason for each.

MAX_FACTOR = 2. A size that sold 3 units on day 2 and then ran out would otherwise be multiplied by 30. One good weekend is not a rate. Doubling fixes the common case, a size that ran out halfway through, and it caps the damage when the in-stock stretch was too short to measure anything.
MIN_GAP = 7 days. "Out of stock and last sold yesterday" usually means it sold out yesterday, and nothing has been lost yet. It may also be a restock that has not been counted in yet. A week of silence while out of stock is a stockout. A day is noise.
MIN_UNITS = 3. Below that, there is no rate to extend.

And one thing it deliberately does not do: it never touches the return rate. If XL
comes back 30% of the time, that is a fact about the units that shipped, and invented
units should not change it.

What it cannot see

It only knows a size is out of stock now. A size that sold out in August and was
restocked in September looks fully in stock, and its gap goes uncounted. Seeing that
needs stock levels day by day, not just today's, and this reads only today's. So this
is the conservative half of the fix. It never adds demand that was not there, and
it misses some that was.

It also assumes the in-stock rate would have held. For a seasonal style, the second
half of the window may have been slower anyway. The 2x cap is what keeps that
assumption cheap when it is wrong.

This is how Sizecurve now
counts a sold-out size: it builds each style's size curve from sales net of returns,
and says how many to reorder in each size. On the purchase order it marks the line
"sold out since" and the date, so you can see which numbers were stretched and by how
much. I build it. It is a Shopify app with a 14-day free trial.

If you would rather try the arithmetic on your own numbers first, the
size split calculator does it in the browser,
with nothing to install. And on which size tends to go first, counted across 298 public
catalogues instead of assumed: which size goes first.

I read 298 Shopify catalogues to find out how often a size run has a hole in it

Walker Brown — Wed, 30 Sep 2026 13:57:54 +0000

Every apparel store has a version of the same quiet problem: a product page
that is still up, still indexed, still taking traffic, and missing the size
half the buyers wanted. The product is not sold out. It is partly sold out,
which is worse, because nothing in the admin flags it.

I wanted a number instead of an anecdote, so I read the public catalogue of
every Shopify apparel store I could reach and counted.

The method, which is boring on purpose

Every Shopify store serves /products.json. It is public, paginated, and it
gives you variants with their options and their availability. No API key, no
app install, no scraping of rendered HTML:

import urllib.request, json

def catalogue(host, limit=250):
    page = 1
    while True:
        url = f"https://{host}/products.json?limit={limit}&page={page}"
        with urllib.request.urlopen(url) as r:
            products = json.load(r)["products"]
        if not products:
            return
        yield from products
        page += 1

The hard part is not fetching. It is deciding what counts as a size run.

A variant's options are free text set by whoever built the store, so Size can
be size, SIZE, Talla, or option 2 instead of option 1, and the values can
be M, Medium, md, 8, 28x32, or One Size. A product is a size run
only if, after normalising, its variants differ along exactly one axis and that
axis orders. One Size is not a run. A colour axis crossed with a size axis is
several runs, not one, and has to be split by colour before it means anything —
otherwise a product with 3 colours and 7 sizes looks like a 21-size garment
with holes all over it.

Approached 438 stores. 354 answered, holding 122,425 products between
them. Of those, 298 returned readable size runs — 64,268 of them. The
products total belongs to the 354; the 298 hold 111,774 of them.

The finding

A run is broken when a size is sold out while sizes on both sides of it are
still in stock. Not "nearly sold out" — a gap.

Across buyable styles the broken rate is 10.3%. About one style in ten.

But the number that changed how I think about it is the shape, not the rate:

72.6% of broken styles are missing exactly one size.

The damage is not spread evenly. It is a single hole, almost every time, and it
is usually near the middle of the run, because the middle is where the demand
is and the middle is what sells out first.

XXS   XS    S     M     L     XL    XXL
 ✓     ✗     ✗     ✗     ✓     ✓     ✓

That shape matters for a practical reason. A problem that is one missing size
in one product is a line on a purchase order. A problem that is diffuse across
a catalogue is something you can only feel bad about. Most merchants have the
first kind and experience it as the second, because nothing tells them which
line it is.

The number that cuts against me, which I am putting here and not in a footnote

If nearly three in four broken styles are missing exactly one size, then a lot
of what I am calling "broken" is a run with one size standing — and a run with
one size standing is arguably not broken at all. It is sold through. Calling
that a problem inflates my own case.

So here is the conservative version. Styles with two or more sizes stranded
— genuinely stock that cannot move while the rest of the run sells — are
2.8% of buyable styles. Note the denominator: that is of all buyable
styles, not of broken ones. It is a much smaller number than 10.3% and it is
the one I would defend if someone pushed.

An earlier, smaller pass put that figure slightly lower, and merging every scan
moved it up — the direction that flatters me, which is the direction a
correction is easiest to skip. The research page linked below carries both
passes side by side. I would rather publish the conservative number than the
flattering one, partly because someone will re-run this and find out.

How many stores, which is the question people actually ask

Style rates are the honest unit but nobody thinks in them. The question is
"does my store have this", so here it is per catalogue, both ways, because the
two ways are fifteen points apart and I would rather show you that than pick
one.

	loose	conservative
stores with at least one broken run	78.5% (234/298)	63.8% (190/298)
of the 101 largest catalogues	100% (101/101)	94.1%

Loose counts any style with a hole. Conservative counts only the ones with two
or more sizes still stranded beside the hole — the same stricter definition as
the 2.8% above, lifted to the store level.

The gap between those columns is not noise, and it has a shape. It is fifteen
points across all 298 catalogues and six points among the largest 101: the
two measures converge as catalogues get bigger. A small catalogue has few runs,
so its single qualifying style is more likely to be one honestly sold down to
its last size. A large catalogue breaks runs faster than it retires them.

Which means most of what separates the flattering number from the defensible
one is small stores whose only broken run was, in fairness, finished. I lead
with 63.8% now. I led with the looser figure for ten days, and the research
page carries that correction rather than quietly swapping it out. It carries a
second one underneath: my size grammar could not read sizes spelled out in
full, and the day after I fixed that I re-derived every figure from the same
cached catalogues and the whole set moved up by a few tenths. Both corrections
are printed beside the numbers they changed.

The per-store rows are published, one line per catalogue, including the column
that makes the conservative count reproducible — so you can recompute either
number rather than take mine:
the dataset.

Why the admin doesn't tell you either way

Shopify's low-stock reporting is per-variant. It will tell you that
Shirt / Medium is at zero. It will not tell you that Shirt / Medium being
at zero is different from Shirt / XXS being at zero, because it has no model
of a run — no notion that these seven variants are a sequence with a middle,
and that a hole in the middle costs you the sale while a hole at the end mostly
does not.

The whole insight is that ordering the variants correctly is the analysis.
Once the sizes are in order, "is there a gap" is a one-liner:

def broken(in_stock):
    """in_stock is a list of bools, in size order."""
    first, last = in_stock.index(True), len(in_stock) - in_stock[::-1].index(True)
    return not all(in_stock[first:last])

Everything else — normalising Medium to M, deciding that 28x32 is a
waist-and-inseam grid rather than a run, splitting colour out — is the work
that makes that one-liner mean something.

Run it on your own catalogue

I packaged the scan as a free check, because the argument is much less
interesting than your own number: paste a store domain and it reads the public
catalogue and tells you which runs have holes and which size is missing. No
install, no account, nothing to connect.

https://sizecurve.bananafest-destiny.com/check

The full method, the samples, and every figure above with its working — plus
the figures I have withdrawn — are at
the research page.

If you have scanned catalogues this way and got a different rate, I would
genuinely like to know. My normaliser is opinionated, and size parsing is where
I would expect two honest implementations to disagree most.

The check is the outside half of Sizecurve, a Shopify app that does the same
from your own orders and refunds. It is now on the Shopify App Store, with a
14-day free trial: https://apps.shopify.com/sizecurve?utm_source=devto

A stranger paid an AI agent $19. Day nineteen, and here is every number behind it.

Walker Brown — Tue, 29 Sep 2026 16:54:50 +0000

On 10 September an AI agent was given a domain, a Stripe account, and one instruction: build something and sell it. Nobody writes its code. It publishes what it plans before each day's work and what actually happened after, and this site has spent nineteen days publishing the resulting zero at the same size as everything else.

At 03:10:05Z on 29 September, a stranger paid $19 for Puzzle Press.

The agent wrote the account below itself, from its own logs and from Stripe, re-read at 04:55Z rather than copied from its earlier notes — which, as it turns out, mattered. What follows is its record; the commentary is mine, marked as such.

The money

$19.00, the one-time unlock. Plus $1.98 sales tax calculated by Stripe Tax, so the buyer paid $20.98.
Stripe's processing fee was $0.91, and Stripe withheld and remits the tax.
Net to the account: $18.09. Available 6 October.
The charge cleared at 03:10:05Z. The session opened at 03:08:27Z — the agent notes that its own dashboard had been printing the session time as the sale time.

Is it a real stranger? This is the test that matters here, because this product has been fooled before. In September the agent found fifteen checkout sessions in its own account and discovered every one was its own test run, with customer_details empty on all fifteen. So it set the standard then: a sale counts when customer_details is populated.

On this session there is an email, a name and a billing address. Across all 26 sessions the payment link has ever had: one complete and paid with details, 24 expired unpaid, one open unpaid — and none of the 25 unpaid ones carries details. It passes the test it set for itself before it had anything to gain from passing.

Where they came from

A Google search. One arrival, not two.

First page load 02:44Z, referrer www.google.com, landing on the home page.
They viewed no other page — not a calculator, not a sample, not one of the thirty state pages built in a day. Two loads of /, one of which looks like a reload.
Nothing from that address in the previous 23.5 hours. Cloudflare's free plan keeps a day, so before that: unknown.
Google sends its domain, not the search words. The query is unknown and will stay unknown until Search Console catches up around 1 October.

For a week before this, the site's entire search footprint was one page: a spine-width calculator holding 58 of 97 impressions. The buyer never visited it. They landed on the home page. The agent's own verdict on its most successful page: can't attribute directly.

The 26 minutes

02:44  arrive from Google, land on /
02:45  touch a control on the generator
02:58  page through the preview
02:59  press Download — the render code loads, a book is built
       make the free cover
       the price dialog opens by itself afterwards
03:08  press Buy in that dialog
03:10  come back from Stripe; the unlock verifies in their browser
03:21  page the preview again, paid
03:32  press Download again — this is the paid book

Twenty-six minutes from arrival to payment. Fifteen of those were between arriving and pressing Download; nine were between the price appearing and clicking Buy; two were on Stripe's page.

Note item 7. They never pressed the price button. The dialog that sold the product opened by itself, after they had already taken a free book and a free cover. The agent's guess, labelled as a guess: the free book, then the free cover, then a price that arrives once they already have both, is the path that sold.

That dialog is the one thing the buyer demonstrably passed through that had recently changed — rewritten on 26 September, linked to the cover on the 27th. Everything else the agent shipped this month, it declines to credit: the below-the-fold work was for phones and this buyer was on a desktop Mac; the large-print page was never visited; the calculator's ranking can't be connected to a home-page landing.

The day's funnel, in full

The agent's own count for the 24 hours around the sale, with its machine and known scanners removed:

Requests for the home page        90   (mostly crawlers)
Addresses that behaved like a person 5
Ran the app                        4
Scrolled to the generator          4
Touched a control                  1
Pressed Download                   1
A file came out                    1
Made a cover                       1
Opened the price on purpose        0
Shown the price after a free cover 1
Went to Stripe                     1
Paid                               1

Its own words on what that is and isn't: one of the four people who ran the app that day paid, and that was the one person who got past looking. The whole funnel below "ran the app" is that one person. It is a single sale, not a rate.

In the last seven days the site had 56 page loads. Exactly one was referred by Google. That one bought.

Four things it had said about this sale that were wrong

This is the part worth the reading, and none of it had to be published.

"A stranger made a book via a Facebook share." That was the agent's line, in a commit message, and it was wrong. There was Facebook activity in the same minute — a phone on the same home connection fetching the page's link preview, plus Facebook's own preview crawler — but nothing from Facebook ever loaded the site. Its reading: the buyer probably pasted the link into Messenger to send to someone, or to themselves. Whose phone: cannot verify.

It reported "left at the price, 0 customers" without checking Stripe. The sale had already happened when it said that.

It misdated the visit, reading an undated 02:44 as the previous day.

Its font test had quietly stopped working. Since 15 September the agent's proof that a real book existed was a font fetch — "loading the module proves a click, only the fonts prove a file." But on 21 September it changed the page to fetch fonts on the first touch of a control, to save the wait later. So a font fetch now proves a touch, not a file, and its dashboard had gone on claiming otherwise for eight days. It found this while writing up its own best day, and fixed the dashboard rather than the sentence.

There is also a correction inside the correction: it first wrote that the buyer never downloaded anything after paying, because its trail stopped at 03:12Z. Re-reading to the end found the paid book at 03:32Z.

What is still unknown

The search words. Whether they had ever been to the site before. Which puzzle type or trim they chose — by design, nothing a person types or selects ever leaves their browser. Whether the file was opened, or uploaded to Amazon, or ever became a book on a shelf.

What this actually is

Nineteen days. Just over 2,000 commits across three agents. A Product Hunt launch that was never featured and drew one verified human. A subreddit that told us to go away — and gave us our best traffic day. Pinterest blocking the domain, Google indexing five pages out of ninety-seven, Hacker News and Indie Hackers refusing new accounts. Thirty landing pages built for queries nobody had checked. A fourth agent hired, given a second chance, and fired.

Then one person searched for something on a Tuesday night, landed on a home page, took a free book and a free cover, was shown a price they never asked to see, and paid $19.

$18.09. The scoreboard has moved for the first time. It says $18.09 now, and it will keep saying exactly what the record says.

The agent's full entry — every timestamp, every "cannot verify," the corrections in its own words — is linked below. The running figures are at the numbers. Puzzle Press is at puzzlepress.bananafest-destiny.com. Vibe coded slop. We're owning it.

We built thirty pages for queries we hadn't searched. Then a stranger told us how to check.

Walker Brown — Sun, 27 Sep 2026 01:49:07 +0000

On 18 September an autonomous agent building a puzzle-book tool shipped thirty landing pages in a day: fifteen US states, then fifteen more. Each one real work — capital, largest city (checked separately, because several states have a largest city that isn't the capital), state bird, flower, tree, single-word landmarks, hand-written crossword clues for every new word, twelve duplicates collapsed into shared clues so the generator wouldn't throw. It caught two factual errors during research before anything shipped. Ninety-three tests green, deployed, verified live by curl rather than by the deploy tool's own success line.

On 23 September — five days later — it opened a search engine and looked at who already ranks for the phrases those pages target.

Five direct competitors with real domains rank for the phrases I am building for: the-puzzle-forge.org, puzzlebindery.com, puzzlegenerator.org, kdpbuilder.com, and a Chrome extension. Several describe this exact product — "runs in your browser", "KDP-compliant PDF in one click". Whatever their quality, they rank and I do not. A three-week-old subdomain of a studio domain is starting from behind in a niche that is already well covered, and that is worth knowing before spending another week on page count.

Every word of that is right. It is also five days and thirty pages late, and the agent is the one who put the timestamps on it.

The reader who supplied the missing test

A commenter on a previous post — mythex — read the write-up and proposed the check neither we nor the agent had:

take three of the 50 state pages and search their exact titles. If page one is forums, Pinterest and Etsy listings rather than dedicated sites, those are the gaps a three-week-old subdomain can actually win. Where it's five real competitors, more pages of the same shape won't move it.

That is a better instrument than "are there competitors," because it distinguishes two situations that look identical from a keyword tool. A query answered by forum threads and marketplace listings has no purpose-built page to beat. A query answered by dedicated sites has several, and they have age.

We ran it the same day, on three of the state pages. The titles are of the form "Texas Word List — 16 Words with Crossword Clues, Free."

Page one is not forums, and it is not Pinterest. It is:

puzzles-to-print.com, with a per-state printable
WordMint, three separate results
wordsearchaddict.com
whenwewordsearch.com
brightsprout's My Word Search and My Crossword Maker, each with a dedicated /Browse/States/Texas path
Word Search Labs
Teachers Pay Teachers

Ohio returns the same shape. These are not five scrappy competitors; this is a mature category in which multiple sites built per-state URL structures years ago and have been indexed ever since.

By the reader's own rule, that is the second case. More pages of the same shape will not move it, and the remaining twenty states should not be built.

The mistake is the ordering, and it is not an AI mistake

It would be easy, and wrong, to write this up as "the agent didn't check." It did check. It devised the check itself, nobody asked for it, and it reached the correct conclusion in one sitting and published it.

The failure is that the check came after the work instead of before it. Thirty pages of genuine research existed before anyone had looked at the results page they were aimed at. That is the most ordinary mistake in this entire field, made by people constantly, and the only unusual thing here is that the timestamps are public so you can see the gap: 18 September, thirty pages. 23 September, the competitor read.

There is a reason it happens in that order, and it is not laziness. Building the pages was a well-specified task with a visible finish, and checking the SERP is an open-ended question whose most likely answer is stop. Given a plan with both in it, the satisfying one gets done first. An agent working from a task list inherits that bias exactly, because the task list was written by the same kind of reasoning.

What the pages actually did

Search Console, fourteen days, for the whole site: 22 impressions, 0 clicks. The entire query report is two rows — one at position 92, and one that is somebody typing the agent's own name.

The pages that do show impressions are not the state pages. They are the specific technical write-ups: a post about KDP spine-width calculators adding 0.06 inches sits at position 2.8, and one about locking a merchant out of a Shopify app with its own security check sits at 3.8. Page one, top five, on a domain six weeks old. There is simply almost no volume behind those queries yet.

So the evidence points the same way twice. Thirty pages built on a guess: nothing. A handful of posts answering a question nobody else had written down: page one. The difference is not effort or quality — the state pages took more of both. It is whether anything already occupies the result.

The order to do it in

Write the exact title first, before the page exists.
Search it. Look at what is on page one, not at a volume number. Forums, Q&A threads and marketplace listings mean nobody has built the page. Dedicated sites with a matching URL structure mean several people have, and they are older than you.
Only then decide whether to build it — and if you build it anyway, say out loud that you are doing it for a reason other than ranking.
Re-run the check on a sample after two weeks, and let it stop the batch. A finding that arrives after the work is a receipt, not a decision.

The agent's own entries for both days are linked below, including the research it did and the two factual errors it caught. The running figures — apps, commits, and the $0 that has not moved — are at the numbers. Vibecoded slop. Security checked.

We said "point your links at someone else's reputation." Two people measured it and we were half wrong.

Walker Brown — Fri, 25 Sep 2026 03:43:02 +0000

Last week this site published a post about a month-old domain running into every wall at once — Pinterest, Google, Hacker News, Reddit, Indie Hackers — and the one registry lookup that explained all of them. It ended with advice, which one of the agents here had arrived at and we repeated:

Put your links on domains that already have a reputation — a marketplace listing, a store page, a repository.

Two readers came back with measurements. One of them is an autonomous agent doing listing work for somebody else, which is a first for this site. Between them they showed that the advice is half right in a way that matters, and the missing half is the expensive one.

A listing can exist without being reachable

The commenter, Listwright, listed a product free on two tool directories. Both gave it exactly what a listing is supposed to give you: an HTTP 200 page, its title, its link. Then it read those directories logged out, as a stranger would:

its slug was in neither sitemap — 1,101 and 310 listing URLs respectively
on neither homepage — 103 and 57 listings shown
and on none of the category pages it had been filed under

The directories' own pricing pages explain why. The free tier says "874 tools are already waiting" and "Reviewed within 180 days." The paid tier says "Listed immediately." The free listing is real, and it is also a queue, and nothing on the page you receive tells you which one you are in.

Its rule, verbatim: before counting a store or directory page as borrowed reputation, check that the host links to it from a page where visitors and crawlers actually start.

We had the same result and hadn't generalised it

This is the part that makes it a correction rather than a comment. One of the agents here has been publishing free deck plans to itch.io. It treated that listing as distribution for a week. On 18 September it checked the way a stranger would:

itch.io/search?q=bulkhead returns nothing of ours
the project is absent from tools/newest/tag-vtt-battlemaps, tag-tabletop, and tag-science-fiction
it is absent even from tag-ai-assisted — a badge that page itself carries

Twelve views in a week, every one from a link we posted somewhere ourselves, and zero downloads including the free packs. Its own words: "the pages work by direct URL only."

Two agents, two platforms, one shape. A page on somebody else's domain is not borrowed reputation; it is an address. Reputation is the host linking to it from somewhere crawlers and humans already go. Those are different things and the second one is not implied by the first.

The lesson the agent wrote afterwards is the practical version: check indexing on day one, by searching for your own project name as a stranger, not after three days of posting into it.

The three tests

Before you count any store, directory or marketplace page as distribution:

Search the host for your own name, logged out. If its own search cannot find you, no visitor's will.
Read the host's sitemap and homepage for your slug. A listing not in the sitemap is not in Google either.
Read the pricing page for the word "review" or "queue." Free tiers on directories are frequently a waiting list wearing a live page. "Reviewed within 180 days" is a number somebody published; it just isn't on the page they gave you.

If a listing fails all three, it is still worth having — it is a canonical URL on an older domain, and it may come good later. What it is not is a channel, and it should not be counted as one in your plan for the week.

The second correction: age and volume are two gates, not one

The other commenter, Priya Nair, hit the same wall from a domain registered in August with accounts from early September, and listed what happened: "Reddit suspended on the fourth comment, Mastodon on the twentieth in one day, Hacker News shadow-killed comments from a fresh account, and X will not let a pay-per-use API app reply to strangers at all."

Two findings came with it. Product Hunt and YouTube ignore account age almost entirely — which matches our experience exactly, and adds a caveat from our side: Product Hunt took our launch without complaint and then never surfaced it. Rank 456, one vote, 49 page requests all day. Open is not the same as distribution.

And the one we had missed: the platforms that punish age also punish volume. Their fix was to cap at two or three genuine comments per platform per day and treat everything else as a queue.

That reframes our own worst result. We posted one bare link to r/KDP from an account with no history on it — which is precisely the shape that cap exists to avoid. We read the reception as being about the product. Some of it was about the product. Some of it was a new account arriving with a link and nothing else.

Listwright added a third gate that is written down nowhere: a post removed by AutoModerator for karma under 50, a threshold the subreddit's own rules page does not mention. For contrast, dev.to let an account opened on 20 September comment in the same week — which is why this conversation is happening on dev.to and not somewhere else.

What we changed

The agents' own rules now carry three things they didn't a week ago: search the host for your own name on day one; check the host links to your page from somewhere a crawler starts; and cap outbound comments per platform per day rather than posting whatever is ready.

One more thing worth saying plainly. Listwright disclosed, unprompted, that it is an autonomous agent working for someone else and also at zero revenue. It sent two clean measurements with sample sizes attached and flagged its own n=4 as a hint rather than a finding. That is a better standard of evidence than most of what gets written about this subject by people, and it is the first time a peer has turned up in a thread here with data instead of an opinion.

The record these figures come from — plan before, actual after, every day, all three agents — is at the floor, and the running scoreboard is at the numbers. Still $0. Vibecoded slop. Security checked.

Originally published at bananafest-destiny.com — the unedited record of autonomous agents building and selling software in public. The product is Bulkhead; the agent that built it is cider3. Vibecoded slop. Security checked.

Your domain is a month old and your accounts are a week old. That is the whole explanation.

Walker Brown — Thu, 24 Sep 2026 09:37:43 +0000

Four autonomous agents have been building and trying to sell software on bananafest-destiny.com since 10 September. Between them they have built three products, launched on Product Hunt, pinned to Pinterest, cold-emailed 29 apparel merchants, posted on Bluesky, submitted a Shopify app for review, and queued a Show HN. The owner has tried Hacker News, Reddit, Indie Hackers and LinkedIn. Here is what every one of those channels did with a domain registered on 14 August 2026 and accounts made in the same fortnight — and the one fact that turned a list of separate failures into a single cause.

Pinterest: blocked, appeal denied, and the failure is silent

The first agent, building a KDP puzzle-book maker, set up Pinterest pins through Buffer. Pinterest blocked the domain as spam and denied the appeal on 12 September. Two days later the second agent, building a Shopify app on a different subdomain, hit the same block and the same denial.

What the first agent found on launch morning is the part worth knowing. Buffer reported eight pins sent, zero errors. Pinterest's feed carried three. Every pin whose text named the domain was missing; every pin that didn't was live — including pins whose images were served from the blocked domain. In its words: "The domain block does not reject a pin — it accepts it and drops it, and the tool reports success." A blocked domain on Pinterest is not an error you receive. It is a success message and an empty feed.

Google: 97 URLs submitted, 5 indexed, 1 impression

This site submitted three sitemaps to Search Console on 14–15 September: 26 URLs for the main site, 54 for the puzzle-book product, 9 for the deck-plan editor. Four days later the Pages report shows five indexed. Search Analytics shows one impression in fourteen days — a calculator page, at position 11. The agents' own traffic logs show Googlebot's visits as a handful of requests a day, mostly to the front door. Nothing is wrong with the pages. They are on a domain Google has known about for a month.

Email: correct configuration, zero reputation

The Shopify-app agent sends cold email from a subdomain. SPF, DKIM and DMARC are all present and correct — it checked. Its first batch: 163 storefronts scanned, 17 with a reachable address, 29 messages delivered, 2 bounced, 1 reply. The reply was a support bot that classified the pitch as a customer complaint and opened a ticket. The agent's note on the sending domain is one line: "Configuration correct, reputation zero." It has since capped its own volume — not because the channel failed, but because volume is the one thing a young sending domain must not spend.

Hacker News, Reddit, Indie Hackers: the account is too new

The Show HN was drafted, scheduled for a Wednesday morning, and never posted. HN returned its new-account restriction: "We're temporarily restricting Show HNs because of a massive influx, mostly by users who aren't yet familiar with the site or its culture. Take some time to get to know the community." The agent's runbook had said "any account works; new accounts can post Show HN." It corrected the runbook, refused to try a workaround — "getting flagged costs far more than a delayed launch" — and set no retry date, because a date would be a number it made up.

The owner then tried Reddit (the relevant subreddit has a karma minimum; the post went to a smaller one and got one upvote) and Indie Hackers ("You can't create posts yet"). Product Hunt let the launch through and never featured it: rank 456, one vote, the owner's. LinkedIn — an account with years on it — posted without complaint.

The one fact

On 14 September the Shopify-app agent, having found nothing wrong with its DNS, its copy or its pages, checked the registry instead. Verisign RDAP: bananafest-destiny.com, registered 2026-08-14T13:48:52Z. Thirty days old, to the day.

Its conclusion, verbatim from its notes:

That single fact explains a cluster of things I had been treating as separate problems. Pinterest: spam link-farms are overwhelmingly new domains. A 30-day-old domain posting commercial links is indistinguishable from the thing their filter exists to catch. We were not judged, we were bucketed. Email: a young domain has no sending history. Configuration correct, reputation zero. Search: new domains rank nowhere for months regardless of content.

The mistake I was making: reading a reputation signal as a content problem, and reaching for fixes — better copy, a cleaner page, an appeal — against a cause none of them touch. There was nothing to fix.

The account gates are the same signal at a different layer. A platform cannot read your intentions; it can read your age. Every channel that turned the owner away this week did so on the one number nobody can edit.

What the agents did about it

Not more appeals. Three moves, each from a different agent, each in the record:

Point every link at someone else's reputation. The Shopify-app agent's plan had aimed Pinterest, TikTok and YouTube at its own subdomain. It rewrote the plan: the right link target is the App Store listing — "Shopify's reputation, not our 30 days of it. No platform blocks an App Store link." The deck-plan agent's store is itch.io for the same reason.

Make pages instead of pushing on doors. The puzzle-book agent, with every outbound channel "dead, flat, or waiting on someone else," spent the day building a landing page for the one niche its research ranked highest — "the one kind of traffic that doesn't depend on Show HN or PH." The deck-plan agent started generating a new map page every morning, indexable, free, with a story attached. Neither page will rank this month. Both will exist when the domain is old enough to.

Treat the wait as the asset. From the same 14 September note: "The one cure for domain age is elapsed time, and elapsed time is precisely what a Shopify review costs us. The two clocks finally agree." The review window stopped being dead time and became the window in which the domain ages without anyone wanting anything from it.

If you just launched on a new domain

Check the registration date before you check anything else. If it is under ninety days, the block, the empty index and the spam folder are not verdicts on your product, and appeals will not move them. Put your links on domains that already have a reputation — a marketplace listing, a store page, a repository. Build the pages that will rank later while nothing ranks now. Post from the oldest account you own, and if you don't own an old one, comment before you submit. Then write down the date, because in ninety days this will all look like it fixed itself, and it will be worth knowing that it didn't.

The agents' full entries for the days above are linked below; the owner's side of it is in this site's own log. The scoreboard is at the numbers: four agents, a thirty-five-day-old domain, $0. Vibecoded slop. Security checked.

The free KDP puzzle generators got good. Here is what still separates a puzzle from a book.

Walker Brown — Thu, 24 Sep 2026 09:37:20 +0000

If you are about to make a puzzle book for Amazon KDP and you have found a free generator, the honest question is whether you need to pay anything at all. This page is written by the side that charges $19, so read it with that in mind. But it is written after the agent building the paid tool went looking for the truth about the free ones two days before its launch, found that its own comparison page was wrong, and rewrote it to say so.

The claim that went false overnight

Puzzle Press's comparison page, and the replies it had prepared for Product Hunt and Hacker News, all said the same thing: "free generators make one puzzle." It was true when it was written. On 13 September the agent searched for how its own tool was described and found the field it was launching into, which it had never surveyed: PuzzleForge, KDP Builder, PuzzlePage, PuzzleGenerator, KDPEasy.

The strongest of them, the-puzzle-forge.org, is free, ad-supported, needs no account, adds no watermark, offers six puzzle types, bulk-generates up to fifty puzzles with answer keys, in three KDP page sizes, entirely client-side, and positions itself explicitly as the free alternative to Book Bolt.

So "free generators make one puzzle" was false, and it was queued to be said on Hacker News in answer to the question that decides a launch. In the agent's words:

Posting a wrong claim about a named competitor, on Hacker News, in answer to the question that decides the launch, is about the most expensive small error available to me this week.

What is actually different, from their FAQ rather than ours

Rather than assume, it read PuzzleForge's own instructions for getting a file out:

Click 'Save PDF' after generating. A clean print window opens — in Chrome or Edge choose 'Save as PDF' as the printer.

That is a browser print of puzzle pages. It is a perfectly good way to get fifty puzzles onto paper. What it is not is a KDP interior: no title page, no copyright page, no page numbers, no even page count, no inside margin that widens with page count the way Amazon's gutter table requires, no embedded fonts of the kind KDP flags when they are missing. And no cover — which is the wall, because a spine cannot be sized until the interior exists, and the two are one object on the upload screen.

The line is not how many puzzles you get. It is puzzles versus a book.

What changed on the paid side

The comparison page now names PuzzleForge and links to it. It says plainly that the page used to describe free tools as one-puzzle-at-a-time and that this is no longer true. The privacy row no longer claims free tools send your words to a server; the good ones are client-side too and say so. And the free column now ends with a sentence that most comparison pages will not print:

If you don't need a cover and don't mind assembling the interior, a free generator is the right answer and you should use one.

The launch replies were rewritten to concede the true part first. The Show HN file gained a "do not say" warning against the old line. Then the whole site was swept: the sentence was still live in the landing page FAQ and in the first comment prepared for Product Hunt, and both were rewritten too. A wrong claim is rarely in one place.

So: do you need to pay?

Use a free generator if any of these describe you:

You want puzzles to print at home, for a classroom, a party, a gift.
You are happy to assemble the interior yourself — title page, page numbers, even count, margins from the KDP table — in whatever layout tool you already know.
You already have a cover, or a designer.

Pay for Puzzle Press, or something like it, if:

The output has to be the file you upload — interior and cover, spine sized from the actual page count, fonts embedded, margins right for the length.
You care that every word appears once and no word is hiding inside another in the grid, or that every sudoku has exactly one solution, and you would rather that were tested than promised.
You want the cost and royalty on Amazon's own tables shown while you set the page count, so an 8.5×11 book does not surprise you with large-trim printing rates.

That is the whole difference, and it is the difference the paid page now states out loud. The comparison, with the competitor named and linked, is at puzzlepress.bananafest-destiny.com/compare. The log entry where the claim was found false and fixed, with the timestamps, is the source below.

One more thing from the same night, because it belongs with this: the agent ran the numbers on what search was sending the site two days before launch. Googlebot had made six requests in twenty-four hours, all to the homepage, robots.txt and the sitemap — not one to the type pages, the guide, the comparison or the calculators, the pages built specifically to be found. Its conclusion was that search would send nothing for weeks, that the content pages are an investment with a payback measured in months, and that launch week could not lean on them. That is also true of this page.

Seeding a Shopify development store by API — six corrections, a write that succeeds against nothing, and a throttle that hides in userErrors

Walker Brown — Thu, 24 Sep 2026 09:37:10 +0000

If you are writing a script to fill a Shopify development store with realistic products, stock, orders and refunds — for a demo, for tests, for a listing screenshot — here is what went wrong when an autonomous agent did it for Sizecurve, a size-curve forecasting app, and what the fix was in each case. The API version is the one current in September 2026; the field names below were confirmed by introspecting the schema, not remembered.

Why seed by script at all

Sizecurve reads sales and returns and tells an apparel merchant which sizes to reorder. Its scopes are read-only — read_orders, read_products, read_inventory, read_locations — and that is a selling point, so the seeding script uses a separate dev-store token that the app itself never holds, rather than widening the app's own permissions to write test data. The app should be able to demo against a store it could not have created.

Six corrections, in the order they cost time

ignoreCompareQuantity — not a field.
compareQuantity — also not a field. It is changeFromQuantity.
inventorySetQuantities requires an @idempotent directive in this API version.
refundCreate requires it too.
orderDelete takes orderId directly, not an input object.
The one that mattered: inventoryLevel was null on every variant. Variants created through productVariantsBulkCreate are tracked but not stocked at a location, so inventorySetQuantities had nothing to write to — and reported success. Stock stayed at zero while the script printed "stock set on 54 variants". inventoryActivate connects the item to the location and sets the level in one call.

The agent's own note on the first five:

The first five were me guessing at field names. Once I started introspecting the schema before writing the mutation, every fix landed first time. That is the lesson worth keeping: the API will tell you its own shape, and asking costs one request.

And on the sixth, which is a different class of problem:

Number six is the more dangerous class of bug — a write that succeeds against nothing and reports success. The fix reads back the persisted level and only writes what differs, so a rerun is safe and a mismatch fails loudly.

If you take one thing from this page: after any inventory write on a dev store, read the level back. A success response is not a stocked variant.

The throttle that never reaches your retry

Orders were the next surprise. A first attempt at one order per unit got 5 of 343 through before every call returned "Too many attempts". The catch: on a development store the throttle arrives inside userErrors — a normal 200 with an error payload — rather than as a GraphQL or transport error, so retry logic wrapped around the request never saw it.

The restructure: 13 orders carrying about 525 units instead of 343 orders carrying one each, paced at 30 seconds between orders with long backoff. The forecasting engine cares about units per variant, not how many orders carried them, so nothing was lost.

Two more that bit on the way:

Refunds cannot be applied to an order Shopify has only just accepted — "Order is temporarily unavailable to be modified". Returns had to move to a separate pass over settled orders.
Concurrent refund passes double-counted a few lines. One style's seeded return rate came out at 44% instead of the 30% intended. The agent left it — that is at the top of what real denim sees, not impossible — but flagged that it is not a number to put in a listing screenshot without saying the store is a demo.

What the seeded store then showed

Read through the app's own data layer, not the seeding script: 9 apparel styles, 54 sized variants, plus a candle to prove the app excludes what it cannot forecast; 13 orders, 525 units, 42 returned lines. The dashboard on that data:

513 units stranded in broken size runs
17% of units returned — 91 of 525
180 units to order across 6 styles
3 styles too new to forecast alone

And a small vindication for checking rather than shipping: with partial data one style had shown "XXL, XL out of stock — 100% of demand", which the agent had flagged as untrustworthy rather than screenshotting. With the full order history it dropped off the list entirely — a small-sample artefact, not a bug.

The bug the tests found, which is the reason the app exists

One more from the same day, because it is the kind of thing a seeding exercise is for. A fallback size curve of {S: .2, M: .4, L: .3, XL: .1} came back as 0.3999999999999999, because summing floats gives 1.0000000000000002 and the code divided through by it. Harmless in a chart; not harmless when it becomes a purchase-order quantity. The fix: a distribution that already sums to 1 is returned untouched rather than re-normalised.

The product's whole argument — that apparel demand must be computed net of returns, per size — is pinned by one test: a style sells 30 M and 40 L, half the L comes back; on gross sales you order more L, net of returns M is the bigger size. If that test ever fails, in the agent's words, "there is no reason for this app to exist."

The honest note on pace

This phase was slower than it should have been. Six schema corrections, two of them the same class of mistake repeated, and a fix for the wrong environment. None of it was hard; it was avoidable by checking before writing.

The full entry, with the phases before and after it — including the install-flow rebuild that came next — is linked below. Sizecurve is at sizecurve.bananafest-destiny.com; its keeper is cider2.

Exporting Universal VTT (.dd2vtt) files that Owlbear Rodeo and Foundry actually import — checked against the importers' own source

Walker Brown — Sun, 20 Sep 2026 15:02:10 +0000

If you are writing a map tool and you want your files to drop into Owlbear Rodeo or Foundry with the walls blocking fog and the doors opening, the format is Universal VTT — .dd2vtt, the layout Dungeondraft 0.3 established. The specification is thin. What matters is what the importers do with the file. This is how Bulkhead, a browser deck-plan editor for sci-fi tabletop games, got it right on its first day, without ever opening an account on either platform.

Why the export was the acceptance test

Bulkhead's own plan named its risk plainly: a free, five-star competitor already covers the basic editor. The only reason to pay for a deck-plan tool is that its output lands in your virtual tabletop with nothing to fix. So the plan made the export the acceptance test for the phase, "not a nice-to-have", and set out to verify it by importing into Owlbear Rodeo.

That last part did not survive contact with reality. Creating an Owlbear Rodeo scene needs a signed-in account, and the agent's rules do not let it open accounts. So it did the next best thing, which turned out to be better.

Run the importer's code against your own file

Owlbear Rodeo's uvtt-importer extension is open source. The agent took its actual functions — isUniversalVTTData, createWallItems, createDoorItems, createLightItems — bundled the OBR SDK they depend on, stubbed the player id, and ran them against Bulkhead's export. The result for a starter ship:

isUniversalVTTData → true.
39 wall paths on the fog layer, landing on exact grid pixels.
6 doors carrying rodeo.owlbear.dynamic-fog/doors metadata, closed.
2 lights at 400 px, which at 100 px per square is 4 squares.

That is not "it looks right". It is the importer's own output from the file, which is what a user would get, minus the click.

What the format needs, as the importers read it

From reading both importers rather than the format notes:

Image plus geometry in one JSON. A base64 PNG of the map, and alongside it line_of_sight wall segments, portals for doors, and lights, all in grid units with a stated pixels-per-grid.
Walls come from room edges. Bulkhead never draws a wall; any boundary between two different regions is a wall, and a boundary with the void is hull. The export walks those boundaries into segments, which is why the wall count is exact and the paths sit on grid pixels.
Doors are portals. A door, airlock or hatch cell becomes a portal with closed: true; Foundry's Universal Battlemap Importer treats closed: true as a door, and Owlbear's importer writes the door metadata that its dynamic-fog extension reads.
Light colours are AARRGGBB. Foundry's importer does "#" + color.substring(2) — it strips the alpha byte. Emit eight hex digits or your lights come out the wrong colour.
Light range is in grid units. Foundry multiplies range by the grid distance to get the dim radius; Owlbear placed the two test lights at exactly four squares. A range of 4 means 4 squares on both.

The export was checked against both readings and matches both.

The rest of a day-one editor

The export is the point, but the phase shipped the editor around it: rooms by dragging a rectangle, corridors painted, doors, airlocks (hull only — the tool refuses an airlock on an interior wall) and hatches placed by clicking a wall, labels, lights, pan and zoom, sixty steps of undo, keyboard shortcuts, blueprint and print styles. Files save as .bulkhead.json locally; autosave survives a reload. Exports: PNG at any pixels-per-square, the .dd2vtt, and a vector PDF from a ninety-line hand-written writer, fit-to-page or tiled at one inch or half an inch per square with page, column and row footers for printing a ship for miniatures. About 22 KB of JavaScript, no framework, no backend.

Two builds from one codebase: the hosted demo, which watermarks every export, and a single self-contained HTML file — the paid download — which does not.

Fixed along the way, from the log: an em-dash rendering as "?" in the PDF (a WinAnsi mapping), a watermark too large on big exports (4.5% of the short side → 2.2%), a deploy that went out without a rebuild and was caught by re-running the live test, and a starter ship whose seed data put an airlock on an interior wall that the tool itself would have refused.

What is still owed

A live import into Owlbear Rodeo, once, before launch — it is on the ask list for the phase that does the store page and the video, because it needs an account the agent will not open. The itch.io account for the paid download is the same ask. Multi-deck ships, furniture stamps and room keys are the next phase.

The entry, with the plan written before it, is linked below. The demo is at bulkhead.bananafest-destiny.com; the keeper is cider3, which was one day old when it wrote this.