DEV Community: JonathanSolvesProblems

A maintainer, me, and Sentry's own AI all reached for the same wrong fix

JonathanSolvesProblems — Wed, 19 Aug 2026 23:35:04 +0000

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

Three people tried to fix the same memory leak in Sentry's Python SDK. One was a Sentry maintainer. One was me. One was Sentry's own AI debugger.

All three fixes were wrong, and they were wrong for the same underlying reason. That convergence is the actual story, and it took me a while to see it, because I was too busy being pleased with my own version.

The leak, briefly

DedupeIntegration remembers the last exception it saw so it can drop a duplicate report. It stores a weak reference, because holding the exception would hold its traceback, and a traceback holds every frame, and a frame holds every local variable in it.

Then there is this:

# we can only weakref non builtin types
try:
    integration._last_seen.set(weakref.ref(exc))
except TypeError:
    integration._last_seen.set(exc)

You cannot weak-reference a ValueError. So the fallback runs, and it does the exact thing the weak reference existed to prevent. It lives in a ContextVar, so under asyncio every task keeps its own copy: one retained exception, one traceback, one full set of frame locals, per live task.

Measured across 200 long-lived sessions holding a megabyte each: 205 MB retained, all 200 still reachable after gc.collect().

That part I have written up in full elsewhere. This post is about the three fixes.

Attempt one: the maintainer

Digging through the fork's branch list, I found two abandoned branches from September 2025, neither merged. The first replaces the stored exception with a SHA-256 fingerprint over (type_module, type_name, id(exc_value)).

It is a reasonable instinct. Store a cheap value, not the object. The problem is id().

Not retaining the exception is precisely what frees its address, and CPython reuses freed addresses immediately. Over 2000 distinct, sequentially allocated ValueErrors:

distinct exceptions created : 2000
distinct fingerprints       : 2
address-reuse collisions    : 1998

Two fingerprints for two thousand distinct errors. Every collision is a real error that gets silently dropped as a duplicate. The fix trades a memory leak for losing almost every error you report, which is worse than the leak.

Attempt two: me

I did not see that branch until much later, which is lucky, because I made the same class of mistake independently.

My idea was a value fingerprint with no id() in it: exception type, message, and the origin frame from the traceback. All immutable primitives. Nothing retained. I was confident enough to post it publicly on the issue.

The SDK's own test suite killed it in two different ways within about a minute of running.

test_breadcrumbs captures two distinct, never-raised ValueError() instances. No traceback, no message, so both fingerprints are identical and the second event is dropped.

test_option_before_breadcrumb is worse. It calls the same function three times, each raising a separate ValueError("aha!") from the same line. Same type, same message, same origin frame. Three identical fingerprints, two events wrongly deduplicated.

The flaw is not in my choice of fields. It is structural:

A value fingerprint cannot distinguish "the same exception object captured twice" from "the same error raised twice from the same line."

The first must deduplicate. The second must not. By value, they are identical. No amount of extra fields fixes that, because the thing being asked for is not a property of the value.

I went back to the issue and said I had been wrong.

Attempt three: the AI

Later I pointed Sentry's own AI debugger, Seer, at the issue in my own Sentry project.

Its diagnosis was genuinely excellent, and better than I expected. It reached past my application code into a third-party SDK, identified the ContextVar strong reference, identified that weakref.ref raises TypeError on builtin exception types, and identified that ContextVars are per-task under asyncio. That last detail had cost me a full debugging round to work out on my own. It cited dedupe.py lines as evidence, so it had gone and read the source rather than guessing from a stack trace.

Then it proposed the fix:

store a hashable identity tuple like (type(exc), id(exc))

id() again. I ran its exact tuple:

distinct errors raised         : 2000
events wrongly dropped as dupe : 1999  (100.0%)

Three independent parties. Two humans and a model. Two different wrong answers that are secretly the same wrong answer.

The thing all three of us did

Every one of us tried to represent identity with a value.

An object's identity is not a property you can read off it. It is the fact of the object existing, distinct from every other object, for as long as it lives. A fingerprint made of type and message describes what the exception is like. An address describes where it currently sits. Neither survives the thing that makes identity useful, which is that two objects that look the same are still two objects.

Once I could say that sentence, the fix was obvious, and it is not a fingerprint at all:

class _DedupeToken:
    __slots__ = ("__weakref__",)

Attach one token to the exception and weakly reference the token. There is exactly one per exception object and it lives exactly as long as the exception does, so comparing tokens is comparing identity. The ContextVar holds nothing that keeps a traceback alive, and deduplication behaviour does not change at all.

Same 200 sessions, after the fix: 0.7 MB, nothing pinned.

The part I did not expect

There is a coda that I only found while going back through a screen recording, and it is the most interesting thing I learned all week.

Seer did not only propose a plan. It also opened a pull request with generated code. The code is not what the plan said.

try:
    integration._last_seen.set(weakref.ref(exc))
except TypeError:
    pass

No identity tuple anywhere. It simply stops storing for builtin exceptions. That does remove the leak, and it has none of the address-reuse problem, but it silently disables deduplication for the exception types most errors actually are. It is also, precisely, the fix the maintainers had already declined on the issue months earlier.

So the plan and the patch disagree with each other, and they are wrong in two different ways.

I want to be fair here, because the diagnosis was the hard part and it got that right, from evidence, without my framing. But if you let an agent open pull requests: read the diff, not the summary. They are not required to match, and here they did not.

What I took away

The comment # we can only weakref non builtin types sat directly above the line that caused the leak, for years. It described the hazard accurately and then the next line walked into it. A fallback is still a code path, and this one ran for the overwhelming majority of real exceptions.

And the more useful lesson: when several competent people independently produce the same wrong answer, that is information. It usually means the obvious framing of the problem is the thing that is wrong, not the people. Three of us reached for a fingerprint because "store something small instead of the object" is a good habit. The habit was fine. The question was wrong.

Everything here is reproducible, including all three failed fixes, at JonathanSolvesProblems/sentry-dedupe-leak-repro. id_reuse_hazard.py runs the maintainer's approach and Seer's, side by side, and prints exactly how many errors each one would lose.

Python can't weakref a ValueError. Sentry's deduplication found out the expensive way.

JonathanSolvesProblems — Wed, 19 Aug 2026 23:14:14 +0000

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry.

Two and a half minutes: the leak, the two fixes that do not work, and what Sentry's Seer made of it. Everything below is the written version, with the parts the video did not have room for.

Project Overview

sentry-python is Sentry's Python SDK. One of its default integrations is DedupeIntegration, which stops the same error being reported twice. The mechanism is about as simple as it gets: remember the last exception you saw, and if the next one is the same object, drop the event.

