The "Time to No" Metric: Why I Challenge Our Engineering Team to Help Users Kill Bad Deals in 30 Minutes
We have an internal metric we care about that doesn't appear in any of our investor updates: time to no.
Time to no is the average time it takes an affordable housing development team using Alpha Deal to reach a confident decision that a site isn't worth pursuing. We want it to be fast. Very fast. As close to 30 minutes as we can get for the sites that are genuinely not viable.
This metric might seem counterintuitive for a product team to optimize for — why would you want users to reach negative conclusions faster? The answer requires understanding the economics of affordable housing development pipeline management.
The pipeline math
Affordable housing development teams typically evaluate many more sites than they pursue. The ratio varies by team type and market, but a ratio of 10:1 — ten sites evaluated for every one that advances — is not unusual. Some teams run much higher ratios.
That means the majority of a development analyst's evaluation work ends in a no. That's not failure — it's how good acquisitions pipeline management works. The question is how efficiently the team can reach those nos and free up capacity for the sites that deserve more attention.
If a team can reach a confident no in 30 minutes instead of 3 days, they can evaluate ten times as many sites without adding staff. The sites that are genuinely viable get the same attention; the sites that aren't get found out faster and removed from the queue. The team's effective capacity multiplies without any change in headcount.
Why this is a product insight, not just a metric
The "time to no" framing shapes how we build the product in specific ways.
First, it means we front-load the deal-killers. Our interface is designed to surface the factors most likely to disqualify a site — program eligibility, basic density math, obvious site conditions flags — before anything else. We don't lead with the most interesting analysis; we lead with the analysis that ends the most screenings fastest.
Second, it means we're honest about negative signals. A product that buries or softens disqualifying signals to keep users engaged is optimizing for the wrong thing. Our users are professionals who need accurate information. A clear "this doesn't work because X" is more valuable to them than a dashboard that requires interpretation.
Third, it means we think carefully about the confidence attached to outputs. "This site probably doesn't qualify for 9% LIHTC in a competitive state" is a different signal than "this site is definitively ineligible." We try to represent the distinction accurately — not because we're hedging, but because the level of confidence matters for how a practitioner should act on the information.
The UX challenge this creates
Designing for fast negative decisions creates some interesting product tensions.
Users come to the product hoping a site will work. There's real psychological resistance to reaching a no — teams have often already spent some time on a site before bringing it into the tool, which means there's sunk cost investment in the possibility. A product that efficiently delivers bad news has to navigate that psychology without softening the signal.
We've found that the most effective approach is to lead with the specific reason, not the conclusion. "This site's estimated eligible basis doesn't support the equity needed for a deal of this size" lands differently than "this site doesn't pencil." The first is actionable — it tells the practitioner exactly what the constraint is and creates a natural question about whether there's a structural fix. The second is just disappointing.
Even when the answer is definitively no, the path to that no should be informative. The practitioner should understand why this site didn't work, which makes them faster and better at evaluating the next one.
What this metric reflects about our product philosophy
Behind the time-to-no metric is a product philosophy: we're not trying to make affordable housing development seem easier than it is. We're trying to give practitioners better information faster so their limited capacity gets concentrated where it matters.
That means building a product that's genuinely useful on the bad days — the days when a site the team was excited about turns out not to work — not just the days when the news is good. It means optimizing for trust over engagement, for accurate signal over impressive dashboards.
The metric we're most proud of isn't the time users spend in the product. It's the quality of the decisions they make with it.
We're building product that respects practitioners' time and earns their trust. If that's the kind of product work that motivates you, we'd like to talk.