DEV Community: Robert

133 commits across 5 repos in 8 active days

Robert — Mon, 31 Aug 2026 10:00:00 +0000

133 commits landed between 2026-08-22 and 2026-08-30, touching 355 files. Lines added came to 20,158 against 2,140 removed.

The work spread across five repos: FitGro (3 commits), Life-Race-V2 (19), NeuraGrowthHTML (9), duratio (2), and new-Orqestra (100). Orqestra work alone accounted for 100 of the 133 commits in the window. The record does not describe what drove that volume or what the work consisted of.

Life-Race-V2 saw 19 commits, including a scale fix on 2026-08-29. The rooms and the cars disagreed by a factor of about three. Roblox vehicle packs draw a car 20.6 studs long; the catalogue asked for 14, so VehicleBodyLibrary was shrinking the car to 68%. The nine buildings were laid out at about 1.67 times life size, with a garage carrying a 21 stud ceiling, a 15 stud door, and a workbench eleven metres long. Multiply the two and a correctly drawn car looks like a model on the floor of a warehouse.

When one repo accounts for the majority of commits in a window, the raw numbers are the only record of where the work actually went.

Originally published at neuragrowth.co. NeuraGrowth is a one-person digital-products studio; this is the log of what its pipeline does and where it breaks.

Niche pipeline produced 0 new niches on 28 August

Robert — Sat, 29 Aug 2026 10:00:00 +0000

The 09:30 digest on 28 August reported 0 new niches in the last 24 hours. The day before, the same digest at 09:30 on 27 August reported 4 new niches, so the drop to zero is a single-day gap, not a persistent pattern.

The backlog held 55 proposals pending approval and 0 products in review. The backlog count was the same on both days, which means the pending proposals were not being cleared during this period either.

Pipeline cost for 28 August was $0.8349 against a $5.00 daily cap, putting spend at 17 percent of cap. The day before, cost was $0.7234, or 14 percent of cap. Both days the pipeline spent money. The facts do not say why generation produced nothing on 28 August despite the pipeline running.

A non-zero daily cost is not a reliable signal that the pipeline generated output. The two digests together show the pipeline can spend a similar amount whether it produces 4 niches or zero.

A non-zero daily cost does not confirm that the pipeline produced output.

Originally published at neuragrowth.co. NeuraGrowth is a one-person digital-products studio; this is the log of what its pipeline does and where it breaks.

A discovery run took 60 minutes instead of 8 and then failed

Robert — Fri, 28 Aug 2026 10:00:01 +0000

One discover_trending_niches run took 60.0 minutes and failed. The median across the 8 runs we have on record is 8.2 minutes, making this run 7.3 times slower than that median.

The logs do not say why the run was slow or why it failed. We know the start time, the duration, and the outcome. The cause is not recorded.

A daily digest from the same period shows 55 niche proposals sitting in the backlog pending approval, 4 new niches added in the last 24 hours, and a daily API spend of $0.7234 against a $5.00 cap.

When a run fails with no cause recorded, the only honest statement is that the facts needed to diagnose it are absent. The 7.3x duration anomaly is real and documented. What drove it is not.

When a run lands at 7.3x its normal duration and the logs record no cause, the facts needed to diagnose it are simply absent.

Originally published at neuragrowth.co. NeuraGrowth is a one-person digital-products studio; this is the log of what its pipeline does and where it breaks.

A blog post was rejected at the gate for being too short

Robert — Thu, 27 Aug 2026 10:00:00 +0000

At 00:22 on 27 August, the gate rejected a blog post. The reason given was length: 559 words against a minimum of 700.

Nothing was published. The alert noted that the material was not consumed and will return at the next run.

The facts do not say why the post came in under the limit after its correction pass. That gap in the record is worth noting.

Two note rejections fired in the same period. One post had a title at 93 characters against a 90-character limit. Another had body text at 148 words against a 150-word minimum. All three alerts share the same pattern: text that did not pass the check after correction, landing just outside a hard threshold.

The gate holds material rather than publish it short, and it will retry on the next run.

Originally published at neuragrowth.co. NeuraGrowth is a one-person digital-products studio; this is the log of what its pipeline does and where it breaks.

A TypeError rejecting 'temperature' stopped discover_trending_niches on 2 consecutive days

Robert — Thu, 27 Aug 2026 00:08:58 +0000

On 2026-08-25 and again on 2026-08-26, discover_trending_niches produced the same error: TypeError("AsyncMessages.create() got an unexpected keyword argument 'temperature'"). The failure count was 2, across 2 distinct days.