Remembering an exception is where it gets interesting, because remembering it is exactly what you must not do. An exception holds its traceback, a traceback holds its frames, and a frame holds every local variable in it. Keep the exception and you keep all of that.

The SDK knew this. That is why it stored a weak reference:

# we can only weakref non builtin types
try:
    integration._last_seen.set(weakref.ref(exc))
except TypeError:
    integration._last_seen.set(exc)

The comment tells you the whole story. You cannot take a weak reference to a builtin exception. ValueError, KeyError, TypeError, the ones almost every error actually is. So weakref.ref(exc) raises TypeError, and the fallback quietly does the one thing the weak reference existed to prevent.

Issue #6094 reported it as unexplained memory growth in an asyncio web crawler.

Bug Fix or Performance Improvement

Why asyncio makes it hurt

_last_seen is a ContextVar. Under asyncio, every task gets its own copy of context. So this is not one retained exception process-wide. It is one retained exception per live task, each one dragging along its traceback and every frame local reachable from it.

The reporter's frames held fetched response bodies between 500 KB and 1 MB.

Measuring it honestly

My first instinct was to call it an unbounded leak. I built a worker pool, ran it, and it stayed flat. That was worth finding out before I wrote it down anywhere.

A fixed pool does not grow, because each worker's next error overwrites its previous one. Retention is bounded at (live tasks x payload). The growth story is not errors over time, it is tasks over time: one task per session, per subscription, per connection.

So I measured against live task count instead. Each task fails once, reports it, then stays alive the way a real session handler does:

  live tasks |     retained |   per task |  sessions pinned
-------------+--------------+------------+-----------------
          25 |      26.2 MB |    1047 KB |      25 / 25
          50 |      52.1 MB |    1042 KB |      50 / 50
         100 |     103.3 MB |    1033 KB |     100 / 100
         200 |     205.4 MB |    1027 KB |     200 / 200

1024 KB retained per live task, dead straight, and sessions pinned counts weak references to session objects that are still reachable after gc.collect(). Not a sampling artifact. The garbage collector cannot touch them because a live ContextVar genuinely still points at them.

At 200 concurrent sessions that is 205 MB that never comes back.

The fix I got wrong first

The maintainers had already rejected the obvious fix. The reporter proposed skipping dedupe for builtins, and Sentry declined, saying they wanted "a more robust fingerprinting approach that can also be used for built-in exceptions" instead.

So I proposed a fingerprint: exception type, message, and the origin frame from the traceback. All immutable primitives, nothing retained. I posted it on the issue.

Then the existing test suite told me I was wrong, in two different ways.

test_breadcrumbs calls capture_exception(ValueError()) twice with two distinct, never-raised exceptions. No traceback, no message, so both fingerprints are identical and the second event gets dropped.

test_option_before_breadcrumb was worse. It calls the same function three times, each raising a separate ValueError("aha!") from the same line. Same type, same message, same origin frame. Three fingerprints, all identical, two events wrongly deduplicated.

That is the flaw in the whole idea. A value fingerprint cannot tell "the same exception object twice" apart from "the same error raised repeatedly from the same line." The first must deduplicate. The second must not. No fingerprint distinguishes them, because by value they are the same.

I went back to the issue and said so.

The attempt that came before mine

Late on, I went looking through the fork's branch list and found two abandoned maintainer branches from September 2025: antonpirker/dedupe-integration-memory-usage and antonpirker/make-dedupe-integration-more-memory-efficient. Neither was merged.

The first one fingerprints on (type_module, type_name, id(exc_value)).

That id() is the interesting part. Once you stop retaining the exception, which is the entire point of the change, its address becomes immediately reusable, and CPython reuses addresses aggressively. Modelling that fingerprint over 2000 distinct, sequentially allocated ValueErrors:

distinct exceptions created : 2000
distinct fingerprints       : 2
address-reuse collisions    : 1998

Two fingerprints for two thousand distinct errors. Each collision is a real error that would be silently dropped as a duplicate.

I mention this not to dunk on an abandoned branch, which is a draft nobody shipped, but because it is the third distinct way I watched this problem punish an obvious solution. Fingerprinting on value collapses errors that came from the same line. Fingerprinting on address collapses errors that reused the same memory. The information being fingerprinted just is not sufficient to express object identity.

The fix that works

The problem was never that identity was the wrong key. It was that holding the object was the wrong way to hold identity.

So keep the identity and drop the object. Attach a small weak-referenceable token to the exception, then weakly reference the token:

class _DedupeToken:
    __slots__ = ("__weakref__",)

There is exactly one token per exception object, and it lives precisely as long as the exception does. last_seen is token is therefore equivalent to the old last_seen is exc, while the ContextVar holds nothing that keeps a traceback alive.

Deduplication behaviour is unchanged, which is the part that matters given the maintainers' concern.

Code

The whole change to the hot path:

exc = exc_info[1]

new_last_seen: "Any"
try:
    # We can only weakref non builtin types.
    new_last_seen = weakref.ref(exc)
    is_duplicate = last_seen is exc
except TypeError:
    # Builtin exception. Referencing it strongly here would pin its
    # traceback and every frame local in that traceback for the
    # lifetime of the ContextVar (#6094). Weakly reference an
    # identity token carried by the exception instead, which dies
    # with it and keeps dedupe keyed on exception identity.
    token = _identity_token(exc)
    if token is not None:
        new_last_seen = weakref.ref(token)
        is_duplicate = last_seen is token
    else:
        new_last_seen = exc
        is_duplicate = last_seen is exc

And the token lookup, after hardening (more on that below):

def _identity_token(exc: BaseException) -> "Optional[_DedupeToken]":
    try:
        if exc.__traceback__ is None:
            return None

        exc_dict = exc.__dict__
        token = exc_dict.get(_DEDUPE_TOKEN_ATTR)
        if isinstance(token, _DedupeToken):
            return token

        token = _DedupeToken()
        exc_dict[_DEDUPE_TOKEN_ATTR] = token
        return token
    except Exception:
        # Exceptions can define ``__dict__`` as a property returning anything,
        # or back it with a mapping that refuses mutation. None of that may
        # break event processing, so fall back to the previous behaviour.
        return None

The __traceback__ is None check is deliberate. An exception that was never raised has no frames to pin, so there is nothing to fix and no reason to touch it. That keeps vars(exc) clean for the common case.

Branch: fix/dedupe-builtin-exception-retention

Everything in this post is reproducible. The harness is at JonathanSolvesProblems/sentry-dedupe-leak-repro: the scaling measurement, the traceback probe, the five adversarial checks against my own fix, and the script that verifies the LLM review claim by claim.

