How We Decide What Not to Build
Every product team says it prioritizes ruthlessly. Most don't — or they prioritize within a backlog that's already too large, which is a different thing.
The more interesting discipline is deciding what doesn't belong in the product at all. Not what to build later, but what to explicitly exclude — what the product won't do, even when users ask for it, even when it seems like a natural extension, even when it would be straightforward to build.
Here's how we think about it.
We start from the constraint the product is solving
Alpha Deal addresses a specific problem: affordable housing development teams don't have the capacity to evaluate as many sites as their pipeline requires, because the work of early-stage feasibility is time-intensive and depends heavily on senior staff expertise.
This constraint has a shape. It lives at the pre-development stage. It involves program eligibility, zoning, capital stack modeling, and competitive positioning. It affects teams doing site screening and early feasibility work.
Anything outside that shape is a candidate for explicit exclusion. Not because it's unimportant, but because solving it would require us to be a different product for a different problem.
The most important things we've chosen not to build
Full underwriting. Our users do full underwriting after a site clears our screening. We deliberately don't try to replicate that process — because it requires data and deal-specific inputs that aren't available at the screening stage, and because attempting to replicate it would create a product that's either too slow for screening or not accurate enough for underwriting. We're a better product for stopping at feasibility signal rather than extending into full model.
Compliance tracking. LIHTC compliance over the 30-year affordability period is a significant operational function. It's also a completely different product for a completely different stage of the asset lifecycle. We're not a compliance tool. We're a pre-development tool. The overlap is minimal.
Market-rate development features. We build for affordable housing. Market-rate developers have different program logic, different competitive dynamics, and different feasibility drivers. Expanding to serve them would require compromising the depth of our affordable housing focus. We haven't done it.
Why this is harder than it sounds
Every feature we've chosen not to build has come up in user conversations. Users ask for things outside our scope because their problems extend beyond our product — which is natural. The discipline is recognizing when a request reflects a genuine gap in our product and when it reflects a need that belongs elsewhere.
The test we apply: does this make the pre-development stage faster and more accurate for affordable housing development teams? If the answer is yes, it belongs in the product. If the answer is "it would be useful to our users in a different context," it probably doesn't.
Being explicit about what the product won't do — with users and internally — is part of what keeps the product coherent. A product that tries to solve every problem a user has ends up solving none of them well.
We're looking for engineers and product people who find the discipline of focused product design as interesting as the work of building it. If that resonates, we'd like to talk.