Why We Are Building a Workflow Engine, Not Just a Data Feed
There's a version of proptech that's primarily a data business: aggregate information about properties, markets, or transactions; clean and structure it; sell access to it. This model has produced some valuable companies and some large outcomes.
There's a different version that's primarily a workflow business: understand how practitioners actually make decisions; build the tools that support those decisions at the point they happen; generate data as a byproduct of being embedded in the workflow rather than as the primary product.
We're building the second thing. Not because data businesses are bad, but because we think the more durable opportunity in affordable housing development is to be where the work actually gets done — not just to provide information that feeds into work that happens elsewhere.
The data business model and its limits
A pure data business in real estate looks something like this: accumulate property records, transaction data, market statistics, and programmatic information; license access to developers, investors, and analysts who use it to inform their decisions. The value proposition is information that's hard to compile yourself.
This model has real value and real precedent. There are successful data businesses serving commercial real estate, residential, and increasingly the affordable housing sector.
The limits are also real:
Data commoditizes. Information that's genuinely proprietary and hard to replicate is valuable. Information that's derived from public sources — parcel data, zoning records, income limits, subsidy program parameters — faces constant competitive pressure as more players compile and clean the same underlying sources. The data moat erodes over time unless it's being continuously defended.
Data without workflow has limited switching costs. If a developer uses a data product to inform decisions but makes those decisions elsewhere — in spreadsheets, in conversations, in separate tools — switching away from the data product doesn't disrupt the workflow. The cost of switching is low, which means pricing power is limited.
Data doesn't capture what practitioners actually know. The most valuable knowledge in affordable housing development isn't in any database. It's in the heads of practitioners who've done dozens of deals, know which soft loan programs actually close on schedule, understand which markets have favorable QAP environments, and can read a site's feasibility signals from experience. A data product that doesn't capture and organize that kind of knowledge is providing a fraction of what practitioners actually need.
What a workflow engine looks like instead
A workflow engine starts from a different question: not "what information do practitioners need?" but "how do practitioners actually work, and where does the workflow break down?"
For affordable housing developers, the workflow breakdown tends to happen at the same places: early-stage site evaluation, where information is fragmented and manual research consumes senior staff time; capital stack scenario modeling, where the combinatorial complexity of program interactions is hard to hold in a spreadsheet; and pipeline management, where tracking multiple deals at different stages with different decision points creates coordination overhead that grows with volume.
Building into those breakdowns means building tools that practitioners use to do their actual work — not tools that provide inputs to work they do elsewhere. When the work happens in the product, several things change:
Usage generates better data. The decisions practitioners make in the workflow — which sites they advance, which capital stack structures they pursue, which deals close and which don't — create a dataset that's more valuable than assembled public records. Not because it's larger, but because it reflects real decisions made by real practitioners with real stakes.
Switching costs compound. When the workflow lives in the product — when evaluation history, capital stack models, deal notes, and pipeline status are all in one place — switching away means losing the accumulated work product, not just access to a data feed. That's a fundamentally different switching cost.
The product learns. Data generated from real workflows can be used to improve the tools that practitioners use — better feasibility signals, more accurate program eligibility assessments, pattern recognition from comparable deals. This creates a feedback loop that pure data products don't have access to.
Why this matters more in affordable housing
In commercial real estate broadly, data businesses have worked because transaction volume is high, data is somewhat standardized, and the users are sophisticated institutions with clear information needs.
Affordable housing is different. Transaction volume is lower and deal complexity is higher. The relevant data — subsidy program parameters, QAP criteria, local soft loan availability, compliance requirements — is fragmented, inconsistently structured, and changes regularly. The users are mission-driven practitioners who are skeptical of tools that don't understand the complexity of the work they do.
In this context, a data product that provides information without context — without the workflow that makes that information actionable for a specific practitioner at a specific decision point — adds limited value. The practitioner still has to do the work of applying the information to the decision.
A workflow engine that's embedded in how the decision actually gets made — that surfaces the relevant information at the right moment, helps the practitioner model the implications, and records the outcome in a way that's useful for future decisions — is a fundamentally different kind of product. And in a market where practitioners are time-constrained, skeptical of tech, and doing genuinely complex work, it's the kind of product that earns real adoption.
The data moat as a byproduct
This framing suggests that the most defensible data moat in affordable housing isn't built by scraping public records faster than competitors. It's built by being the system of record for how deals get evaluated and advanced.
The data that accumulates from being embedded in practitioners' workflows — which sites were evaluated and why they did or didn't advance, which capital stack structures were modeled and which closed, which market conditions correlated with successful allocations — is data that no data aggregator can replicate. It exists only if you've earned your place in the workflow first.
That's a different path to a data moat. It's harder at the beginning, because you have to build something practitioners actually use before you can capture the data. But it's more defensible at scale, because the moat is built from usage rather than from sources that anyone can access.
Alpha Deal is building the workflow engine for affordable housing pre-development — helping development teams work more efficiently at the point where decisions are actually made.