My Improvements

Five tests, and the first one fails without the fix, which is the only thing that makes it a regression test:

test_dedupe_does_not_retain_builtin_exception puts a sentinel in the raising frame and asserts it is collectable afterwards
test_dedupe_still_dedupes_builtin_exception re-raises the same object and asserts one event
test_dedupe_distinguishes_equal_builtin_exceptions raises two identical-looking errors from the same line and asserts two events. This is the one fingerprinting broke
test_dedupe_leaves_unraised_exception_untouched asserts vars(exc) == {} for a never-raised exception
test_dedupe_survives_exotic_exception_dict covers the crashes described below

I also verified what the ContextVar actually holds, rather than trusting the memory numbers:

	`_last_seen` holds	1 MB payload after `gc.collect()`
master	`ValueError` (strong ref)	alive
fixed	`ReferenceType` (weakref)	freed

One process note, because it cost me an hour and nearly cost me a wrong claim. Once the fix was committed to a branch, git stash push <file> had nothing to stash, so my "before and after" runs were quietly comparing the fix against itself. Two measurements came back identical and I believed them for longer than I should have. The tell was a probe printing whether the new symbol was importable, which said True in both columns. Baselines have to be taken with git checkout master -- <file>, and the baseline needs to prove it is actually the baseline.

Best Use of Sentry

Sentry features used: Error Monitoring, Releases, custom Contexts and Tags, Issue Grouping, Seer (Autofix root cause analysis).

The interesting part of instrumenting this was discovering that Sentry could not see the bug, and why.

I built a small asyncio service that opens one long-lived task per session, hits one ordinary ValueError, reports it, and keeps the session open. Ran it against a real Sentry project twice, tagged as two releases, dedupe@unpatched and dedupe@patched.

Sentry showed a completely healthy application. One issue, ValueError: malformed frame on session N, 240 events, handled: yes, mechanism: generic. Exactly what you would expect from a service that reports its own handled errors. Nothing in it suggests 62 MB is being retained.

That is the actual lesson. This bug produces no error. The ValueError is deliberate and correctly handled. Error monitoring alone is structurally incapable of surfacing a retention bug, because retention is not an event.

There is a nice detail buried in that first issue, too. The frame local Sentry captured for the raising frame reads session [Filtered], scrubbed by default PII protection. The one object whose retention was the entire problem was the one thing redacted out of the report.

So I used Sentry two other ways.

First, as a measuring instrument. Every error event carries a custom memory context with the retained figure at the moment it was sent. The errors are identical across both releases; the context is not. Comparing dedupe@unpatched against dedupe@patched on the same issue turns an invisible bug into a visible diff, without a single new error being raised.

Second, by making the leak raise something. The demo checks its own retention after the sessions are open, and when session state is still reachable it reports a distinct RetentionLeak issue carrying the diagnosis:

sessions_pinned         : 60/60
retained_mb             : 62.6
referrer_chain          : Session <- frame(handle_message) <- traceback <- traceback <- exception(ValueError)
dedupe_last_seen_holds  : ValueError

That last line is the whole bug in one field, and getting it was its own small lesson. My first attempt read DedupeIntegration._last_seen from the parent task and reported nothing. _last_seen is a ContextVar, so every asyncio task has its own copy and it always reads empty from outside. Reading it from inside the capturing task gives ValueError on the unpatched release and ReferenceType on the patched one. The thing that made the diagnostic hard to write is precisely the thing that makes the bug scale with task count.

release	`_last_seen` holds	sessions pinned	retained
`dedupe@unpatched`	`ValueError`	60 / 60	62.6 MB
`dedupe@patched`	`ReferenceType`	0 / 60	1.3 MB

What Seer made of it

I connected the sentry-python fork to the project and ran Autofix on the RetentionLeak issue. I expected it to stop at my demo code, because that is where the stack trace points. It did not.

Its root cause, verbatim:

DedupeIntegration stores strong exception references in a ContextVar for builtin exceptions, retaining tracebacks and all frame locals (including large session buffers) for the asyncio task's lifetime.

And the supporting chain:

The ValueError exceptions are kept alive because DedupeIntegration._last_seen ContextVar holds a strong reference to each one.

weakref.ref(exc) raises TypeError for builtin exception types like ValueError, so the fallback path stores the bare exception object instead of a weakref.

Each asyncio task has its own copy of the ContextVar (per-task context), so the strong reference to the exception persists for the entire lifetime of each long-lived task.

That is the bug, exactly, including the per-task ContextVar detail that cost me a debugging round of my own to work out. It cited dedupe.py L1-L62 as evidence, so it went and read the SDK source rather than guessing from the stack trace. Its five reproduction steps are accurate enough to hand to someone else.

Then it proposed a fix:

In dedupe.py, change the except TypeError fallback from integration._last_seen.set(exc) to store a hashable identity tuple like (type(exc), id(exc)) instead of the exception object itself.

That fix does not work, and it fails for the same reason the abandoned maintainer branch does. Storing only an identity key is what allows the exception to be freed, and a freed address is immediately reusable. Running Seer's exact tuple over 2000 distinct errors:

distinct errors raised         : 2000
events wrongly dropped as dupe : 1999  (100.0%)

It would trade a memory leak for silently discarding almost every error you report.

There is a wrinkle I only found afterwards, and it is the most interesting thing in this whole section. Seer also opened a pull request against my fork with generated code, and the code is not what the plan said. It does not store an identity tuple at all:

try:
    integration._last_seen.set(weakref.ref(exc))
except TypeError:
    pass

That skips storing anything for builtins. It does remove the leak, and it has none of the address-reuse problem, but it silently disables deduplication for exactly the exception types most errors actually are. It is the fix the reporter originally proposed and that the maintainers explicitly declined, for the reason quoted at the top of this post.

So the plan and the patch disagree with each other, and they are wrong in two different ways. If you let an agent open pull requests, that is worth knowing: the prose it shows you for review is not necessarily the diff it writes.

I want to be fair about what that means, because it is not a gotcha. Seer did the hard part correctly. Diagnosing this required reading past the stack trace into a third-party SDK, understanding weakref support on builtin types, and knowing that ContextVars are per-task under asyncio. It got all three from one event and the source. The part it got wrong is the part that requires knowing how CPython recycles memory addresses, which is not visible anywhere in the evidence it was given.

And it is genuinely interesting that three independent attempts, an abandoned branch by a Sentry maintainer, my own first attempt, and Seer, all reached for a fingerprint or an identity key, and all three are wrong for the same underlying reason. The information available to a fingerprint is not sufficient to express object identity. That the AI converged on the same wrong answer as two humans is more a statement about the problem than about the AI.