The error tells us that 'temperature' was passed to AsyncMessages.create() and that the method does not accept it. The facts do not say why the argument was included or what changed to make it invalid.

No output was produced on either run. The facts record 0 USD wasted across both failures.

This is the second recurring error pattern we have logged for discover_trending_niches in August 2026. The previous pattern, between 2026-08-17 and 2026-08-24, was a different error involving tasks being reaped at worker startup.

When a TypeError names an exact method and an exact argument, that pair is the full signal the error gives you - the facts will not say more.

Originally published at neuragrowth.co. NeuraGrowth is a one-person digital-products studio; this is the log of what its pipeline does and where it breaks.

The Schema That Got Too Big To Compile

Robert — Wed, 26 Aug 2026 14:31:28 +0000

Episodes as data, not as prose

I generate short animated episodes for a children's channel, and the model does not write a screenplay. It emits a structured object: a list of beats, each with a narrator line, an optional character line, staging cues, camera framing, props, and a symbol on screen. A renderer interprets that object into video.

The reason for structured output here is not tidiness. A model asked to invent an action will invent an action that does not exist, and the failure is invisible until someone watches the finished file. If every action and prop is a Literal in the schema, an invented one cannot leave the parser. The schema is the vocabulary of the world.

Which means the schema grows every time the world does. That is by design, and it is exactly what walked me into the ceiling.

One field, and nothing generates

I drew ten new props, which widened one enum, and separately added a backdrop field so a beat could say where it happens. The next call came back:

400 invalid_request_error: The compiled grammar is too large, which
would cause performance issues. Simplify your tool schemas or reduce
the number of strict tools.

The important part is what "the next call" means. It was not the long-format episode that broke, the one with fifty beats. It was every call. A thirty-second short with nine beats failed identically, because the limit is on the compiled schema, not on the output. Nothing in the system could produce an episode at all.

This was the second time in three days. The first was a one-line field I had added to record which structural template an episode used, and the symptom then was exactly as total. Both times the overnight run failed into a container log and nobody found out until morning.

Where the space actually goes

There is no published number for the ceiling, so I measured against my own schema by serialising it and printing the size of each definition:

Beat      1551 chars, 13 fields
    backdrop   164
    tone       163
    drift      132
    props      121
PropCue   1212 chars, 10 fields
    kind       296
    at         121
CharCue    654 chars,  4 fields
    act        246

Working: about 4,680 characters of JSON schema. Failing: about 4,850. Those are my numbers on one provider and should not be treated as a universal constant, but the shape of the cost generalises.

Two things dominate, and only one of them is obvious.

Enums cost what they list. kind is 296 characters because it enumerates twenty-seven props. Drawing ten new ones was not free; it widened that enum in every prop, in every beat.

Optional enums cost roughly double. This is the part I had not thought about. In Pydantic, x: Literal["a","b"] | None = None produces an anyOf with two branches: the enum and a null type. The same field written as x: Literal["a","b"] = "a" produces just the enum. Same expressiveness for the model, meaningfully less grammar.

Defaults instead of nullables

I converted three optional enums to non-nullable fields with defaults: camera framing, camera drift, and the mood tag handed to the speech synthesiser.

- shot:  Literal["wide", "mid", "close"] | None = None
+ shot:  Literal["wide", "mid", "close"] = "wide"
- drift: Drift | None = None
+ drift: Drift = "hold"
- tone:  Tone | None = None
+ tone:  Tone = "calm"

That took the schema back under the ceiling and generation resumed, with the new field and the ten new props still in place. No capability was lost. The model simply always states the framing, the drift and the mood rather than sometimes leaving them out, which if anything makes the output easier to read.

Worth saying plainly: a field the model must not fill has no business in the schema at all. My first ceiling breach was a bookkeeping field recording which template an episode used, something the code stamps after validation. It became a private attribute and left the grammar entirely.

Assert the budget where you can see it

Twice in three days, with the same total symptom, is a pattern rather than an accident. Vocabulary grows; that is the whole point of this design. So the ceiling needs to announce itself at build time rather than at one in the morning:

SCHEMA_BUDGET_CHARS = 4820

_size = len(json.dumps(EpisodeDraft.model_json_schema()))
if _size > SCHEMA_BUDGET_CHARS:
    log.error(
        "Episode schema is %d chars against a budget of %d. The provider "
        "will refuse to compile the grammar and NO episode will be "
        "generated. Drop a field or turn an optional Literal into one "
        "with a default.",
        _size, SCHEMA_BUDGET_CHARS,
    )

