Weissman Check

Inspiration

If you've watched Silicon Valley, you remember the Weissman score. While watching it, I thought: why not bring it to reality? So I did, and building it showed me why a single score can't tell a developer what to actually ship. Most of us default to gzip, or pick whatever makes the file smallest. But the smallest file isn't always the best choice.

What it does

Drop in a file (or pick a sample) and Weissman Check runs six real lossless compressors, gzip, brotli, zstd, lz4, xz and bzip2, each at a fast and a strong setting on it, streaming each result live into a 12-segment progress bar.

It then recommends the one that reaches a user fastest at an assumed 20 Mbit/s:

• Static (compress once): transfer + decompression time
• Dynamic (compress on every request): compression + transfer + decompression time

Flip the toggle and the winner can change: a strong compressor that wins for static files can lose for dynamic ones, because its slow compression is paid on every request. Near-ties are called out, tiny files get "Too small to matter", and already-compressed files (zip, png, pdf…) get "Ship it as is". Only gzip, brotli, and zstd work in browsers, so the banner also names the best browser-supported pick.

Results come as a scorecard of gauges (time to user, space saved, decompression speed, your file's entropy, Weissman score), a delivery-time chart showing where the time goes, and a full table with real downloadable files. A replay card shows how LZ-style compressors see your file by highlighting repeated strings.

And yes, the Weissman score:

$$ W = \frac{r}{\bar r} \cdot \frac{\ln \bar T}{\ln T} $$

with a "break it" control: switch the time unit from milliseconds to seconds and the ranking reshuffles, with scores turning "flagged" or "undefined".

How I built it

I planned first with the Devpost Learn Skill Pack (scope → PRD → spec), where the agent interviewed me and I made the decisions. Then I built it in small, verified slices with Claude Code, with hands-on checkpoints where my feedback reshaped the product. A FastAPI backend runs the real compressor libraries and streams each result over Server-Sent Events to a React + TypeScript + Tailwind frontend. All the maths (recommendation and Weissman) lives in one place in Python and is covered by pytest; the gauges and chart are hand-built SVG and plain elements, no chart library.

Challenges I ran into

• Real compressors are black boxes that finish in milliseconds, so the visualization had to be an honest, labelled replay rather than fake "live internals".
• Timings on small files are noisy, so I used medians of repeated runs, a near-tie rule, and a "too small to matter" state so the app never crowns a winner by noise.
• The Weissman formula breaks with sub-second times (negative or zero logarithms), so those cases are shown as "undefined" or "flagged" with an explanation, never NaN.
• Strong settings are slow on big files: brotli at quality 11 took about 86 seconds on a 24 MB file.
• My first flat design felt too plain, so I reworked it into a bright retro file-archiver look.

Accomplishments that I'm proud of

• Every number comes from real compressors running on your actual file.
• The static/dynamic flip shows on real data that the smallest file isn't always the right one to ship.
• 50 passing tests, including a check that a real sample actually flips the winner.
• The whole results view fits on one screen without scrolling.
• A plan-first build: the scope, PRD, and spec were written and approved before any code.

What I learned

The best compressor isn't the one that makes the smallest file. It's the one that gets your file to your users fastest, and that depends on whether you compress once or on every request. I also learned that letting the agent interview me before building kept the project focused.

What's next for Weissman Check

• Lossy images and video with quality metrics like SSIMULACRA2, VMAF, and BD-Rate, plus 3D models
• A network-speed selector instead of a fixed 20 Mbit/s
• A deployed version so anyone can try it without installing it
• Per-compressor visualizations (Huffman trees, BWT, and more)

Built With

• brotli
• bzip2
• claude-code
• fastapi
• gzip
• lz4
• motion
• pnpm
• pydantic
• pytest
• python
• radix-ui
• react
• ruff
• server-sent-events
• svg
• tailwindcss
• typescript
• uv
• uvicorn
• vite
• xz
• zstd