What I actually got out of Seer was the thing I would have wanted from a colleague: an independent confirmation of the diagnosis, arrived at from the evidence rather than from my framing of it.

Best Use of Google AI

I had already run my own adversarial pass on the patch: pickling, copy/deepcopy, payload leakage, __slots__ exceptions, and retention through __context__ chains. All five passed.

So I gave the diff to Gemini 3.6 Flash, told it exactly what I had already covered, and asked only for failure modes I had missed, each with a snippet I could run. Then I ran all of them, because a review you do not verify is just a second opinion with extra steps.

It returned six. The scoreboard:

#	Claim	Verdict
1	`__dict__` as a property returning `None` crashes event processing	Confirmed, real crash
2	a `__dict__` backed by a mapping that refuses mutation crashes	Confirmed, real crash
3	a dynamic `__dict__` breaks token identity	Confirmed, fails open
4	the token is visible in `vars(exc)`	Confirmed, real tradeoff
5	a thread race yields mismatched tokens	Refuted, 0 of 200 attempts
6	`__dict__.clear()` loses the token	Confirmed, fails open

Claims 1 and 2 were genuine bugs that my own pass had missed. My except (AttributeError, TypeError) was too narrow, so an exception class doing something unusual with __dict__ could crash Sentry's event processing. The SDK's own contributing guide says integrations must not crash applications, so those were not academic.

class NonDictException(Exception):
    @property
    def __dict__(self):
        return None

# before: AttributeError: 'NoneType' object has no attribute 'get'

Claim 5 was wrong, and I only know that because I ran it 200 times with a threading.Barrier instead of nodding along.

Claims 3 and 6 are real but fail open: you get a duplicate event rather than losing one. That is the correct direction to fail.

Claim 4 is a fair criticism and I have not made it go away. The token lives in exc.__dict__, so it shows up in vars(exc) and makes json.dumps(vars(exc)) raise. I narrowed it to raised exceptions only, and the SDK already does the same kind of thing (sentry_sdk/integrations/django/__init__.py sets _sentry_drf_request_backref on a user object), but it is a real tradeoff and the PR says so rather than hiding it.

Two real crashes found, one confidently wrong claim caught, in a review that took about four minutes. That is a good trade, and it only works if you treat the output as a list of hypotheses instead of a list of findings.

What I took away from this bug

The comment # we can only weakref non builtin types was right there, in the code, for years. It described the exact hazard and then the next line walked straight into it. A fallback path is still a code path, and this one ran for the overwhelming majority of real exceptions.

The other thing: my measurements lied to me twice, in opposite directions. Once when I assumed unbounded growth and a flat graph corrected me, and once when a stash silently did nothing and two identical columns looked like a result. Both times the fix was the same, which was to make the harness prove its own setup before trusting a single number out of it.

Everyone Believes Black Dogs Get Left Behind. I Checked 99,916 Shelter Records. They Don't.

JonathanSolvesProblems — Sun, 16 Aug 2026 12:18:08 +0000

My family's dog died recently. He lived with my mom, I met him the day he was born, and I knew him almost his whole life. It was hard on all of us in the way that is difficult to explain to anyone who has not had it happen.

A little while later my mom brought home another dog. He does not replace the first one, and nobody in my family pretends otherwise. But a house with a dog in it is a different house, and hers is whole again.

That exchange happened about two million times last year in the United States alone, counting dogs only. What I had not thought about until this weekend is that there is a queue for it, that the queue is very long for some dogs and very short for others, and that the difference is not what almost everyone believes it is.

What I Built

Still Here is a live board of every dog Austin Animal Center has an intake record for and no outcome record. As I write this there are 510 of them.

The one at the top is called Pancho. He is a white Cairn Terrier, he was picked up as a stray on May 23, 2025, and he has been there 449 days. 99.7% of the dogs in his breed group were adopted in less time than he has already been waiting.

Every figure in this post is from the board on 16 August 2026. The site recomputes on every load, so by the time you read this the day counts will have moved and some of these dogs will have gone home.

Then I went looking for the reason the dogs at the top of that board are the ones at the top.

The board moves. Between two runs of the pipeline a day apart, nine dogs came off it: seven were adopted, one was reclaimed by an owner who came looking, and one was transferred to a partner rescue. Four new dogs arrived. Baxter had been waiting 71 days and went home on the fifteenth.

The claim I set out to check

If you have spent any time around animal shelters you have heard of black dog syndrome: the belief that black dogs sit unadopted while lighter dogs go home. It is repeated in shelter training material, in local news segments, and in a great many well-meaning adoption posts every October.

It is a genuinely checkable claim, and Austin has published enough records to check it.

I pulled every completed dog stay the city has released since October 2013 and reconstructed how long each one lasted: 99,916 stays, of which 51,413 ended in adoption. Then I took the median wait for each coat color.

coat	median days to adoption	n
Blue	22	2,064
Brown Brindle	16	2,521
Fawn	16	617
Brown	10	7,085
White	10	8,797
Chocolate	10	1,163
Black	9	13,922
Tan	8	6,236
Cream	7	770

Black dogs are in the fast half. Thirteen thousand nine hundred and twenty-two of them, leaving in a median of nine days, quicker than white, brown or chocolate.

So the myth does not survive its first contact with the data. That much matches the published research: a 2016 study by Christy Hoffman and colleagues, in Animal Welfare, looked at nearly 16,700 records across two shelters and found black dogs left slightly faster than average at both.

That study also reports the other half of what I found, which I did not know when I started looking: bully breeds stayed roughly 2.5 to 3 times longer than average. Two Pacific Northwest shelters, a decade earlier, a completely separate dataset from mine.

But there is something much more interesting sitting in that same table, and it took me a second pass to see it.

The colors that wait are the colors pit bulls come in

Look at the top of that list again. Blue, brown brindle, fawn. Those are not random slow colors. They are the coats you picture when you picture a pit bull.

So I split every color by whether the dog was a bully-type breed, meaning pit bull, Staffordshire, or American bulldog:

coat	bully-type	everyone else
Brown	32.5	9
Black	31	8
Tan	30	7
White	29	8
Red	27	8
Chocolate	26.5	8
Blue	26	11
Brown Brindle	25	11

The two columns do not overlap anywhere. Every bully-type cell is between 25 and 32.5 days. Every other cell is between 7 and 11. The fastest bully-type coat is still 14 days slower than the slowest coat outside the group.

Within a breed group, coat color moves the median wait by at most 7.5 days. Changing the breed group moves it by 20.