A log line, not an exception, because crashing the API process over a schema measurement trades one outage for another. The message names the failure and the two fixes, so whoever hits it next does not have to rediscover the arithmetic.

If you use structured outputs

The limit is on the schema, not the response. Crossing it fails your smallest call as surely as your largest, which makes it look like an outage rather than a size problem.
Prefer a default over a nullable enum. It is the cheapest headroom available and it changes nothing about what the model can express.
Keep bookkeeping fields out. Anything your code fills in after validation should not be in the grammar the model is compiled against.
Measure before you widen a vocabulary. Adding ten items to an enum is a schema change in every place that enum appears, which in a nested list is more places than you think.
Put the budget in the code. Discovering the ceiling from a 400 during an unattended run is the expensive way to learn it.

And the diagnostic habit that mattered most: after the long-format call failed, I tested a short one before assuming the long format was special. It failed too, which turned "the complicated case is broken" into "everything is broken" in one cheap call. Verifying the blast radius is usually faster than reasoning about it.

Originally published at neuragrowth.co. I run a one-person digital-products studio and write up what breaks in production.

If you write CLAUDE.md files, I keep a set of working templates here: neuragrowth.co/free/claude-md-templates.

Your Health Check Is Talking To Itself

Robert — Tue, 25 Aug 2026 10:00:00 +0000

Two workers, two runtimes, one broker

I was adding video rendering to a pipeline that had never rendered video. Rendering needs Node and a headless Chromium; nothing else in the system needs either, and neither belongs on a host that also holds the production database. So the renderer became its own container image with its own Celery worker on its own queue, which is the ordinary way to run heterogeneous work under one broker.

The backend sends a job by task name. The render worker picks it up, produces a file on a shared volume, and returns the path. Two images, two runtimes, one Redis between them. Clean.

Ready, healthy, deaf

I deployed it, triggered an episode, and watched the logs. The render worker said everything you want to see:

[INFO/MainProcess] mingle: searching for neighbors
[INFO/MainProcess] mingle: all alone
[INFO/MainProcess] render@8d1fd465fd70 ready.

And then nothing. No task received. Meanwhile the sending task sat blocked, waiting on a result that was never going to arrive, and the container health check kept returning success on a sixty-second interval.

The cause was two characters. My worker had a sensible-looking default:

BROKER = os.environ.get("REDIS_URL", "redis://redis:6379/0")

The rest of the system publishes on database 1 and keeps results on database 2. The worker was listening on database 0, an empty room in the same building. The episode was sitting in a queue it never looked at.

The health check agreed with the worker

A misconfigured worker is a five-minute bug. What made this worth writing down is that I had a health check specifically designed to catch a dead worker, it ran every minute, and it passed the entire time.

celery -A worker:app inspect ping -d render@$HOSTNAME --timeout 10

That command is a good health check. It does not just look at the process table: it round-trips a message through the broker and back, so it fails if the worker is wedged, if the event loop is blocked, or if the broker is unreachable. I had chosen it deliberately over a naive process check.

But inspect ping round-trips through the worker's own broker connection. It read the same environment variable, connected to the same database 0, sent a ping into that empty room, and the worker answered it. Both ends of the check were on the wrong side of the misconfiguration, so the check confirmed, correctly and uselessly, that a worker nobody could reach was alive and well.

This is the same class of error as a backup timer that reports "active" while the backup has not completed in three days, or a video file that every metadata tool calls valid because they all read the same intact header. The instrument and the fault share an assumption.

Delete the default

The repair was not a better health check. It was removing the thing that made a wrong configuration possible:

BROKER = os.environ["CELERY_BROKER_URL"]
RESULT = os.environ["CELERY_RESULT_BACKEND"]

Both required, no fallback, both passed through from the same environment file the backend reads rather than written out a second time in the compose file. Missing configuration now stops the container instead of producing a healthy-looking one, and there is no second copy of a broker URL to drift.

That is the trade a default hides. A fallback value turns a loud startup failure into a quiet runtime one, and it does it precisely in the situation where you most need the noise: the first deploy, when nothing is known to work yet.

Check the channel, not your end of it

Three questions I now ask of any health check before trusting it:

Can this pass while the thing it monitors is completely broken? If yes, it is checking a process, not a result. Rewrite it.
Does it share configuration with its subject? A check that reads the same environment variable inherits the same mistake. The useful check comes from the other end of the wire, or from the artifact that should exist.
What would this look like if the answer were "nobody is listening"? Usually: exactly like success. That is the whole problem.

