What a Good Pipeline Tracking System Looks Like for a Small Development Team
Affordable housing development teams spend a lot of time thinking about individual deals. They spend surprisingly little time thinking about how deals are tracked across the pipeline — which sites are at which stage, what the next decision point is for each one, and where things are most likely to stall.
For a small team running 10-20 sites in active evaluation at any given time, the pipeline tracking system is the difference between a team that consistently advances deals and one that loses things in the gaps between people's inboxes.
What a pipeline tracking system needs to do
The core function of a pipeline tracking system is to make the status of every site visible at a glance, without requiring anyone to ask. At a minimum it should answer:
- What sites are currently in evaluation, and at what stage?
- What's the next action required on each site, and who owns it?
- What's been screened and rejected, and why?
- What's advanced past initial screening and is in active development?
The last question — what's been rejected and why — is the most underrated. Teams that record why sites didn't advance build institutional knowledge about what doesn't work in their market. Teams that don't record rejections lose that knowledge and sometimes end up re-evaluating the same sites.
The stages that matter for affordable housing
Generic pipeline management frameworks don't map cleanly onto affordable housing development. The stages that matter are specific to the development workflow:
Initial identification — Site has been flagged as potentially worth looking at. No evaluation has been done.
First-pass screen — Basic program eligibility, density, and site conditions have been checked. Awaiting go/no-go decision to advance to deeper evaluation.
Active evaluation — Site has cleared the first-pass screen. Team is doing deeper feasibility work: zoning analysis, capital stack modeling, market study, soft debt conversations.
Under option / site control — Team has site control. Deal is in active pre-development: program applications, entitlement work, design, financing structure.
In financing — Deal is progressing through credit application, debt placement, or closing process.
Rejected — Site did not advance, with a documented reason.
Each stage transition should require a documented decision, not just a status change.
What to capture at each stage
The value of a pipeline system grows with the quality of what's recorded at each stage. The minimum useful data:
- Site address and basic characteristics (size, current use, current zoning)
- Date entered evaluation
- Program hypothesis (what program type is being evaluated)
- Key constraints identified (the one or two things that most affect feasibility)
- Next action and owner
- Date of last update
For rejected sites: the primary reason for rejection, and whether the rejection is permanent or time-dependent (a site that doesn't work today because of a land price expectation might work in two years if the seller's situation changes).
The discipline that makes it work
Pipeline systems fail not because they're poorly designed but because they stop being maintained. A system that requires manual updates at every stage depends on the team's discipline to update it consistently — which is difficult to sustain under workload pressure.
Two things help: making updates lightweight (the system should require minimal effort to keep current) and making the pipeline visible to leadership (when the pipeline review is a regular part of how the team operates, maintenance becomes a natural part of the workflow rather than an afterthought).
Alpha Deal helps development teams track sites from initial identification through active evaluation — keeping pipeline status visible and institutional knowledge intact.