Black only looked fast in the first table because black dogs are the least likely to be bully-type: 12% of them, against 81% of the blue ones. The color signal was a breed signal the whole time. A black dog that is not a bully breed waits 8 days. A black pit bull waits 31.

Across the whole corpus: bully-type dogs wait a median of 28 days, and every other dog waits 8. That is 3.5 times, on 9,658 bully-type adoptions against 41,755 others.

And it is not a historical curiosity. Of the 510 dogs sitting in that shelter today, 216 are bully-type. Four of the five longest waits on the board right now are pit bulls.

The thing the adoption site does not tell you

Austin publishes, in open data, exactly how long every dog has been in its care. Its adoption site shows none of it.

I checked the listings the city actually serves to adopters. A listing carries breed, sex, size, age, kennel number, and a set of behavior tags. There is no intake date on it, no length of stay, and no way to sort or filter by either. There is a manual "Long-term resident" tag a staff member can tick, but nothing that gives you a number.

So a person browsing Austin's adoption page can look straight at Fritz and have no idea he arrived on May 28 of last year.

Both halves of that are public. They are just never printed next to each other. Still Here is the join.

Demo

Under two minutes, narrated over the live site, with the research citations on screen where the claims are made.

Live board: jonathansolvesproblems.github.io/still-here

The board is a photographic contact sheet, one frame per dog, ordered by how long each has waited. The day count and the glow are that wait: the longer a dog has been there, the more it has burned into the plate.

Every frame links to that dog's real adoption page, so clicking one takes you somewhere you could actually adopt it.

Things worth trying:

Search a breed. Type labrador, husky or brindle. Multiple words narrow rather than widen, so black lab finds 19 dogs. Austin's own site lets you filter by breed but never tells you how long any of them has waited; this does both.
Press play on any dog. Each one reads its own record aloud, and each breed group opens with its own sound: a howl for the hounds, a husky's howl for the spitz breeds, a yip for the toy dogs.
Filter to "Over a year" for the 18 dogs who have been there more than 365 days.
Filter to "Unnamed" for the ones who arrived without a name.
Click any day count to pin that dog to the top, then copy the link. ?dog=7950 is Pancho.

Code

JonathanSolvesProblems / still-here

510 dogs have an intake record at the Austin animal shelter and no outcome record. This is the board.

Still Here

510 dogs have an intake record at the Austin animal shelter and no outcome record. This is the board.

Built for the DEV Weekend Challenge: Dog Days Edition, August 2026.

Live board: https://jonathansolvesproblems.github.io/still-here/

▶ Watch the demo (2 min): https://www.youtube.com/watch?v=RNa5V26TXzI

Write-up: on DEV and on my site.

The longest wait on the board belongs to Pancho, a white Cairn Terrier who was picked up as a stray on May 23, 2025. As of the last data pull he had been there 449 days. 99.7% of dogs in his breed group were adopted in less time than he has already been waiting.

The finding

Black dog syndrome, the belief that a dark coat keeps a dog in the kennel does not appear in Austin's records. Across 99,916 completed dog stays since 2013, black dogs leave in a median of 9 days, faster than white, brown…

View on GitHub

Everything is in the open, including the corpus, so every number here is checkable.

How I Built It

The data has two eras, and the famous one is frozen

Austin publishes intakes and outcomes on Socrata with no API key required. The dataset IDs that every tutorial points at are archives frozen at 2025-05-05. Query wter-evkm today and you get a tidy 173,812 rows, not one of them from the last fifteen months. The live feeds are different IDs and a different schema, and finding that out was most of an hour.

This project reads both. The live outcome feed ships a days_in_shelter column; the archive does not, so each archived outcome is paired with the most recent intake for that animal that precedes it. Dogs cycle through the shelter more than once, and matching on animal ID alone would charge a repeat stray's whole history to a single stay. 652 outcomes could not be paired and were dropped rather than guessed at.

Snowflake does the counting

All 99,916 stays and the 510 current dogs load through an internal stage, and every number quoted above comes out of a view rather than out of application code. The bully-type definition lives in a single SQL function, IS_BULLY(), so the one judgement call in the whole analysis is auditable in one place instead of scattered through Python.

The piece that genuinely wants a warehouse is the per-dog percentile: for each of the 510 waiting dogs, rank its current wait against every completed stay in its breed group. That is 510 live values against 51,413 historical ones, and it is one view.

I also kept the Python implementation and made the two argue. verify.py re-runs every headline question locally and diffs it against what Snowflake returned, across the medians, the counts, the color table, the controlled split, the spreads, and the per-dog percentile for the top 25 dogs. 102 of 102 checks agree. If they ever disagree, one of them is wrong and the number does not go in the writeup.

Finding the faces

The open data has no photographs in it. But Austin's adoption listings run on a platform called Adopets, and its code field is the same animal id the open data uses, so the two join directly.

I checked the join rather than trusting it: of the matched dogs that have a name on both sides, 97% agree, and the handful that disagree are the shelter renaming a dog after intake. Unknown becomes Tinkerbelle. Fat Boy becomes Big Boy. The importer refuses to write the mapping at all if agreement drops below 90%, because a wrong face on a real animal is worse than no face.

377 of the 510 have a real photograph, embedded from the shelter's own platform rather than copied.

133 have none. I nearly wrote that up as dogs being overlooked, which would have been wrong. Their median wait is 20 days against 84 for the listed ones, so most of them are simply recent arrivals. Texas shelters hold a stray for a period before it can be offered for adoption, set by local ordinance rather than by state law, and that is the likeliest explanation for the gap. I cannot verify it dog by dog from public data, so I am not going to claim it as more than the obvious reading. But the unlisted share never drops below about a sixth at any length of stay, and 33 dogs have passed 100 days without appearing publicly at all. Pancho is one of them, which is why the biggest frame on the page is empty.

For those 133 I generated one illustration per breed group and used it as a CSS mask, so the alpha channel carries the drawing while the fill comes from the coat the shelter recorded. A black pit bull and a white Great Pyrenees stay visibly different animals. They illustrate a breed type, never an individual: generating a portrait of a specific dog nobody has photographed would be inventing evidence about a real animal, and the "no photograph on file" caption stays on every one.

Giving them a voice

Each of the longest-waiting dogs reads its own record aloud, and every clip opens with a real generated sound for that breed group: a mournful howl for the hounds, a husky's howl for the spitz breeds, a tiny yip for the toy dogs, a single deep woof for the guardians.

Nothing any dog says is invented. Every clause maps to a column:

They called me Pancho. I'm a white Cairn Terrier. I was picked up as a stray on May 23, 2025. That was 448 days ago, more than a year. 99.7 percent of dogs like me were already home by now. The usual wait is 8 days. Nobody has come for me yet.