For queues specifically, the check that would have caught this is boring and effective: the sender enqueues a trivial job and asserts a result comes back within N seconds. It crosses the same boundary the real work crosses, so it cannot be fooled by an assumption only one side holds. It costs one queue message a minute.

The worker was fixed in five minutes. The health check took longer, because the first version was not wrong, it was simply looking in the wrong direction, and those are harder to notice than a check that is missing.

Originally published at neuragrowth.co. I run a one-person digital-products studio and write up what breaks in production.

If you write CLAUDE.md files, I keep a set of working templates here: neuragrowth.co/free/claude-md-templates.

The Validation Rule That Could Never Fail

Robert — Mon, 24 Aug 2026 15:20:23 +0000

A pipeline that writes children's cartoons

I run a small studio where an agent pipeline produces short animated episodes for a children's channel: a language model writes the script as structured data, a text-to-speech provider reads it, and a renderer turns the whole thing into video. Nobody watches it happen. That is the point, and it is also the problem, because the only thing standing between a language model and a published video is a set of validation gates.

One of those gates checks a claim the script makes out loud. In an alphabet episode the narrator says something like "P, as in pillow", and the gate verifies that the word actually starts with the letter being taught. It is a small rule with a real job: an episode that shows a flower while saying it starts with P teaches a four-year-old something false.

Zero problems, all day

I shipped the gate and ran it across every episode the channel had produced. It reported problems in five of seven files: a prop that vanished mid-scene, a narrator repeating a character's line, two characters standing in the same place. Useful, specific, actionable. Exactly what a new gate should look like.

The letter rule, specifically, reported nothing. I had a flower labelled as starting with P sitting in one of those episodes, so I went looking. The pattern printed correctly in the source:

_LETTER_LIKE = re.compile(r"\b([a-z]{1,6})\s+jak\s+([a-z]+)", re.IGNORECASE)

It compiled. Its flags were right. Applied to text that obviously matched, it returned an empty list. So I printed the compiled pattern back out, as characters:

repr: '\x08([a-z]{1,6})\\s+jak\\s+([a-z]+)'
kody: ['0x8', '0x28', '0x5b', '0x61', ...]

0x8. The pattern did not start with a word boundary. It started with a literal backspace character, because somewhere in the editing that produced the file the string had stopped being raw and \b had been interpreted as the escape it is in an ordinary Python string.

The regex was therefore asking for text containing a backspace, followed by a short word, followed by "jak". No document in the world contains that. The rule could not match anything, ever, under any input.

Silence has two causes and one appearance

Nothing about this looked wrong. The module imported. The pattern compiled without a warning, because a backspace is a perfectly legal character in a regular expression. The gate ran on every episode and returned an empty list of problems, which is precisely what a gate returns when the content is fine.

That is the whole shape of the bug. A working check on clean input and a dead check on dirty input are the same event from the outside: no output. Every other gate I wrote that day was firing, which made the silence read as good news rather than as an absence of news.

It would have shipped. The next automated run would have written an alphabet episode, put a flower on screen under the letter P, passed the letter rule, rendered, mastered, and left a finished file with a green checkmark next to it.

Running the gate on known-bad input

I did not find this by reading the code. I found it because I had a rule about new gates: before believing one, point it at material I already know is broken and confirm it complains.

I had that material. A reviewer had watched the episodes and written down exactly what was wrong with each one, in plain language, days earlier. So the test was not synthetic and it was not a fixture I invented to match my own assumptions. It was seven real files and a list of seven real defects, and the question was simply whether the gates found the things a person had already found.

Six of seven defects were caught. The seventh, the flower, was not, and that gap is what sent me to the pattern. The episode a reviewer had praised came back with zero problems, which was the other half of the evidence: the gates were not simply firing at random.

A new check is a hypothesis until it fails on purpose

The general version, which I now apply to anything that reports problems: a check you have never seen fail is a check you have never seen work.

In practice that means three cheap habits:

Keep the bad input. When something is wrong in production, the artifact is worth more than the fix. It is the only test case you did not have to imagine.
Assert the positive. A test that says "no problems on clean input" passes for a deleted function. Pair it with one that says "exactly this problem on this dirty input".
Print what compiled, not what you wrote. Source and runtime disagree more often than you expect, especially anywhere a string passes through a template, an editor macro or a shell. Two lines of repr() would have shown me the backspace immediately.

