I didn’t set out to start a blog. I set out to stop wasting evenings.
I’m Dan Kowalski. I live in Pittsburgh with my wife Megan, our five-year-old daughter Nora, and a cat named Biscuit who has strong opinions about GPU fan noise. Most nights, after Nora goes to bed, I have a limited window to run tests. That window is not generous. It does not expand just because a new model dropped or someone on Discord posted a “mind-blowing” result with zero settings attached.
For months I did what a lot of people do. I chased impressive clips. I opened workflow files that looked promising. I tried to reverse-engineer settings from screenshots. I ran things that almost worked, then fell apart on the next seed, the next resolution, or the next time I restarted ComfyUI. The results looked great for eleven frames. Or they looked great until the character changed clothes. Or they looked great until the VAE decided to have a bad night.
At some point I realized I was collecting highlights, not workflows.
That is why Wan Workbench exists.
The Problem With Prompt Galleries
Prompt galleries are useful. They show what is possible. They give people ideas. They make the technology feel exciting. I look at them too.
But they have a structural problem: they optimize for the final image or the final clip, not for the path that produced it. When the path is missing or incomplete, the result becomes a one-off event instead of something another person can actually run.
I kept running into the same pattern:
A beautiful 720p clip with no seed, no sampler settings, no exact model versions, and no mention of VRAM usage.
A “low VRAM” claim that quietly assumed a specific offloading setup that was never documented.
A workflow JSON that loaded but produced different temporal behavior every time I touched the frame count.
Side-by-side comparisons that changed three variables at once and then declared a winner.
None of that is malicious. Most of it comes from people who are excited and moving fast. The trouble is that excitement without measurement does not travel well. If you cannot hand the exact conditions to someone else and get the same behavior, you do not have a workflow. You have a happy accident.
My signature line is not a slogan I invented for branding. It is a rule I started enforcing on myself:
If you can’t reproduce it, it’s not a workflow.
What “Reproducible” Actually Means on Consumer Hardware
Reproducibility is not the same thing as “I ran it once and it looked good.” On consumer hardware, it means something more specific.
It means I can tell you:
Exact model versions and file hashes when they matter
ComfyUI version and the relevant custom nodes
Seed, sampler, steps, CFG, resolution, frame count, and any frame interpolation settings
Which GPU I used, how much VRAM was free at the start, and what the peak usage looked like
Whether I used offloading, quantization, or both
What failed, how it failed, and whether the failure was consistent
I test primarily on a carefully maintained primary GPU and a used RTX 3090 that I bought secondhand, repaired, and turned into a dedicated test card. The 3090 is not glamorous. It is 24 GB of real-world constraints. It forces me to care about memory behavior instead of assuming unlimited headroom.
I do not run uncontrolled batches. I usually test one configuration at a time after Nora’s bedtime. That limitation has been useful. It keeps me honest. If a setup only works when I am babysitting it and restarting nodes every twenty minutes, I will say so.
The Four Questions Every Technical Post Here Tries to Answer
I use a simple editorial rule. Every major technical article should answer four questions:
What hardware and software were used?
What exactly was tested?
What failed or changed?
Can another reader reproduce it?
If I cannot answer the fourth one, the post is not finished. It might still be interesting as a progress note or a failure report, but it is not a completed workflow.
This is also why the site is organized the way it is. The Wan Bench is for controlled comparisons. ComfyUI Under the Hood is for node-level and dependency-level clarity. VRAM and Hardware Reality is for the ugly cost numbers. Failure Reports exist because the failures are usually more informative than the successes.
A Concrete Example From My Own Testing
Early on I spent a full weekend chasing temporal consistency. The subject was simple: a person walking toward camera in a plain room. The first renders looked promising. Then the clothing would shift color or style every few seconds. Sometimes the face would drift. Sometimes the background would start inventing new furniture.
I did the usual things. I blamed the prompt. I increased steps. I decreased steps. I changed the sampler. I tried different seeds. I added negative prompts that felt increasingly desperate.
None of it fixed the core issue.
What eventually helped was treating the problem as a measurement problem instead of a creative one. I fixed the seed. I fixed the resolution. I fixed the frame count. I logged VRAM at every major stage. I isolated the VAE. I compared the same prompt across two different loading configurations. After roughly twenty controlled runs, the pattern became clear: the instability was tightly coupled to how the VAE was being handled under memory pressure, not to the poetic quality of the prompt.
That session later became the basis for a Failure Report. The important part was not that I eventually got a cleaner clip. The important part was that I could write down the conditions under which the failure appeared and the conditions under which it mostly stopped. Another person with a similar GPU could start from the same place instead of starting from zero.
That is the difference between a gallery post and a workbench post.
Why I Am Not Building Another “Best Settings” List
I am wary of “best settings” posts. Settings are context-dependent. What works cleanly on a 4090 with plenty of headroom can fall apart on a 3090 the moment you push resolution or frame count. What looks stable at 480p can introduce new temporal artifacts at 720p. What feels fast with aggressive offloading can become a thermal and power-draw problem if you actually need to generate volume.
So instead of publishing a single blessed configuration, I am going to publish baselines, controlled comparisons, and failure evidence. A baseline is not a claim of perfection. It is a documented starting point with known behavior.
My first real baseline post will include the exact node graph, versions, seeds, and hardware notes so that someone else can load it and see the same starting behavior I saw. From there we can change one variable at a time and measure what actually moves.
That approach is slower than posting a highlight reel. It is also more useful if your goal is to ship something reliable rather than to collect likes.
Personal Constraints Shape the Method
I do not have a research lab. I have evenings, a secondhand test card, and a household that prefers the house not to sound like a small server farm. Biscuit has already registered formal complaints about fan curves. Megan has a low tolerance for me staring at logs past midnight when I have to be functional the next day. Nora does not care about temporal consistency; she cares about whether I am available to read books.
Those constraints force prioritization. I cannot afford to run fifty uncontrolled variations and then reverse-engineer which one worked. I have to decide what I am testing, lock the other variables, run the test, save the settings, and look at the failure modes directly.
That discipline is the entire point of this site.
What You Can Expect Here
You can expect exact settings when I claim a result. You can expect me to say when something is still unstable. You can expect side-by-side evidence instead of marketing language. You will not see me call a half-broken workflow “production-ready.” You will not see me hide the render times or the VRAM spikes.
You will see dry humor, mostly directed at my own mistakes. You will not see me dunk on readers who are still learning the stack. Everyone starts somewhere. The difference is whether we document the path or just the destination.
I will also publish workflow JSON files, configuration notes, and logs when they are useful. If a result only exists inside my head or inside a one-off session that I cannot recreate, it does not belong on the site as a finished workflow.
A Practical Suggestion If You Are Starting Out
If you are currently collecting impressive clips and feeling frustrated that you cannot get consistent results, try this for one week:
Pick one simple subject and one resolution.
Lock the seed.
Change only one variable per test.
Write down the full settings every time, even when the result is bad.
Save the failed outputs with the same care you save the good ones.
You will learn more from ten controlled failures than from fifty uncontrolled successes. The failures tell you where the system is brittle. The successes, without context, mostly tell you that you got lucky once.
Closing
Wan Workbench is not a gallery. It is a public lab notebook for one independent engineer who got tired of results that could not be repeated.
I will keep the voice straightforward. I will keep the measurements honest. I will keep the failures visible.
Run the test. Save the settings. Show the failure.
If you can’t reproduce it, it’s not a workflow.
That is the standard I am holding myself to. Everything else is just content.
