Site Feasibility Software: How to Choose by Deal Stage

Earlier this year, one of the largest players in site feasibility software quietly split its flagship early-stage tool into two separate products. It went out as a routine release note, not a strategic reversal, and almost nobody outside the industry noticed, but it's a real signal. A company with effectively unlimited engineering resources spent years building one tool to handle "early-stage work," then concluded that early-stage work isn't one job. It's at least two, happening at different moments, to different people, under different kinds of pressure.

The vendor story is the smaller part. It's good evidence for something buyers already suspect but rarely act on: the category looks unified from the outside because it's sold under one label, but underneath it are different jobs.

That segmentation lines up with independent data on where development timelines, and the money at stake, really get decided.

Research from the Federal Reserve Bank of Atlanta by Chris Cunningham and Anthony Orlando, summarized by the Urban Institute, tracked two decades of multifamily projects through the Dodge Construction Network database. On average, 15.3 months pass between a project being announced and construction beginning. Construction itself takes 12.3 months. Planning runs three to four months longer than the building does, and the authors found those timelines becoming more systemic over time.

Most of the decisions that determine whether a project pencils get made during that longer stretch, when there's no building to look at and no drawings to mark up. Unit count, parking strategy, whether the site can absorb the density the pro forma assumes, whether a rezoning is worth the political risk. Every one of those gets settled before a design team is fully engaged, and every one is expensive to revisit later.

That's the window site feasibility software is competing for. The trouble is, the category has splintered into tools solving different problems, and most of them use the same handful of words to describe what they do. Teams go shopping, line up feature lists across products that were never built for the same job, pick the one with the most checkmarks, and then wonder why the tool that demoed beautifully is sitting unused six weeks later. Before comparing features, ask a narrower question: Which moment in the deal are you buying for?

Three Categories Hiding Under One Label

Search for site feasibility software and the results arrive undifferentiated. The category is loosely defined as anything that tests whether a parcel can support a proposed development, weighing zoning and setbacks against buildable area, floor area ratio, and the cost of putting something there. That definition is broad enough to cover products that share almost nothing, and underneath it sit three distinct categories, each optimized for a different moment.

The first is land acquisition intelligence. These tools answer the question you ask before you have a site at all: where should I be looking, and is this parcel worth a call. This is search and screening work, automated zoning interpretation, parcel discovery, and rough yield estimates across a large territory, built for a team trying to filter hundreds of parcels down to the handful worth a real look.

The second is deal-stage feasibility. This is the moment after a site is on the radar and before a design team is engaged, when someone has to decide whether to write a letter of intent. The work is quantitative and comparative: how many units fit, how much parking the code demands, what the earthwork looks like, whether the yield on cost clears the hurdle. This is where TestFit sits.

The third is schematic design. Here the deal is done and the question becomes what to build, in detail, with a team. The work shifts from screening and comparison to coordination and iteration, and it's a different job entirely from deciding whether to buy the land in the first place.

Three Functions Every Stage Depends On

Acquisition and deal-stage feasibility are distinct decisions made by distinct people, but both call on the same three functions, and neither one finishes before the other starts.

The first function is zoning and environmental analysis: what is this parcel entitled for, what does the code demand, what's in the ground, and what will the site plan have to work around. The second is geometric feasibility: given those constraints, what can physically fit here, and in what configuration. The third is financial modeling: given what fits, does it clear the hurdle.

In practice, these don't run in sequence, they run in a loop. A land team screening a parcel needs to know what it's zoned for and whether the site can physically carry what the pro forma assumes, which means they're already doing geometry before they have a deal. An underwriting team then amends the pro forma based on what the site will really produce, and tests whether that version still pencils, which means the geometry is still moving while the numbers are being set. A change to the parking ratio pushes the unit count, the unit count pushes the yield on cost, and a soft yield sends someone back to ask whether a different configuration recovers it.

Most tools in this space do one of the three functions well and hand you a spreadsheet for the other two. That's the gap, and it's the reason a tool can demo beautifully and still leave the loop running by hand.

Where Site Feasibility Software Works, and Where It Breaks

When the category matches the moment, these tools are good. A land team screening a hundred parcels a month gets enormous leverage from acquisition intelligence, because the job is filtering and the tool is a filter. A design team well into schematic design gets real value from a coordination-focused platform, because the job is coordination and the tool coordinates.

The failures are almost always mismatches, and they follow a pattern.

Buying a schematic design platform for deal screening produces beautiful output too slowly. The tool is built to develop an idea, not to kill ninety of them. By the time a team has modeled one scheme properly, the seller has taken another offer.