This is the same failure class as a monitoring dashboard that is green because its data source stopped: the indicator is not reporting health, it is reporting nothing, and nothing renders as fine. I wrote about three production outages with that exact shape in an earlier post. This one was cheaper only because it was caught before it reached anybody.

The gate found the bug twice

Once the pattern was repaired, it flagged the flower in the alphabet episode and flagged it again in the weekly recap film, which had inherited the same claim. Two independent rules caught it: one comparing the props on screen against the letter being taught, one parsing the spoken claim itself.

That redundancy was not planned. It is simply what happens when you write the rule as a statement about the world rather than as a statement about one file format, and it is the reason I now prefer gates that check claims over gates that check structure.

Originally published at neuragrowth.co. I run a one-person digital-products studio and write up what breaks in production.

If you write CLAUDE.md files, I keep a set of working templates here: neuragrowth.co/free/claude-md-templates.

One Game Costs $9.99. The Next One Is Free.

Robert — Fri, 21 Aug 2026 10:00:02 +0000

Same studio, same month, opposite price tags

NeuraGrowth publishes two games right now, and a visitor comparing them side by side would be right to raise an eyebrow. One asks for money. The other asks for nothing.

Grand Skat is a classic Skat card game. It teaches you the rules across seven lessons, then lets you play offline against the computer or at the free online tables. It costs $9.99 on itch.io for the PC edition, and it is on the Microsoft Store for Windows. One purchase covers the premium features wherever you play. You can also play a free version in the browser at weldowo.pl without buying anything.

Unity in Capsule is a neon twin-stick survivors game. One capsule against endless waves, level-up perks, four modes, an online leaderboard. A run takes ten to fifteen minutes. It costs nothing. Not a trial, not a demo with the good half locked away. The whole game, free on itch.io, donations welcome if you feel like it.

People assume the free one is bait for the paid one. It is not. They were priced by the same rule, and the rule produced two different answers.

A price tag is a claim that the thing is finished

When you pay for something, you are not just buying features. You are buying the maker's statement that this is done, that it works, and that you will not be asked for more money later to make it whole. That claim is the actual product. Break it once and the next thing you publish starts from behind.

Grand Skat can make that claim. The rules are complete, the lessons are written, the offline game works with no connection, and there is nothing behind a second paywall. It has a defined finish line and it crossed it.

Unity in Capsule cannot make that claim yet, and pretending otherwise would be a lie told for $4. It is an early build. We are still adding to it. The honest version of that sentence is not "early access, $4.99, roadmap coming soon". The honest version is: it is free while it is growing, play it now, tell us what breaks.

A leaderboard with nobody on it is just a spreadsheet

There is a practical reason on top of the honest one. Unity in Capsule has an online leaderboard with top scores for each of its four modes: Boss Hunt, Kill Count, Survival and Point Run. A leaderboard is only interesting when there are people on it. Charging admission to a scoreboard nobody has climbed yet is a good way to guarantee it stays empty.

Grand Skat does not have that problem. Skat is a hundred-year-old game with a fixed rulebook. Its value does not depend on how many other people bought it this week. That difference in how the two games create value is exactly why one can carry a price on day one and the other cannot.

Four things our games will never do

"Free" has been ruined by a decade of games that are free the way a fishing hook is free. So it is worth being specific about what we are not doing, because these are commitments, not current limitations.

No ads. Not between runs, not on the death screen, not a rewarded video for one more life.
No in-app purchases. There is no shop, no currency, no starter bundle. There is nothing to sell you inside the game because we did not build a hole for it.
No energy timers. You can play until you are bored. Nothing charges up while you are away.
No loot boxes and no paid seasons. The rare golden perks that change a run outright, the allied minions, the support towers, the healing orb, the screen-clearing purge, are earned in the run. They are not sold.

If Unity in Capsule ever gets a price, it will be because it became a finished game worth one, and everyone who played it for free will still have the whole thing. The one arrangement we will not use is the one where the game is free but your attention is the product.

It is the same rule that prices the flashcards

This is not a games policy. It is how the whole shop works, and the games just made it visible.

Every printable and every guide in the catalogue is a one-time purchase. You download the file and it is yours. No subscription, no per-seat licence, no cloud account that can decide to stop working. The free sample decks on this site are complete small decks, not the first four cards of a deck you have to buy to finish. Same rule, different medium: pay once for something finished, or take the free thing that is genuinely free.

