Composite, drawn from patterns across engagements, not one specific client.
Three platforms, all technically capable of doing what a founder I worked with needed. Feature comparisons weren't settling it, all three checked every box on the list. The decision had stalled for weeks, not from lack of information, from too much of it, none of it decisive.
Why the feature list wasn't the right lens
When three options all satisfy the stated requirements, the requirements list has stopped being useful, and continuing to compare against it just produces more ties. The actual decision needed a different question entirely, not "what can each one do," but "what does each one assume about how we'll grow."
The question that actually broke the tie
Which platform's pricing and architecture punishes us least if we're twice the size in two years. One option scaled its pricing in a way that would have quietly doubled costs disproportionate to growth. Another had a architecture that would require a full re-platform past a certain size, a predictable, known wall. The third scaled cleanly, with pricing and architecture both built for the growth curve the business was actually on.
None of that was visible in a feature-by-feature comparison. All of it was visible once the question shifted from "what can it do today" to "what happens as we grow."
What decided it, concretely
The platform whose docs and pricing were most transparent about scaling was chosen, not because it had more features, it had roughly the same set as the others, but because it was the one built with the least discomfort baked into growth.
The lesson, generalized
When multiple options tie on features, the tie itself is a signal to change the question, not to keep comparing lists more carefully. The right question at that point is almost always about growth, not capability, since capability was already established as roughly equal.