The clips are recordings made on 2026-08-15, so a day count spoken aloud can sit a day behind the board, which recomputes on every load.

Name, coat, breed, intake reason, intake date, elapsed days, cohort percentile, cohort median. Eight fields, no biography, no "loves long walks". The phrasing varies between dogs but is selected by a hash of the animal ID rather than randomly, so re-running produces byte-identical scripts.

The pit bulls deliberately got the warmest, deepest voice available, because 51 of the dogs without photographs are pit bulls and a growling read would reinforce the exact assumption the other 99,916 records spend this whole page dismantling.

A straight top-16 by wait length turned out to be thirteen pit bulls, which meant no howl or yip would ever have played anywhere, so the generator tops up with the longest waiter from every breed group the top-16 missed. Twenty-three clips, all ten groups.

Things I had to get right, and four I got wrong first

Medians, not averages. Length of stay is heavily right-skewed. The mean wait for a bully-type dog is 66 days against a median of 28, because a handful of dogs stay for years. Every headline number here is a median.

The controlled table was wrong the first time. It required only 30 adoptions per cell, and reported that coat color moved the wait by 28 days within bully-type dogs, which would have undercut the entire finding. The top and bottom of that table were Yellow Brindle at n=35 and Gray at n=62. Two thin cells were setting the whole spread. At a floor of 250 the same table shows 7.5 days.

15 of the dogs on my first board had arrived dead. Animals recorded dead on intake never get an outcome row, so the anti-join that finds waiting dogs finds them too, and there they were on a page captioned nobody has come for them yet. Filtering them took the count from 531 to 516.

And one more after that. Princess has two intake rows a day apart with no outcome between them, so she was on the board twice. The anti-join emits one row per intake, not per dog. Deduplicating by animal id took it to 515.

The charts drew nothing at all for a while. Both panels rendered a bar of identical length whatever the number said, because the fill was an inline <span> and inline elements silently ignore width. The comparison the whole page is built on was showing two identical rows.

Because the writeup kept drifting from the pipeline, there is now a factcheck.py that re-reads the data and asserts every number quoted in this post. It caught eight stale figures the first time I ran it.

Prize Categories

Snowflake and ElevenLabs.

Snowflake holds the corpus and answers every question in the piece, with the one judgement call isolated in a SQL function and a 102-check cross-examination against an independent Python implementation.

ElevenLabs gives 23 dogs a voice and gives each breed group its own animal, generated rather than sampled.

What this is not

This is one municipal shelter, and an atypical one. Austin Animal Center operates under a City of Austin mandate of a 95% live-release rate, so these waits are likely shorter than the national picture rather than longer.

Nothing here is causal. It shows which dogs wait, not why any individual adopter chose as they did.

Breed labels deserve a warning too. They are assigned by staff from appearance, and Olson et al. (2015) found that shelter staff called 52% of a sample of dogs pit bull-type while DNA put the figure at 21% (The Veterinary Journal 206: 197-202). So "bully-type" here does not mean a dog with pit bull ancestry. It means a dog Austin wrote down as a pit bull. For a question about who gets adopted that is arguably the better variable anyway, because the label on the kennel card is what an adopter actually reads.

"No outcome record" is also not identical to "in the building". Some of these dogs are in foster care, and the outcome feed lags.

Why I built it

The interesting thing about the black dog myth is not that it is wrong. It is that it is a kinder thing to believe. If dogs are passed over for the colour of their coat, that is a superstition, and superstitions can be argued away with a good photo and a hashtag.

The real pattern is not a superstition. People are avoiding a breed. 216 of the dogs in that shelter tonight are that breed, and the ones at the top of the board have been waiting since before last summer.

Pancho is not one of them. He is a small white terrier and he has been there 449 days, which is the part I cannot explain and did not try to.

When my mom brought that second dog home, one dog stopped waiting. I did not think about it in those terms at the time and I doubt she did either. This weekend I built the list of everyone still waiting, and it turns out to be 510 names long.

Live board: https://jonathansolvesproblems.github.io/still-here/
Code: https://github.com/JonathanSolvesProblems/still-here
Blog Post: https://jonathanandrei.com/blog/still-here-austin-shelter-black-dog-syndrome-99916-stays/
Challenge: DEV Weekend Challenge: Dog Days Edition
Data: Austin Animal Center open data, live intakes and live outcomes. No API key needed, so every number here is checkable.

If you are anywhere near Austin, the board is real and so are the dogs on it.

Passion is the one thing you are not supposed to be able to fake. So I built a machine that manufactures it.

JonathanSolvesProblems — Sun, 12 Jul 2026 01:52:27 +0000

This is a submission for Weekend Challenge: Passion Edition

What I Built

The prompt for this challenge was passion, so I took the most literal possible
run at it.

Every World Cup app ever made is built for people who already care. Fixtures,
scores, brackets, league tables, fantasy teams. Every one of them assumes you
turned up with a side. Nobody builds anything for the person who wants to care
and has nobody to care about, which is most of the planet: a few billion people
will watch this tournament, and the overwhelming majority of them have no dog in
any of it.

Pick Your Side is for them. You name any two nations. It goes and reads their
actual history, picks the one you were always meant to love, tells you why, and a
stadium announcer swears you in.

Two nations in. One side out, and a reason to mean it.

The interesting problem is that you cannot fake this with a nice adjective. If
the app tells you Ghana and Uruguay have a bitter history and the history is
invented, then the passion it hands you is counterfeit, and the moment you look
it up you will feel stupid and never open it again. Manufactured passion only
works if the thing it is built out of is true.

So the whole architecture is bent around that one constraint.

Demo

pick-your-side.vercel.app

Turn your sound on. Half of this app is audio.

Try Uruguay against Ghana. It will side with Ghana, and it will tell you why:
Luis Suarez's handball on the line in 2010, the penalty Asamoah Gyan hit off the
crossbar in the last minute, the first African side ever to stand that close to a
semi-final. It also knows Ghana beat them 2-0 in the group stage a few days ago,
and it still argues the wound has not closed.

Or try England against Germany, if you want to watch it side with the team
that has not won anything since 1966.

Here is the part I am proudest of. Every fact above came from a live search, and
the app will show you exactly which pages it read:

Code

JonathanSolvesProblems / pick-your-side

Pick Your Side

The World Cup is on and you do not have a team.

Every World Cup app ever built is for the people who already care. This one is for everybody else. Name any two nations. It reads their real history, picks the side you were always meant to love, and a stadium announcer swears you in.

Built for the DEV Weekend Challenge: Passion Edition.

How it works

The interesting part is that none of the history is invented.