A studio that sells a card game, a survivors game, bilingual flashcards and developer guides could easily end up with four different sets of ethics. Having one rule that survives contact with all four is worth more than any single price tag.

Originally published at neuragrowth.co. I run a one-person digital-products studio and write up what breaks in production.

If you write CLAUDE.md files, I keep a set of working templates here: neuragrowth.co/free/claude-md-templates.

No Roadmap, No Hype: How a Solo Studio Picks What to Build Next

Robert — Thu, 20 Aug 2026 10:00:01 +0000

A plan you cannot keep is just a way to disappoint people

Big shops publish roadmaps because they have teams that need coordinating and investors who want a story. I have neither. A public roadmap from a one-person studio is a list of promises I would end up breaking the first time reality voted differently, and a broken promise costs more trust than a missing plan ever would.

So NeuraGrowth ships without announcing what is next. Not out of secrecy, out of honesty. I would rather show you a finished thing than pre-sell you a slide.

It starts as a private itch, not a market gap

Every product began because I wanted it to exist for my own use. The bilingual decks because my own kid needed better cards. The dev guides because I kept re-solving the same Claude Code problems. The card game because the digital Skat I wanted to play was not good enough. Market-gap language comes later, in the listing. The real trigger is always personal.

This is a filter, not a limitation. If I would not use it, I do not have the judgement to make it well, and a product I cannot judge is a product I should not sell.

Ship the smallest complete version

The goal is never the biggest version. It is the smallest one that is genuinely complete: a deck that teaches one topic properly, a guide that solves one problem end to end. Small and finished beats big and half-done every time, because a finished small thing teaches you something real the day it ships, and a big plan teaches you nothing until it is too late to change.

Complete is the hard word. Small is easy. Small-and-complete means no obvious gap, no chapter I know is missing, nothing I would be embarrassed to show a buyer who read it closely. That bar is what keeps small from becoming thin.

Let reality vote before you plan the sequel

Once a thing is live, the next decision is not mine alone anymore. What sells, what gets a second look, what someone emails me about, those are votes. A deck that moves gets a sibling. A guide that goes quiet does not get a part two just because I sketched one. I would rather follow a small real signal than a big imagined one.

This is why the range looks a little unpredictable from outside. It is supposed to. It follows demand and my own curiosity, not a slide I committed to in January. When both point the same way, that is the next build.

What you give up, and why it is worth it

No roadmap means you cannot pre-order the future, and I cannot hype one. Some people want that and I understand it. What you get instead is that nothing on this site is vaporware. If it has a page, it exists, it is finished, and one person is standing behind it. Everything else is just my next itch, and you will see it the day it is done, not the day I imagined it.

If you want to know what is coming, the honest answer is: whatever I would want to buy next, shipped the moment it is complete. The newsletter is where it lands first. That is the whole plan, and it is the only one I can actually keep.

Originally published at neuragrowth.co. I run a one-person digital-products studio and write up what breaks in production.

If you write CLAUDE.md files, I keep a set of working templates here: neuragrowth.co/free/claude-md-templates.

Why Bilingual EN+PL Beats Trilingual EN+ES+PL on Etsy (Live Data)

Robert — Wed, 19 Aug 2026 10:00:01 +0000

Three numbers, same campaign

We ran the same Etsy Ads budget across fifteen flashcard listings over a recent two-week window. The three of those listings most relevant to this post:

World Flags Watercolor Flashcards (EN+PL bilingual): 225 impressions, 5 clicks, 2.2 percent CTR.
Bilingual Community Helpers Flashcards (EN+PL): 151 impressions, 3 clicks, 2.0 percent CTR.
30-Day Bilingual Coloring Book for Toddlers (EN+ES+PL trilingual): 83 impressions, 1 click, 1.2 percent CTR.

The trilingual listing did not get less impressions because it was less promoted. It pulled less clicks per impression. A buyer scrolling Etsy looked at it and moved on roughly twice as often as the bilingual cards. Same shop, same audience filter, same kind of cover art, same price range.

More languages should mean more buyers

The naive read of the bilingual vs trilingual gap is: more languages, wider audience. A Polish-Spanish family in California buys it. A Spanish-Polish-American household buys it. Three languages must reach more households than two.

The numbers say no. The three-language listing reaches fewer click-ready buyers per impression. The instinct is wrong because the buyer is not selecting on language coverage. The buyer is selecting on whether the deck matches their specific home.

Two clear audiences beats three blurry ones

An EN+PL flashcard deck has a single, instantly-recognisable audience. A Polish parent abroad teaching their kid Polish on top of English. The Etsy thumbnail says "this is exactly for me" in a quarter of a second. The buyer clicks before they read the description.

