Back to Blog
January 27, 20263 min read

Check Model-Market Fit First

Before you interview a single user, test whether any model can actually do the task reliably. A simple checkpoint that would have saved a lot of dead prototypes.

Every AI product that dies in production dies the same way: the demo was great. The prototype handled the happy path in front of an audience, the roadmap got approved, and six months later the team quietly discovered that the model can't do the task reliably enough to charge money for it.

Nicolas Bustamante gave this failure a name this week, and I think it deserves to stick: model-market fit. Before product-market fit — before user interviews, before market sizing — an AI product has to clear a more basic bar: can the underlying model actually perform the required task, consistently, on real inputs? It sounds obvious written down. It's skipped constantly, because the standard product playbook starts with the customer, and with AI products the customer isn't the first risk. The capability is.

The practical version: build task-specific evaluations before you build the product. Not general benchmarks — those tell you a model is impressive, not that it can do your thing. A few hundred real examples of your actual task, scored honestly, will tell you in a week what a failed launch would tell you in a year. It also changes how you shop for models: vendor comparisons become "run our eval," which is a much shorter conversation.

Apple, of all companies, spent this week demonstrating the same principle at maximum scale. Their AI strategy restructured under Craig Federighi, with external models now powering Siri improvements — a genuine retreat from the build-everything-internally playbook that defines the company. Read one way it's a stumble; read more usefully, it's an honest build-versus-buy call. AI moves too fast for their integrated approach, they measured the gap, and they bought. If the most resource-rich company on earth can conclude its in-house capability doesn't fit the task, your team can too, without shame. The differentiation moves to what you build on top — integration, product, experience — which was probably where your advantage lived anyway.

A smaller thread I enjoyed: the Python GIL debate resurfaced, asking why multi-core parallelism remains broken and whether it even matters. As someone who spends his days in .NET, where async/await and real threading have been unremarkable for years, the discussion is a good reminder that platform decisions are twenty-year decisions. Nobody choosing Python for a script in 2010 was thinking about core counts in 2026.

The shared moral, from Apple's pivot down to your next prototype: measure the capability before you commit to the story. Enthusiasm is not an evaluation.

Sources