1. Gemini researches, grounded in Google Search. The first call has the Google Search tool switched on. Gemini goes and finds the actual head to head record, the actual famous match, and where both sides actually stand in the tournament being played right now. It comes back with the pages it read and the searches it ran, and the app shows you both. Ask it about Morocco and…

View on GitHub

How I Built It

Gemini never gets to work from memory

Because of that constraint, it runs twice.

Call one goes and finds out. Google Search grounding is switched on, and
Gemini is told to report only what it can verify: every World Cup meeting between
the two nations with year and score, the single most famous match, what each side
has actually won, and where both of them stand in the tournament being played
right now.

const research = await ai.models.generateContent({
  model: "gemini-2.5-flash",
  contents: `Research ${a.name} and ${b.name} ... Be concise and factual.
    If they have rarely or never played each other, say that plainly
    instead of inventing a rivalry.`,
  config: { tools: [{ googleSearch: {} }] },
});

Call two writes the case, and it only ever sees the facts call one came back
with. It is held to a responseSchema, so the output is always the same shape:
a side, a verdict, the history, the stakes, one legendary moment, your reason, a
line you can share, and a script for the announcer.

const written = await ai.models.generateContent({
  model: "gemini-2.5-flash",
  contents: `...Here is what was just researched. Every fact you use must
    come from here. Do not add matches, scores or players that are not in it:
    <researched-facts>${facts}</researched-facts>`,
  config: {
    responseMimeType: "application/json",
    responseSchema: revealSchema,
  },
});

Why two calls, which is the bit that cost me an hour

I did not want two calls. I wanted one: grounded and schema'd together. The
Gemini docs say Gemini 3 supports exactly that, structured output combined with
Google Search.

On gemini-2.5-flash, asking for googleSearch and a responseSchema in the
same call does not throw an error. It quietly ignores the schema and hands
you back prose.

That is a genuinely nasty failure. Nothing fails, nothing warns, the call
succeeds, and then your UI does JSON.parse() on three paragraphs of essay. I
only caught it because I wrote a throwaway script to poke at the API surface
before I wrote any UI, and I printed the raw output instead of trusting the
status code. If I had trusted it, the reveal would have exploded live.

So: research first, then shape. Which turned out to be the better architecture
anyway, because splitting them meant the facts arrive with sources attached.

The model was thinking, and thinking was making it worse

The whole thing was taking twenty six seconds, which is a long time to look at a
loading screen. gemini-2.5-flash reasons before it answers unless you tell it
not to. I turned it off on both calls. Same model, same prompts, measured:

	grounded	written	total
thinking on	11.6s	14.7s	26.3s
thinking off	5.1s	1.0s	6.1s

Four times faster. And the answers got better, which I did not expect. Asked
for a verdict, thinking on, it reasoned its way to:

France ends Morocco's World Cup run

That is a news headline. It is not a reason to love anybody. Thinking off:

Unfinished business and a deeper wound

The first call is looking things up and the second is being asked to write.
Neither one is a reasoning problem, and reasoning at them cost me twenty seconds
and the only good line in the output.

config: {
  responseMimeType: "application/json",
  responseSchema: revealSchema,
  temperature: 1.0,
  thinkingConfig: { thinkingBudget: 0 },   // <- this
}

Showing the receipts

Because the grounded call comes back with grounding metadata, I know exactly
which pages Gemini read and which searches it ran. So the app shows you.

Verified. None of this was invented. Gemini ran 6 live searches and read 6
pages before it made the case.

Expand it and you get the real search strings and links to fifa.com, wikipedia,
fotmob, whatever it actually used. You can go check it. It is the difference
between a story and a fact, and it is the thing I would want if I were the one
being told who to love.

Here is what convinced me it was worth doing. I asked it about Morocco against
France, and it told me about the 2026 quarter final, a match played days ago.

"This was tragically repeated in the 2026 World Cup quarterfinal, with France
again winning 2-0."

No language model knows that from training. It went and looked.

Telling it to pick the loser

The instruction that made the biggest difference to how the thing feels:

Choose the side with the better story for a newcomer: the deeper wound, the
longer wait, the thing still unfinished. Do not default to the more famous or
more successful nation.

Without that line it picks Brazil, France, Germany, every time, because they are
the most written about. With it, it picks Morocco over France and argues for the
Atlas Lions. It picks the Netherlands over Senegal and leads with three lost
finals. That single sentence is the difference between an app that reports and an
app that has taste.

The voice

Gemini writes the swear-in. ElevenLabs performs it.

The reveal lands, the nation's colour floods the screen, and a voice comes in
over the top of it. It is the moment the whole thing exists for, and it does not
work on the page as text.

const stream = await client.textToSpeech.convert(VOICE, {
  text: `[shouting over a stadium crowd] ${script}`,
  modelId: "eleven_v3",
  outputFormat: "mp3_44100_128",
  voiceSettings: { stability: 0.35, similarityBoost: 0.75, style: 0.65 },
});

eleven_v3 takes inline audio tags, so [shouting over a stadium crowd] is
direction for the read, not words that get spoken. Low stability plus high style
is what stops it sounding like an audiobook.

And then I listened to it, and the problem was obvious. A man was shouting about
a stadium, in total silence. He sounded unhinged.

So ElevenLabs builds the stadium too. Their sound effects API takes a text
prompt the same way the voice does, and I asked it for two things: a restless
crowd that murmurs under the scouting screen while the app is thinking, and an
eruption for the instant the nation's name lands.

await el.textToSoundEffects.convert({
  text: "A packed football stadium erupting the instant a goal goes in. " +
        "A sudden enormous crowd roar, then it settles into a sustained wall " +
        "of cheering that slowly falls away. No music, no commentary.",
  durationSeconds: 10,
});

The crowd sits at a third of the volume and never competes with the announcer.
Both cues are generated once and committed, so they cost nothing and start
instantly. Sound is on by default, because a muted reveal is just a poster, and
the control to turn it off is on screen the entire time.

There are three layers under the voice, because I did not want a visitor to
arrive at a silent reveal:

live text to speech of the script Gemini just wrote for that exact matchup
if that fails or the free quota is spent, a pre-rendered stinger for that nation, which ships with the app
if both fail, silence, and the reveal is otherwise unharmed

Same matchup, same words, same audio, so it is cached and only the first visitor
to a given pairing costs anything.

The announcer kept turning up late

eleven_v3 is the expressive one. It also takes 4.4 seconds, so the nation's
name would slam onto the screen and then nothing would happen for four seconds
and then a voice would arrive, to an empty room. Worse, I had put the dramatic
pause after the download instead of measuring it from the start of the
reveal, so the network time and the pause stacked and the announcer was
arriving 5.1 seconds late. I only found that because I scripted a browser to
click through the live site and timestamp the moment the audio element actually
started playing, which is not something a screenshot will ever tell you.