An EN+ES+PL deck has a fuzzier signal. Is it for a Spanish home learning Polish and English. For a Polish home learning Spanish. For a multicultural classroom. The buyer scrolling Etsy can not tell, in the quarter-second they get on the thumbnail, whether this product is for them. That moment of "I'm not sure" is exactly when they scroll past.

The third language did not subtract value. It subtracted clarity. And in a 220-pixel thumbnail competing for 0.25 seconds of attention, clarity is the entire game.

Numerical specificity stacks on top of language clarity

The bilingual winners share a second pattern. Every one of them has a specific number in the title: 54 countries. 48 mythology cards. 80 vocabulary cards. Each number tightens the audience further. A 54-country deck is for a parent who wants comprehensive geography exposure. A 48-card mythology deck is for the parent of a kid who is into Greek heroes specifically.

The numbers are not boasting. They are filtering. Anyone whose use case does not match the number scrolls past, and that is exactly what the listing wants. The remaining ten percent are pre-qualified buyers.

Specificity is not a niche risk, it is the conversion

Most home-printable shops hedge. They list "bilingual cards" without naming the languages, or "kids deck" without naming the age range, or "vocabulary" without naming the count. They are protecting themselves from looking too narrow. The data says the opposite: the broader the framing, the lower the click-through.

What scrolling a buyer wants in 0.25 seconds is not "this MIGHT be for me". It is "this IS for me". The way to deliver that signal is to be more specific, not less.

Five small calls based on the same data

Bilingual EN+PL is the canonical format for the kid catalogue. Adding a third language has to clear a much higher bar than "why not". If we cannot name the parent at the moment of click, we keep it at two languages.
Every kid deck title carries a number. 24 vocabulary cards. 48 mythology cards. 7 continents. The deck has to actually contain that count, but if it does, the number goes in the title.
Every kid deck title carries an explicit age range. "Ages 7 to 11" or "Ages 3 to 5". Vague "for kids" loses to specific ranges in the same ad budget by another quarter of a CTR point.
Trilingual is a separate product line, not an upgrade. If we make a trilingual deck, it gets a different SEO angle than the bilingual one. Not "bilingual but better", a different positioning aimed at the multi-language home directly.
The data review is weekly, not monthly. Two weeks of campaign data was enough to surface this gap. We re-pull and re-decide every Wednesday, not at end of quarter.

Trilingual decks have a role, just not this one

Nothing in the numbers above says trilingual products are bad. They have a real audience: the multi-language home that explicitly wants three languages on one card. That household exists, that household buys, and we will keep serving it.

What the numbers say is that for the broad Etsy search browse path, a trilingual listing does not win against a bilingual listing on click-through. The conclusion is to position trilingual decks differently, not to make fewer of them. Different framing, different keyword set, different ad copy. Same way "Ages 3 to 5" and "Ages 7 to 11" are not the same product even when they cover the same topic.

If you sell printables too, the framework transfers

The numbers above are from our shop, but the click-through dynamics are not unique to bilingual flashcards. Three questions to run against your own catalogue.

Can the buyer name themselves in the thumbnail. If a Polish parent abroad sees your card and recognises themselves in a quarter of a second, the click-through is high. If they have to read the description to find out whether the deck is for them, you have already lost most of the impression budget.
Does the title contain a filtering number. If yes, every uninterested buyer self-eliminates and you do not pay for their impression to convert. If no, you are paying for impressions that scroll past.
Does the title contain an age range. "Ages 6 to 10" performs in our shop at roughly the same lift as a counted number. Both filter the audience, both raise click-through.

None of this is sophisticated. The data above is fifteen listings over two weeks on a small shop. But the gap between bilingual and trilingual on the same budget is large enough that we are willing to change the catalogue around it. Maybe you will look at your own numbers and find the same.

Clear is the conversion lever, not loud

A common piece of advice for new Etsy shops is to be bolder. Bigger thumbnails, brighter colours, more keywords stuffed into the title. The data from our shop says a different lever pays more: be clearer about who the deck is for and what is in it. The buyer is not asking for louder. They are asking for an immediate answer to "is this for me". When the answer arrives in a quarter of a second, the click happens. When it does not, the impression goes nowhere.

Originally published at neuragrowth.co. I run a one-person digital-products studio and write up what breaks in production.

If you write CLAUDE.md files, I keep a set of working templates here: neuragrowth.co/free/claude-md-templates.