Buying acquisition intelligence for vertical development runs into the opposite problem. Yield logic tuned for horizontal subdivisions, where the output is lots and roads, doesn't transfer cleanly to a wrapped multifamily building with structured parking, or to an industrial box where trailer courts and truck maneuvering drive the whole layout. The screen is fast and the answer is directionally wrong.

Buying a tool that covers only one of the three functions is the quietest failure, because nothing visibly breaks. The zoning analysis is excellent. The massing holds up just as well. So does the pro forma. They just don't talk to each other, so every time one input moves, somebody re-exports, re-enters, and re-checks, and the loop that should take an afternoon takes a week.

One version of that last failure deserves its own paragraph, because it's hard to spot in a demo. Some tools treat zoning as information. They show you the district, the setbacks, the height limit, and the parking minimum, and leave it to you to apply them. Other tools treat zoning as rules the software has to obey when it generates a site plan. Vendor websites describe both the same way, usually as "zoning analysis," so the difference rarely shows up until the tool is in use. A tool that displays the zoning district is doing something different from a tool that enforces setbacks, height limits, and parking minimums as constraints on what it generates. The first is a map layer. The second changes what comes out. This is worth testing directly: ask what happens when the parcel is rezoned mid-evaluation, or when a setback changes. In a tool where zoning is a live input rather than a reference layer, the building comes back different.

How to Choose Site Feasibility Software Without a Feature Matrix

Five questions sort this faster than any comparison table.

Who is holding the mouse? A tool built for a land acquisitions analyst and a tool built for a project architect will both claim to do feasibility, and they'll feel completely different in the hands of the wrong person.

Where in the deal does it get used? Pre-letter of intent, entitlement, and schematic design are three different problems. Write down which one is costing you the most right now, and evaluate against that one.

Is code compliance a constraint or a display? Ask a vendor to change the parking ratio mid-demo and watch whether the building regenerates or whether a number just updates in a sidebar.

Does the output survive contact with an underwriter? A massing study that can't connect to a pro forma is an image. If someone on the deal team has to rebuild the numbers in a spreadsheet afterward, the tool has moved work rather than removed it.

How many of the three functions does it close? A tool that handles one of them and exports to the other two hasn't removed the loop, it's just documented it.

What Closing the Loop Looks Like

This is where the distinction between stages and functions stops being academic. A site with a difficult parcel geometry, a parking minimum that eats the yield, terrain that drives cut and fill volumes, and a pro forma that has to clear an investment committee on Thursday is several constraints resolving against each other at once, and the answer changes every time one of them moves.

TestFit is a deal-stage tool, and it was built for that specific moment. It does not try to cover all three stages. It covers all three functions inside the one stage where they have to move together, and that is what separates it from other tools a deal-stage buyer will see. Zoning and environmental data sit on the parcel as constraints rather than as a reference layer. The site plan generates against those constraints. The pro forma reads from the geometry that just generated.

In practice that means the loop stops being a sequence of handoffs. Change the parking ratio and the building regenerates against the new requirement. The unit mix updates because the building changed. The yield on cost updates because the unit mix changed. Nobody re-exports anything, and the answer arrives while the question is still live, which is the part that matters when the committee meets Thursday and the seller has three other offers.

Now the work each team does has changed, on top of how fast they do it.. When one scheme costs an afternoon, you evaluate one scheme and defend it. When one scheme costs minutes, you evaluate twenty and bring the best one, which is a different job with a different outcome. Somewhere north of 1,730 deals move through the platform in a given week, according to a 2026 survey of TestFit customers, and the pattern holds across them: many options generated quickly, most discarded, before anyone commits real design hours.

TestFit is not built for every part of this. It won't hunt off-market parcels across a state, and it won't carry a project through documentation. What it is built to do is close the three-function loop at the moment the deal is decided, which is the one place those functions have to move together.

The Takeaway

A single, one-size-fits-all site tool rarely survives contact with the different jobs it's asked to do, because acquisition, feasibility, and schematic design are three different problems wearing one label. Even the biggest players in this space are learning that the expensive way.

Before the next demo, write down the single stage of your process that's costing you the most time and the most dead deals. Evaluate every tool against that stage alone. Features matter enormously, but only the ones that compound on the stage where your deals are stalling. The category that matches your bottleneck will usually contain one obvious answer, and the tools that seemed like competitors will turn out to have been solving somebody else's problem the whole time.

See how TestFit fits into your evaluation. Book a demo and run your next deal through it, at whatever stage you're in.