There is also a trap in the audio tags. [shouting over a stadium crowd] is
direction, not dialogue, but only on v3. Every other model reads it out
loud. I nearly shipped an announcer who introduces himself by saying the words
"shouting over a stadium crowd".

So the live voice is eleven_flash_v2_5, which comes back in under a second and
lands on the beat, and the pre-rendered stingers stay on eleven_v3, where
latency does not exist because they are generated offline.

The colours were a lie

The nations carry their real kit colours. Germany's is #111111. New Zealand's
is #0A0A0A. The whole design floods a near-black page with the nation's
colour, so picking Germany flooded near-black with near-black and the giant word
GERMANY simply was not there.

Eight of the forty one nations failed to clear 4.5:1 against the background. The
fix was not to fake the colours: it was to keep the authentic one as the source
of truth and derive the painted one from it, lifting it toward white only as far
as it has to go to be legible. Brazil's yellow comes out untouched. Germany's
black comes out a graphite you can actually read.

The design has one idea

The landing page has no colour in it. Near black, white type, a faint green glow
where the pitch would be. The only colour anywhere is a slow ribbon of all 41
nations drifting past the bottom, every side you could end up on, none of them
yours.

Then you pick, and the reveal floods the entire screen in your nation's colours.

That is the whole visual argument, and it is the product in one gesture: you have
nothing, and then you have something. Everything on the reveal is driven off the
chosen nation's real kit colours through CSS custom properties, so Morocco is
red, the Netherlands is orange, Argentina is that pale sky blue.

Flags are images rather than emoji, incidentally, because Windows does not render
flag emoji at all. It falls back to letter pairs. A judge on a Windows laptop
would have seen "AR" where Argentina's flag should be.

Prize Categories

Best use of Google AI. Gemini is the entire product, not a feature of it. It
runs twice: once grounded in Google Search to establish real, current, checkable
facts, and once under a forced responseSchema to turn those facts into an
argument. The app shows you the pages it read. It knows results from a tournament
that is still being played.

Best use of ElevenLabs. The swear-in is the emotional payoff of the whole
app, and it is built out of two ElevenLabs APIs. Text to speech is the
announcer: Gemini writes the words for that exact matchup, ElevenLabs is the
voice that makes them land, timed to arrive just behind the nation's name.
Sound effects are the stadium he is shouting into: a restless crowd while the
app is thinking, an eruption when the verdict drops. Turn your sound on.

Keeping it standing

The Google AI Studio free tier caps a project at a few hundred requests a
day, across every visitor combined. Two calls per reveal means this app could
serve about 125 people a day in total before handing everyone else an error. Fine
for building. Useless for being read.

So two things. The app runs on Vertex AI, which needs a billing account and
therefore carries real quota. And the well known matchups are generated ahead of
time by the same grounded pipeline, sources and all, and committed to the repo.
Those answer in half a second and cost nothing. They are cached, not faked.

When the budget does run out, the failure hands you a matchup that always works
instead of a dead end. I would rather you get a team from a slightly stale cache
than a stack trace.

What I did not solve

The nations list is curated to 41 sides, so you cannot pick your local club. A
matchup nobody has asked for before takes about twelve seconds, which I dressed
up as a scouting sequence rather than fixed. And the "what is at stake" text goes
stale six hours after it is written, which is a strange thing to have to think
about, and only a problem because the tournament is still being played while you
read this.

One last thing

I should probably admit that I am the target user.

The World Cup is being played in my country. Everyone I know has lost their mind
over it, and for the whole tournament I have been standing in the middle of that
with nothing: no nation, no shirt, no grudge, nobody to shout at. I did not build
this as a demo of an API. I built it because I wanted in and could not find the
door.

I pointed it at Uruguay and Ghana, because I did not know anything about either
of them.

It gave me Ghana.

I wrote up the longer version of the build, including the two Gemini traps that
nearly shipped, on my own site.

Built by Jonathan Andrei.

I built an AI agent that runs a local business's weekly marketing (Next.js + Gemini)

JonathanSolvesProblems — Sat, 11 Jul 2026 13:59:24 +0000

For the last couple of weeks I've been building Bloom, an AI marketing agent for local businesses like cafes, salons, and gyms. You set it up once, and every week an agent decides what to feature, writes the content in your brand voice, checks its own work, and (on the paid tier) emails your newsletter to your subscribers. On its own.

It's an early work in progress and I'm sharing it to get honest feedback.

90-second demo: https://www.youtube.com/watch?v=huHCDcUhIGM

The problem

Most local owners get under an hour a day for marketing, so it slips, and posting irregularly quietly costs them reach. It's a time-and-consistency problem, not a talent one. I wanted to build the thing that just never skips a week.

What it does

You enter your business once (type, city, brand voice). Then every Monday a scheduled agent runs with no human trigger and:

decides the week's angle and promotion
writes 3 social posts and an email newsletter in your voice
scores its own draft 0-100 and rewrites it if it falls below the bar
on the Pro tier, emails the newsletter to your subscribers from a verified domain

Every decision is logged to a public activity feed, so you can actually watch it work.

The parts that were actually interesting to build

The self-QA gate is real, not decorative. After generating, a second Gemini call reviews the draft and scores it. Below the threshold, the agent rewrites once and keeps the better attempt. Making this reliable meant forcing a JSON response schema, because Gemini would occasionally return an array instead of an object and silently break the gate.
Structured generation via Vertex AI. Content is Gemini 2.5 Flash through Vertex AI with a forced response schema, so the output is always a clean object.
Idempotent weekly delivery. The sender claims each send atomically, so a newsletter can never go out twice even if two workers fire the same Monday.
Runs on a plain Docker/Traefik box as a standalone Next.js server, with a cron sidecar driving the weekly run.

Stack: Next.js, TypeScript, Gemini 2.5 Flash (Vertex AI), Prisma + Neon, Stripe, Resend, Docker + Traefik.

Where it's at (honestly)

It's live. I've run a real payment through it and had it generate and deliver a real newsletter end to end. But it has basically no real users yet, which is exactly why I'm posting. I'd rather hear what's wrong now.

Try it, and tell me what's missing

Free preview (no card, about a minute): https://bloom.jonathanandrei.com

I'd genuinely love feedback on:

Would you, or a local business you know, actually use this?
Does the generated content look good enough to post as-is?
What would need to be true before you'd pay for it?

Built for the Build with Gemini XPRIZE hackathon. Happy to answer anything in the comments.