Ask someone outside the industry what a feasibility analyst does, and they'll usually say something vague about "crunching numbers before a project gets approved." True, but it undersells how much of the day isn't analysis at all it's data wrangling. If you've worked adjacent to real estate development (or you're building tools for it), this breakdown might feel familiar even if you've never touched a pro forma yourself.
The short version: the actual thinking part of feasibility work should deal with pencil, where's the risk, what happens if construction costs jump 8%, takes up maybe a third of the day. The rest disappears into version control chaos, chasing down comps, and rebuilding the same model structure for the fifth time this month.
Morning: Comps, Assumptions, and the First Round of Rebuilding
Most days start with revisiting assumptions. Land cost, hard costs, soft costs, absorption rate none of it stays static for long, especially in fast-moving markets. An analyst might pull updated comps, check whether last week's cap rate assumption still holds, and then realize the model they built it into is a spreadsheet inherited from someone who left the company two years ago.
This is where a chunk of the morning goes: not analyzing, but reconstructing. Tools like EstateMaster exist partly because so many teams were rebuilding the same DCF structure from scratch every time a new deal came in. Having a standardized modeling framework doesn't remove the judgment calls, but it does mean less time spent re-wiring formulas that should've been solid the first time.
Midday: Where Feasibility Analysis Time Actually Gets Wasted
Here's the part nobody puts in the job description. A huge amount of a feasibility analyst's day is spent moving data between systems that don't talk to each other. Cost data lives in one place, budget actuals in another, comps in a third, and none of it syncs automatically. So the "analysis" becomes a copy-paste exercise dressed up as due diligence.
This is usually where deals slow down internally, not because the underwriting is hard, but because pulling accurate, current cost data takes longer than the underwriting itself. Platforms like Northspyre have gained traction specifically because they attack this problem: centralizing project cost and budget tracking so the numbers feeding into feasibility work are live instead of three weeks stale. When the input data is trustworthy in real time, the actual analysis speeds up dramatically.
Afternoon: Scenario Testing and the Sensitivity Analysis Grind
By early afternoon, the work usually shifts to sensitivity testing what happens to yield-on-cost if construction financing rates move, what the exit cap rate needs to be for the deal to still clear a hurdle IRR, and how absorption delays ripple through the whole timeline. This is the genuinely interesting part, and it's also the part that gets squeezed because the morning ran long.
Static spreadsheets aren't built for this kind of rapid scenario testing. Change one input, and you're often manually checking five downstream cells to make sure nothing broke. This is a big reason teams have moved toward feasibility-specific software rather than general-purpose spreadsheet platforms like Deepblocks, which are built around scenario modeling for site feasibility specifically, which means testing five or six variations of a deal doesn't mean five or six versions of a fragile spreadsheet.
Late Afternoon: Formatting for the People Who Actually Approve the Deal
The numbers can be right, and the deal can still stall if the output isn't legible to whoever's approving it, the investment committee, lender, or JV partner. So a real chunk of late afternoon goes into making the model readable: clean summary tabs, charts that actually communicate the story, and sensitivity tables that don't require a walkthrough to understand.
This is often the least efficient part of the day, honestly. Reformatting the same underlying numbers into three different presentation styles for three different audiences eats time that should go toward actually stress-testing the deal. Tools like Aprao have tried to close that gap by keeping feasibility modeling and reporting in one environment, so the output doesn't need a separate formatting pass every time it changes hands.
The Real Time Sink: Manual Rebuilds, Not Bad Analysis
If there's one takeaway from all this, it's that feasibility analysts don't lose time because the underlying math is hard. IRR, yield-on-cost, debt yield calculations, none of that is the bottleneck. The bottleneck is infrastructure: disconnected data sources, manual model rebuilds, and formatting gymnastics that have nothing to do with judgment or expertise.
That's also why there's been a shift toward feasibility-specific platforms rather than trying to force general tools to do this job. Something like feasibilitypro.ai reflects where this is heading: purpose-built feasibility workflows instead of a spreadsheet stitched together with macros and hope. Less time spent rebuilding the wheel means more time actually testing whether a deal is worth building in the first place.
Where This Leaves Feasibility Work
None of this means the human judgment part goes away, deciding whether a market can absorb a BTR product, or whether a hotel's ADR assumptions are realistic, still requires real expertise. But the hours spent on plumbing instead of analysis are the real inefficiency in this line of work, and it's worth naming that clearly instead of pretending every hour in a feasibility analyst's day is spent thinking deeply about the deal. Most days, it's closer to half thinking, half fighting the tools.
Top comments (0)