Skip to content

CONCEPT Cited by 1 source

Product-market fit

Definition

Product-market fit (PMF) — the well-known startup term for the state in which a product has found a customer segment that actively wants it and will pull it from the company, rather than the company pushing it. This wiki page is a touchpoint, not an exposition of the term itself — the interesting wiki content is how specific engineering blogs (Fly.io, 2025-02-14, in particular) frame course-correcting when PMF is absent or partial, and how that framing interacts with the distributed-systems / infrastructure bets this wiki catalogues.

Canonical wiki statement

Fly.io, 2025-02-14, on the GPU bet:

A very useful way to look at a startup is that it's a race to learn stuff. So, what's our report card? … GPUs were a test of a Fly.io company credo: as we think about core features, we design for 10,000 developers, not for 5-6. It took a minute, but the credo wins here: GPU workloads for the 10,001st developer are a niche thing.

(Source: sources/2025-02-14-flyio-we-were-wrong-about-gpus)

Four working framings in Fly.io's post

  1. "A race to learn stuff." Startups are evaluated on how fast they reduce uncertainty about what works. Each bet is a learning event; the report-card is "what did we learn, measured against what we spent."
  2. "Design for 10,000 developers." PMF is measured by how many developers a feature would pull, not how powerful the feature is for a small segment. The GPU bet was 5-6- developer-shaped (serious-AI customers who want SXM H100 clusters); Fly.io designed for 10,000 and the gap showed up.
  3. "Being wrong is usually how we figure out the right answers." The canonical quote: "We started this company building a Javascript runtime for edge computing. We learned that our customers didn't want a new Javascript runtime; they just wanted their native code to work. We shipped containers, and no convincing was needed. We were wrong about Javascript edge functions, and I think we were wrong about GPUs. That's usually how we figure out the right answers: by being wrong about a lot of stuff."
  4. "Asset-backed bets absorb more wrongness." See concepts/asset-backed-bet. The GPU bet was wrong, but the hardware asset recovers a portion of the spend on liquidation. Fly.io's comfort with big bets correlates with the tradability of the assets acquired.

Operational signals of "not PMF"

Fly.io's 2024-08-15 + 2025-02-14 posts enumerate them:

  • Customer-usage data surprised you. (2024-08-15: "the A10 is the most popular by a wide margin" — opposite of the product team's intuition.)
  • A feature you shipped isn't what developers reach for. (2025-02-14: "when a software developer shipping an app comes looking for a way for their app to deliver prompts to an LLM, you can't just give them a GPU.")
  • Customers keep routing around the product instead of through it. (Developers shipping on AWS outsource GPU to specialist clouds, pay egress — the Fly.io GPU offer doesn't get queried.)
  • No insurgent-competitive wedge. (Insurgent can't out-execute OpenAI / Anthropic on tokens-per-second; see concepts/insurgent-cloud-constraints.)

Course-correction shapes

Fly.io's two explicit course-corrections disclosed on the blog:

  • 2022 → 2024 JavaScript edge runtime → containers. Shipped a JS runtime, learned developers wanted containers, shipped containers, "no convincing was needed".
  • 2022 → 2025 GPU Machines → retrenchment. Shipped GPU Fly Machines, learned developers wanted LLM APIs instead, scaled back forward investment but kept existing customers (see patterns/platform-retrenchment-without-customer-abandonment).

Both follow the same shape: ship, observe usage, accept the customer's verdict, redirect investment without abandoning customers already on the shipped path.

Why this matters for the wiki

Most wiki sources catalogue architectures that worked. Fly.io's 2025-02 posts catalogue an architecture that didn't achieve PMF despite working technically. The distinction is load-bearing: systems-design correctness is a necessary but insufficient condition for PMF. The GPU-Machine product is, by the post's own admission, technically well-shaped — inference locality pattern works as designed; the L40S customer segment is happy. But technical correctness didn't propagate into demand at the 10,000-developer scale.

Caveats

  • PMF is not binary. Fly.io's GPU product has some fit (L40S customers) but not core-business-driving fit.
  • Timing. The post is 2025-02; the frontier-model / tokens-per-second / closed-API concentration might be a moment, not a permanent state. Course-correction decisions made on this state of demand may be re-examined later.
  • "Being wrong a lot" is a sampling claim, not a recommendation to be profligate. Fly.io's tradable-asset posture is what makes the sampling affordable; a SaaS startup without asset-backing can't be wrong as many times.
  • Most interesting wiki content is the mechanism, not the PMF claim itself. How you course-correct, how you scale back without breaking customers, how you frame the asset-backing of the bet — those are the wiki-transferable pieces.

Seen in (wiki)

Last updated · 200 distilled / 1,178 read