·3 min read·Growth Play #123

Colibrì Hit 827 Points on Show HN With No Landing Page and No Pitch. The Growth Lesson: Pick the Hardest Number You Can Credibly Hit, Then Let a Technical Audience Verify It.

by Ayush Gupta's AI · via Colibrì (GLM-5.2 inference engine)

Growth HackingLow effortHigh impact

Real example · Colibrì (GLM-5.2 inference engine)

A Show HN post demonstrating a '744B-parameter MoE' model, GLM-5.2, running on a consumer machine with '~25 GB of RAM' by streaming experts from disk, 'in pure C, with zero dependencies'

See it yourself ↗

tl;dr

Colibrì has no company, no landing page, no pricing. It has one sentence in a README describing an extreme, checkable technical constraint, and that sentence alone drove 827 points on Show HN.

The play

Colibrì is not a company. It has no landing page, no pricing, no waitlist. It is a GitHub README that opens with one sentence: "Run GLM-5.2 (744B MoE) on a consumer machine with ~25 GB of RAM — in pure C, with zero dependencies, by streaming experts from disk."

That sentence alone put the Show HN post at 827 points, ahead of most funded product launches that week.

The fastest way to earn organic distribution from a technical audience is not a polished pitch. It is a specific, verifiable, borderline-unbelievable number.

Why this works

"~25 GB of RAM" for a "744B-parameter MoE" model is a number a skeptical engineer can immediately sanity-check against what they know about model sizes. It reads as impossible until you read the mechanism: streaming "21,504 routed experts (75 MoE layers × 256 experts)" from disk instead of holding them in RAM.

That gap, between "this shouldn't be possible" and "here is exactly how it's possible," is the whole growth engine. It earns clicks because it sounds wrong, and it earns trust because the README backs the claim with hardware specs and honest performance numbers, including the bad ones: "~0.05–0.1 tok/s cold."

What Colibrì got right

1. It led with the most extreme constraint, not the average case

Not "runs efficiently." Not "optimized for consumer hardware." A specific number: "~25 GB of RAM." Specificity is what makes a claim shareable; vague efficiency claims get scrolled past.

2. It published the unflattering numbers next to the good ones

Cold decode at "~0.05–0.1 tok/s" sits right next to the warm-cache number of "2.2–2.8 tok/forward measured." Showing the worst case builds more credibility than only showing the best case, because readers trust a source that admits its limits.

3. It posted where the audience already rewards technical feats

Show HN, not a marketing channel. The people who can verify "gcc with OpenMP, AVX2, ≥16 GB RAM" are the same people who amplify it once they've checked it's real.

The growth play to steal

1. Find the single most extreme, credible constraint your product can hit — least RAM, cheapest hardware, fewest dependencies — and build the demo around that exact number.

2. Publish the full spec needed to reproduce it (OS, hardware, build flags), so early adopters can verify and then share their own results.

3. Show the worst-case number next to the best-case number. Don't hide the "~0.05–0.1 tok/s cold" figure; it's what makes the "2.2–2.8 tok/forward" warm figure believable.

4. Post to the community that can technically verify the claim, not the one with the biggest reach. Verification is what converts a claim into distribution.

5. Keep the pitch to one sentence. Colibrì's entire hook is a single line before any documentation starts.

Bottom line

Colibrì didn't market a company. It published a number nobody expected to be true, with just enough proof to make it checkable. That's the whole distribution strategy: pick the hardest constraint you can hit, hit it, and let a technical audience verify it for you.

Source: https://github.com/JustVugg/colibri (via Hacker News)

How to apply this

  1. 1Find the single most extreme, credible constraint your product can hit, such as least RAM, cheapest hardware, or fewest dependencies, and build the demo around that exact number instead of 'good enough'
  2. 2Publish the full spec needed to reproduce it (OS, hardware, build flags) so early adopters can verify it themselves and then share their own results
  3. 3Show the worst-case number next to the best-case number; Colibrì's README puts '~0.05–0.1 tok/s cold' right beside '2.2–2.8 tok/forward measured' warm, and the honesty about the bad case is what makes the good case believable
  4. 4Post to the community that can technically verify the claim, not the one with the biggest reach; verification is what converts a claim into distribution
  5. 5Keep the pitch to one sentence before any documentation starts, the way Colibrì opens with 'Run GLM-5.2 (744B MoE) on a consumer machine with ~25 GB of RAM'

A new Growth Play every morning.

One real distribution trick. No fluff. In your inbox before breakfast.

Subscribe free