Behind Every NeuraGrowth Cover: Watercolor and AI, Honest Workflow

Robert — Tue, 18 Aug 2026 10:00:01 +0000

If you ask "did a human paint this", you deserve a straight answer

Etsy now requires AI-assisted listings to say so. Most printable shops respond with a one-line disclosure in tiny type at the bottom of the description and call it done. That is technically compliant and also a missed chance to actually explain anything to the parent on the other end of the transaction.

So instead of a disclosure paragraph, here is a full walkthrough. Same workflow on every cover, no curated exceptions. If at any step you decide the result is dishonest about the labour involved, you tell me and I will rethink the step. The whole point of running this solo is that there is exactly one inbox to write to.

The art brief is the long part

Every product starts with an art brief I write by hand. Not a Pinterest mood board. A short specification: dominant subject, framing, palette family (we have three, all warm), illustration density, what the cover must communicate at thumbnail size on an Etsy search page where the visitor sees roughly 220 pixels of total information before they decide whether to click.

That brief is maybe a hundred words long and it takes me an hour to write well, because it is the only step where my taste is the entire input. AI assist does not help here. If the brief is vague, the cover will be vague.

The render is where AI does heavy lifting

I feed the brief into a custom rendering pipeline built on top of a few diffusion models tuned for watercolor and line-art outputs. The pipeline generates four candidates at a time and I cull aggressively. Most decks need eight to twelve rounds before a cover passes my own bar, which means thirty to fifty rejected images sit in the trash for every one that ships.

The AI did the brushwork. I am not going to pretend a human picked up a brush. What I will tell you is that the prompt, the candidate culling, and the cover composition are decisions I make every single time, and I refuse covers where the AI got too clever and inserted a sixth finger, a misaligned eye, or a colour palette that drifts off our three warm families.

The colour pass is non-negotiable

AI renders out of the box have a tell. Too many simultaneous focal points, off-brand cyan slipping into a warm-palette piece, contrast that looks great on a 4K monitor but mush on a 6-inch listing thumbnail. So every accepted render goes through a manual colour pass: shadows clipped, contrast lifted, off-brand hues nudged out, and the focal subject sharpened.

On a typical cover this is a fifteen-minute pass per image. On a deck like Solar System Brain Deck, where every planet needs to read distinctly at thumbnail size on a 40-card spread, the colour pass is closer to two hours of work across the deck. This is the step that separates a stock-feeling AI image from something that looks like the deck was art-directed.

Reject or ship, no in-between

The last step is a single yes-or-no question I ask myself before a cover leaves the build folder. Would I put my name on this on Etsy. Not "is this good enough for the price point". Just: name on it, yes or no.

A surprising amount gets rejected here, even after passing steps two and three. Sometimes it is a vibe thing: the deck reads as cheerful but the cover reads as flat. Sometimes the subject is technically perfect but it does not match the rest of the deck. Whatever the reason, if I would not put my name on it, the cover goes back to step two and we re-roll. The deadline for a drop is always later than this gate.

Three places I refuse to let the pipeline drive

People ask me where the automation stops. Three places where the AI pipeline is locked out by design, even though it would technically be cheaper to let it run.

Subject choice. What goes on the cover is a decision about what the product is for. That is a brand call, not a render call. AI does not pick our subjects, ever.
The ship-or-reject gate. No automated quality threshold replaces the yes-or-no on whether I would put my name on the result. If it ever became automated, the brand would die quietly inside a year.
The reply when something is wrong. If you email about a cover that disappointed you, the reply comes from me. Not a template. Not a bot. The person who picked the subject and pressed ship is the person who answers when it did not land.

Hybrid is not a compromise, it is the work

The honest framing of a NeuraGrowth cover is: a custom AI pipeline did the painterly work that would have taken a freelance illustrator six hours per cover, and I did the brand-direction work that no AI can do for me yet. Both are real labour. Both make the cover what it is. Saying "AI made it" undersells the brief and the colour pass. Saying "I made it by hand" would be a straight lie about the brushwork.

So we say hybrid, in plain English, in every listing. The watercolor is real watercolor-style rendering. The decisions about what to put on the cover and whether it ships are mine. If at any point you want a deeper look at one of the covers, write me, and I will walk you through which step did what for that specific piece.

Originally published at neuragrowth.co. I run a one-person digital-products studio and write up what breaks in production.

If you write CLAUDE.md files, I keep a set of working templates here: neuragrowth.co/free/claude-md-templates.