DEV Community: Real Estate Hub

AI in Real Estate Feasibility: Hype vs. What's Actually Useful Right Now

Real Estate Hub — Sat, 27 Jun 2026 12:10:02 +0000

The real estate industry has a complicated relationship with AI. Half the conversations you'll find online are either breathless "AI will replace analysts!" takes or dismissive "Excel is all you need" counterarguments. Neither is particularly useful if you're actually trying to build or assess projects.

So let's cut through it. Here's what AI is genuinely doing well in feasibility right now, where it's still falling short, and what that means for how you work.

The Hype First (So We Can Get Past It)

The most oversold idea is that AI can autonomously run a development feasibility from end to end. Feed it a site address, and out comes a viable business case. That's not where we are not even close.

Feasibility isn't just a calculation problem. It's a judgment problem. You're making calls on absorption velocity, achievable sales rates, construction cost contingencies, and what a planning authority is actually going to approve versus what the zoning technically allows. AI doesn't have the local market intuition for that, and a lot of it frankly can't be sourced from training data.

The other overhyped thing is "AI-generated reports." What most tools produce is AI-assisted formatting and structuring of outputs you could have made yourself. Calling that intelligence is generous.

What AI Is Actually Good At Right Now

Automating the Repetitive Structure of Models

One thing that genuinely saves time is using AI to set up model frameworks cost category structures, cash flow waterfall templates, sensitivity table layouts. Tools like Northspyre have leaned into this on the project cost management side, helping owners track committed versus projected costs with a layer of automation that reduces the manual entry burden. That's real. It's not glamorous, but it compounds over a 3-year development program.

Scenario Modelling at Speed

Running 50 sensitivity scenarios manually is tedious. AI-assisted tooling can accelerate that loop significantly. EstateMaster has been around long enough to know what practitioners actually need from a feasibility engine, and their approach has always been grounded in the numbers rather than the marketing. Where AI adds value there is in how quickly you can stress-test assumptions across multiple variables simultaneously yield on cost, construction cost escalation, sales rate changes without rebuilding the model each time.

Zoning and Site Analysis as a Starting Point

This is probably the most genuinely useful application. Deepblocks does interesting work here using AI to interpret zoning codes and quickly assess what's developable on a given parcel. It's not a planning approval, and it's not a substitute for a planning consultant, but as a first-pass filter when you're looking at multiple sites? It saves meaningful time. The key word is "starting point." Anyone using it as a final answer is going to get burned.

Soft Cost Estimation and Benchmarking

Getting to a rough feasibility number quickly before you've spent money on consultants is something AI-enhanced tools are getting better at. Aprao has built a product aimed at exactly this use case: early-stage feasibility with enough structure to be useful without requiring you to already know your construction cost breakdown in detail. The question isn't whether it replaces a detailed QS it doesn't but whether it helps you decide if a site is worth pursuing in the first place. For that, it's genuinely useful.

Making Assumptions Transparent and Auditable

This is underrated. One of the real problems with Excel-based feasibilities is that assumptions get buried and nobody can trace where a number came from six months later. feasibilitypro.ai has thought about this — building assumption transparency and auditability into the model structure rather than treating it as an afterthought. That's less about AI and more about discipline, but AI can help surface which assumptions are driving your returns versus which ones barely move the needle.

Where AI Is Still Genuinely Struggling

Market Data Quality

AI tools are only as good as the data they're working with. In established markets with good transactional transparency, you're fine. In GCC markets, secondary cities, or anything off-plan dominated, the data gaps are significant. Garbage in, garbage out — and the AI doesn't know the difference.

Construction Cost Accuracy

Generic construction cost benchmarks are almost useless for feasibility. Costs vary massively by submarket, contractor availability, supply chain conditions, and specification level. AI tools that spit out a per-square-metre number with confidence are the ones you should be most skeptical of.

Planning and Regulatory Nuance

Zoning codes are a starting point, but planning decisions involve discretion, political context, design quality assessments, and community responses that no AI currently handles well. A tool that tells you a site can support 200 units doesn't know that the local council has been rejecting anything over 6 floors for the last two years.

Replacing Experienced Judgment on Assumptions

The biggest risk is using AI-assisted tools to bypass the hard thinking on key assumptions. What's the right sales velocity for this product type in this market right now? What contingency is appropriate given where the contractor market is? Those are questions where experience matters, and AI doesn't have it.

The Practical Takeaway

AI in real estate feasibility is most useful as a productivity layer — not a replacement for the analytical work. The developers getting genuine value from it are using it to do more analysis faster, not to skip the analysis entirely.

The tools that are worth paying attention to are the ones that have been built by people who understand development finance — not generic AI platforms that have been dressed up with real estate language. That's a meaningful distinction, and it matters when you're making decisions that involve tens of millions of dollars.

The honest position: if you're not using any of these tools yet, you're probably leaving efficiency on the table. If you think they can replace experienced underwriting, you're going to make expensive mistakes.

Riyadh vs. Dubai vs. Doha: A Developer's Side-by-Side Market Comparison

Real Estate Hub — Sat, 20 Jun 2026 08:46:55 +0000

If you're a real estate developer trying to figure out which GCC market actually makes sense for your next project, you've probably already noticed that the surface-level narrative "the Middle East is booming" doesn't help you much. All three markets are active. All three have capital flowing in. But Riyadh, Dubai, and Doha are structurally different in ways that matter enormously when you're trying to underwrite a project and make an IC-ready case.

Here's how they actually compare, from a developer's perspective.

Market Structure and Who's Driving Demand

Dubai's demand story is well-documented at this point: it's internationally driven, heavily skewed toward investor buyers (both regional and global), and it runs on sentiment as much as fundamentals. That's not a criticism it's just how the market works. When global confidence is high and capital is mobile, Dubai absorbs a lot of it. When it isn't, absorption slows faster than the supply pipeline does.

Riyadh is a fundamentally different animal. The demand base is predominantly domestic Saudi nationals and long-term residents, driven by Vision 2030-linked employment growth, giga-project spillovers, and genuine housing undersupply in the mid-market. The population is young, growing, and increasingly urbanizing into Riyadh specifically. This makes the demand story more durable in some ways, but also more sensitive to government employment policies and subsidy structures like REDF.

Doha sits somewhere in between. It's a small market by GCC standards, with demand that was largely shaped by the World Cup build-up and is now going through a post-event recalibration. The expatriate population remains the primary demand driver for residential, but the government has been actively working to diversify the economy and attract foreign investment — which is creating some interesting commercial and mixed-use opportunities even as the residential market finds its new equilibrium.

Land and Entitlement

This is where developers often get surprised. In Dubai, the land acquisition and project registration process through RERA and the relevant master developer is relatively well-understood and move-fast-by-regional-standards. Freehold zones are clearly defined, foreign ownership is permitted in designated areas, and the regulatory environment, while not frictionless, is legible.

Riyadh is more complex. Land ownership in Saudi Arabia is restricted to Saudi nationals and GCC citizens in most categories, which means foreign developers typically need to structure joint ventures or work within the framework of specific investment licenses. The regulatory environment is modernizing quickly the Ministry of Municipalities and Housing has been pushing through significant reforms — but the process of navigating entitlements for a large-scale development is still materially more involved than Dubai. That said, the government is actively facilitating development at a scale that's genuinely unprecedented, and if you have the right local partnerships, the pipeline of opportunities is enormous.

Doha has been progressively opening up foreign ownership through its freehold and leasehold zones The Pearl, Lusail, and a few others but the market is smaller and the number of genuinely institutional-grade development opportunities is more limited. Government entities like Qatari Diar and Msheireb Properties dominate the large-format development pipeline, which means private developers are often competing for a narrower set of sites.

When you're modeling land cost as a component of RLV across all three markets, the entitlement risk profile looks very different and that has to be reflected in your feasibility assumptions, not just treated as a legal footnote.

Construction Costs and Supply Chain

Dubai has a mature contractor market with genuine competition at most tier levels. You can get multiple credible bids, there's reasonable price discovery, and the supply chain for most standard construction inputs is well-established. Cost inflation has been real over the last couple of years, but it's manageable and there's data to anchor your assumptions.

Riyadh is experiencing significant cost pressure right now, primarily because the volume of concurrent government and mega-project activity is absorbing contractor capacity. Skilled labor is tight, materials supply chains are being stress-tested, and some developers are seeing construction cost escalations that their original feasibility models didn't anticipate. This isn't a reason to avoid the market but it is a reason to build more conservative contingency into your cost waterfall and to think carefully about contractor procurement strategy. Tools like Northspyre are increasingly relevant in this context for tracking actual versus budgeted spend on large programs where cost drift can compound across phases.

Doha's contractor market has gone through a significant post-World Cup adjustment. A lot of the capacity that was mobilized for tournament infrastructure has either demobilized or redeployed, which has created some pricing normalization. For developers entering now, that's actually a reasonably favorable construction cost environment compared to the 2019–2023 peak period.

Feasibility and Return Expectations

Yield compression in Dubai has been a consistent story for the last few years. Prime residential yields have come down, land values have moved significantly, and the developers still making strong returns are largely doing so through speed fast project cycles, off-plan sales momentum, and operational efficiency. The margin for error on a poorly modeled project has genuinely narrowed.

Riyadh offers more interesting yield dynamics right now, partly because the market is less mature and pricing is still catching up to underlying demand in many segments. Affordable and mid-market residential in particular has a supply gap that's well-documented. But the modeling is harder you're working with less transaction data, more volatile construction costs, and a regulatory environment that's still evolving. EstateMaster's phased cash flow modeling is particularly useful here for understanding how a multi-phase residential scheme plays out when absorption and cost escalation are both uncertain, which in Riyadh right now is basically always.

Doha is a yield story that requires patience. The residential market is recovering, commercial is selective, and the most interesting opportunities are probably in hospitality and mixed-use where the government is actively trying to build a long-term tourism economy. For developers used to short cycle times, Doha requires a different mindset.

For teams running scenario analysis across all three markets simultaneously which is increasingly what regional developers are doing as they think about portfolio allocation feasibilitypro.ai's ability to run rapid iterations across different market assumptions is worth factoring into your workflow. When you're trying to compare a residential scheme in Riyadh against a mixed-use play in Dubai with fundamentally different cost, absorption, and exit assumptions, the manual modeling overhead adds up fast.

Density, Massing, and Planning Context

Dubai has been pushing density upward in ways that would have surprised planners a decade ago. JVC, Business Bay, and parts of Jumeirah Lake Towers now have skylines that reflect genuine high-rise urbanism. The planning environment has adapted to that, and developers have gotten comfortable with high-density, high-velocity residential models.

Riyadh is a more horizontal city by tradition, but that's changing. Vision 2030 is explicitly targeting densification in specific corridors, and the King Salman Road and King Abdullah Financial District areas are seeing significant height. The massing optimization question how much GFA can you extract from a given site while still hitting the right product mix and pricing is one where tools like Deepblocks are genuinely useful, particularly for development teams that need to run density scenarios quickly at the site selection stage rather than commissioning a full planning study for every potential land parcel.

Doha's planning context is more controlled. Lusail in particular was master-planned in a way that constrains individual developer decisions fairly tightly which reduces planning risk but also limits the upside of smart massing decisions.

The Bottom Line for Developers

These aren't interchangeable markets dressed up in different weather. Dubai is a high-velocity, globally connected market where your competition is sophisticated and margins reward execution speed. Riyadh is a structural growth story with real demand fundamentals, but it requires patience with regulatory complexity and serious cost escalation risk management. Doha is a selective opportunity market where the best returns will come from understanding the government's long-term vision rather than chasing short-cycle residential plays.

The worst thing a developer can do is take a feasibility model that worked in one of these markets and apply it wholesale to another. The RLV logic, the absorption assumptions, the capital stack structure, and the exit timing all need to be recalibrated from the ground up. That's not extra work that's just what rigorous feasibility looks like across markets that are genuinely different from each other.

If you're working across all three, build your models to reflect those differences explicitly. The opportunity is real in all three places. The risk is in pretending they're the same story.

Hospitality Feasibility with AI: A Hotel Development Walkthrough

Real Estate Hub — Sat, 13 Jun 2026 06:35:12 +0000

Hotel development feasibility is one of those processes that looks clean on paper and turns into controlled chaos in practice. You're pulling RevPAR projections from STR reports, layering in construction cost assumptions, adjusting your ADR curve three times because the market comp set shifted, and somehow trying to land on a development yield that satisfies your lender and your equity partners simultaneously. It's a lot of moving parts and most of it still runs on Excel.

That's starting to change. Not in a dramatic "AI will replace your feasibility analyst" way, but in a quieter, more useful one: AI tools are starting to compress the time it takes to get from site identification to a credible first-pass pro forma. Let me walk through what that actually looks like in a hotel development context.

Starting Point: The Site and the Brief

A mid-scale select-service site think a 120-key limited-service hotel in a secondary market. You've got the land under LOI, you have a rough program (rooms, F&B, parking), and you need to run feasibility before you commit to DD spend.

Traditionally, the first two weeks are spent gathering: comp set analysis, market demand data, cost benchmarks from recent comparable projects, zoning verification, and a rough capital stack sketch. That's before a single cell in Excel is populated.

With AI-assisted workflows, a chunk of that front-end research compresses significantly. Tools like Deepblocks, which focuses on urban analytics and development potential, can surface land use parameters, density restrictions, and comparable development patterns faster than manually pulling GIS layers and zoning ordinances. For urban hotel sites specifically especially mixed-use plays where the hotel sits above retail or residential having that zoning and massing intelligence early changes the conversation with your architect before the first schematic design meeting.

Building the Revenue Model

Revenue modeling for hotels is its own discipline. It's not just about square footage or rent per unit you're modeling occupancy curves by season, ADR sensitivity to market positioning, RevPAR indices against the comp set, and how your brand flag (or lack thereof) affects stabilized performance assumptions.

This is where the AI assistance gets interesting. Some platforms now let you feed in market-level data and generate preliminary demand forecasts with penetration rate assumptions baked in. The output isn't investment-grade yet you still need your hotel consultant or a branded feasibility report from STR/CoStar but it gives you a working hypothesis to stress-test before you commission that expensive third-party study.

Aprao, which is primarily a development appraisal platform, handles the layering of revenue assumptions into a live pro forma in a way that's more responsive than static spreadsheets. If your STR data suggests your blended ADR needs to be $148 to hit your target yield, you can immediately see what happens to your development margin when that ADR assumption drops to $132 and what that does to your residual land value. For hospitality projects where the revenue model is inherently uncertain (especially in emerging markets or repositioning plays), running those sensitivity loops quickly matters.

Cost Side: Where Assumptions Get Dangerous

Construction cost assumptions for hotel development are notoriously difficult to get right at feasibility stage. A select-service hotel builds out very differently from a boutique lifestyle property, and the FF&E component alone furniture, fixtures, and equipment, which for hotels can be 15–25% of total project cost gets underestimated constantly.

This is a place where AI tools that pull from historical cost databases genuinely earn their keep. EstateMaster, which has been in the development feasibility space for a long time, handles this kind of cost benchmarking within its broader financial modeling framework. When you can anchor your per-key construction cost to validated comps rather than a back-of-envelope estimate from your GC's last project, your contingency assumptions get more defensible and your IC (investment committee) conversations get less painful.

The other cost risk that AI-assisted tools are starting to address is the timeline sensitivity. Hotel projects have unusually long stabilization curves you're not selling units at completion, you're ramping occupancy over 18–36 months. If your construction schedule slips by four months, your carry cost blows up, your opening coincides with a shoulder season, and your Year 1 RevPAR looks terrible on paper. Modeling those schedule sensitivity scenarios systematically, rather than manually rebuilding the timeline each time, is exactly where platforms that automate sensitivity tables add real value.

The Residual Land Value Problem in Hospitality

Residual land value (RLV) is the output that tells you whether the deal works it's what's left over after you subtract all development costs and required profit margin from the gross development value (GDV). In hotel development, GDV is typically expressed as a cap rate applied to stabilized NOI, which means your RLV is hostage to three unknowns stacked on top of each other: stabilized revenue, cap rate assumptions, and total development cost.

This is where feasibilitypro.ai's approach is worth noting. The platform is built specifically around feasibility modeling with AI-assisted scenario generation, and for hospitality assets where you often need to run a full-service versus select-service versus mixed-use hotel comparison on the same site being able to generate multiple development scenarios and compare their RLV outputs side-by-side without rebuilding the model each time is legitimately useful. The GCC hospitality market, which has some of the most complex mixed-use hotel programs in the world, is a context where this kind of multi-scenario capability maps directly onto how developers actually think about their options.

Northspyre sits in this execution layer rather than the feasibility layer. It's a project financial management platform that uses AI to flag budget variance, automate vendor invoice processing, and surface cost overrun risks before they become surprises at your monthly owner-lender call. For hotel developers specifically where the FF&E procurement cycle overlaps with base building construction and the brand's PIP (property improvement plan) requirements can shift mid-project — having real-time cost visibility rather than a monthly spreadsheet update matters.

What AI Doesn't Fix

It's worth being direct about the limits here. AI-assisted feasibility tools don't resolve the fundamental uncertainty in hotel development they just let you explore it more efficiently. Your ADR assumptions are still based on market judgment. Your cap rate at exit still reflects investor sentiment that can shift dramatically. Your construction cost benchmarks are only as good as the comparable data in the underlying database.

And hospitality feasibility has some genuinely hard inputs that no AI tool is going to hand you: the brand negotiation, the franchise fee and PIP structure, the management agreement terms, the debt structure from a construction lender who actually understands hotel assets. That's still relationship-driven, judgment-driven work.

What these tools do is compress the time between "we have a site" and "we have a credible development hypothesis." For hotel developers running multiple opportunities in parallel which is basically everyone in this space that compression has real value. You can kill the bad deals faster and get the good ones to IC with better supporting analysis.

The Practical Takeaway

If you're doing hotel feasibility today and your entire workflow lives in Excel with a few STR reports stapled to the side, the tools above are worth evaluating not because they're going to transform your process overnight, but because the gap between a manually-built pro forma and an AI-assisted one is starting to show up in how fast teams can respond to opportunities.

The developers who get to IC first with a defensible feasibility model have an advantage. That's always been true. AI is just starting to change what "fast" looks like in that race.

How to Build a Sensitivity Table for a Mixed-Use Development in Minutes

Real Estate Hub — Thu, 04 Jun 2026 06:31:43 +0000

Mixed-use deals are genuinely messy. You've got residential above retail, maybe some office thrown in, different lease structures, different cap rates per use and your investor wants to know what happens to returns if rent drops 10% or construction costs spike. That's where a sensitivity table stops being a "nice to have" and becomes the thing that saves you from confidently presenting a deal that falls apart under light questioning.

First, Why Mixed-Use Makes Sensitivity Analysis Harder

In a straightforward apartment building, you're mostly toggling rent per unit and exit cap rate. With mixed-use, each component has its own income driver, its own vacancy assumptions, and sometimes its own financing treatment. A 10% rent decline in your ground-floor retail hits completely differently than the same drop in your residential floors especially if your retail is NNN and your residential is gross.

So your sensitivity table can't just be a single two-variable grid. You either need component-level tables, or you need a model that aggregates them cleanly enough that the blended output still tells a useful story.

Step 1: Lock Down Your Base Case Numbers First

Before you touch a sensitivity table, you need a model that actually works. That sounds obvious, but a lot of people try to run sensitivities on a half-built model and wonder why the outputs look weird.
For a mixed-use project your base case needs at minimum:

GBA breakdown by use (residential, retail, office, parking)
Revenue assumptions per use residential rent per unit, retail rent per sqft, occupancy by component
Hard and soft cost totals, development timeline
Stabilized NOI per component, then blended
Exit cap rate or sale price assumption
Financing structure construction loan, permanent debt, equity stack
Your IRR and equity multiple at base

Once that's solid, you're ready to run scenarios against it. Tools like EstateMaster have been around long enough that their mixed-use module handles this component-by-component breakdown natively so if you're modeling in something purpose-built rather than Excel, the base case structure is already baked in.

Step 2: Pick Your Two Variables

A sensitivity table is a grid:- rows are one variable, columns are another, and every cell shows your output metric (usually IRR, equity multiple, or profit margin).

For mixed-use, the most useful variable pairs I've seen are:
Residential rent vs. exit cap rate:- captures both income and valuation risk in one table. This is the one every equity partner wants to see.

Construction cost variance vs. retail rent:- useful when your retail is less certain (pre-leased vs. speculative) and your GC bid has some range to it.

Residential occupancy vs. retail occupancy:- shows how bad things have to get on both sides simultaneously before the deal breaks.

Equity contribution vs. construction cost:- if you're stress-testing the capital stack.

Don't try to do all of these in one table. Pick the two that represent the most meaningful uncertainty in your specific deal. If your retail is already pre-leased at a fixed rate, retail rent isn't a relevant sensitivity variable for you right now.

Step 3: Define Your Range Increments

Most sensitivity tables use 5 or 7 data points per variable, stepping in equal increments around the base case.

For a residential rent assumption of $2,800/unit, you might step in $150 increments: $2,200 / $2,350 / $2,500 / $2,650 / $2,800 / $2,950 / $3,100

For exit cap rate at 5.25%, stepping in 25bps:
4.25% / 4.50% / 4.75% / 5.00% / 5.25% / 5.50% / 5.75%

The base case cell sits in the middle of the grid. The ranges should represent realistic stress not apocalyptic scenarios, but not cosmetic either. If your market has seen 15% rent swings in the last cycle, your table should probably cover at least that range.

Step 4: Build the Table (Excel vs. Dedicated Tools)

If you're in Excel, the cleanest approach for sensitivity tables is the Data Table function under What-If Analysis. You set up a row input cell and a column input cell, highlight the grid, and it runs every combination without you having to do it manually. The trick is making sure your model has clean cell references that actually link back to the inputs if your residential rent is hardcoded in 12 different places, the table won't work right.
This is also where a lot of people hit a wall with mixed-use models specifically. If your model has three separate income schedules that all need to respond to the same input shift, you need an intermediate cell that ties them together. Build it right and the table works in seconds. Build it messily and you'll spend an hour debugging.

If you're using dedicated feasibility software, this is much faster. Aprao, for instance, is built for development appraisals and lets you run scenario comparisons without the manual table setup you define the variable range and it handles the grid. Similarly, Deepblocks does this at the project concept stage, which is useful if you're still in early feasibility and don't want to over-engineer the model yet.
Northspyre leans more toward active project cost tracking and budget management, but if your sensitivity is focused on cost variance (which it often should be on complex mixed-use deals), pulling actual cost data from there into your sensitivity assumptions gives you ranges grounded in real project data rather than guesses.

Step 5: Choose Your Output Metric Carefully

IRR is the default, but it's not always the most useful. Here's when to use what:
IRR use when you're talking to equity partners who have a hurdle rate. They want to know if you clear it under stress.

Equity Multiple use when the hold period might vary or when your LP cares more about total return than annualized rate.

Profit on Cost / Development Margin use in early-stage feasibility, before you've locked down the capital structure. Simpler, harder to game.

Levered vs. Unlevered show both if you can. A deal that looks okay unlevered but breaks levered at mild stress tells you something important about the financing structure.

For a mixed-use project where you're presenting to a lender or a value-add equity partner, I'd show IRR and profit-on-cost side by side. Different people anchor to different metrics.

Step 6: Color Code It So the Story is Obvious

This sounds minor but it matters. A raw table of numbers requires someone to read every cell. A color-coded table communicates instantly.
Simple convention:

Green:- IRR above your target (say, 15%+)
Yellow:- IRR within acceptable range (10–15%)
Red:- IRR below hurdle or deal is structurally broken

In Excel this is a two-minute conditional formatting job. In most dedicated tools it's automatic. Either way, when you hand this to someone in a meeting they should be able to look at it for five seconds and understand where the deal is robust and where it isn't.

A Note on AI-Assisted Feasibility

This is moving fast. feasibilitypro.ai is one of the newer tools specifically targeting this workflow where you input project parameters and it generates scenario outputs including sensitivity grids without you having to build the model architecture yourself. The pitch is speed at early feasibility, which is legitimate. If you're running 10 sites through initial screening, spending four hours building a model per site is genuinely not the right use of time.

The caveat and this applies to any automated feasibility tool is that the assumptions it uses need to match your market. Output is only as good as the input assumptions, and local rent trends, cap rate compression, construction cost premiums, and land residuals vary enough that you should always sanity check the numbers against deals you've actually underwritten or closed in the same market.

What the Table Should Actually Tell You

Once you've got the grid, here's what to look for:
Where's the break-even line? Find the cells where your IRR crosses the hurdle rate. That diagonal line tells you the worst combination of your two variables the deal can tolerate.

Is the deal sensitive to one variable much more than the other? If moving the cap rate 50bps kills the deal but a 15% rent decline barely moves the needle, that's telling you something about where your real risk is.

How much cushion do you have? If your base case is in the middle of the green zone, that's a different deal than one where base case is sitting one cell from red.
Does this match your gut read on the market? If your table says the deal works under a lot of scenarios but you know retail leasing in that submarket has been dead for two years, the table is not a substitute for judgment.

The Whole Point

A sensitivity table for mixed-use isn't complicated it's two variables, a grid, and a clean base case model. The reason people struggle with it is usually that the underlying model isn't structured well enough to run clean scenario analysis, or they're trying to show sensitivities on too many variables at once and it becomes noise.

Get the base case right, pick the two variables that actually matter for your deal, run the grid, and color it. That's the whole thing. Thirty minutes if your model is already built. And when someone in the room asks "what happens if construction costs run 12% over?" you just point at the table.

Hospitality Feasibility with AI: A Hotel Development Walkthrough

Real Estate Hub — Sat, 23 May 2026 06:38:32 +0000

So you've got a site. Maybe it's a plot in a secondary city that looks promising on paper, or a distressed property someone's pitching as a conversion play. The first real question before architects, before brands, before you spend $80K on a full feasibility study is: does this actually work as a hotel?

That question used to take weeks and a lot of expensive consultant hours. Now? A good chunk of it can be stress-tested in a day, sometimes hours, using AI-assisted tools that have gotten genuinely useful in the last couple of years.

This isn't about replacing your feasibility team. It's about walking into those conversations better prepared and killing bad deals faster.

The Old Way (And Why It Breaks Down Early)

Classic hotel feasibility has a pretty standard arc: you do market research, pull STR or CoStar data, estimate ADR and occupancy for a comp set, build a financial model, stress-test your assumptions, and eventually land on a projected NOI. Then you overlay construction costs, financing, and see if the returns make sense.

The problem is the sequencing. Most of that work happens after you've already convinced yourself the deal is worth pursuing. By the time you get to the numbers-don't-work moment, you've burned time, soft costs, and a lot of internal goodwill on a deal that probably failed a basic feasibility test in week one.

AI doesn't fix that problem by being smarter than your consultants. It fixes it by being faster at the parts that don't need to be slow.

What a Modern AI-Assisted Walkthrough Looks Like

Let's say you're evaluating a 120-key select-service hotel on a 2-acre site in a mid-sized metro a B-market city with a developing convention scene and some corporate demand drivers.

Here's how you'd actually move through this today.

Step 1: Site-Level Economics Before Anything Else
Before market comps, before brand conversations, you need to know if the site can physically and financially support what you're imagining.

Tools like Deepblocks are useful here you can feed it parcel data, zoning constraints, and building parameters, and it'll run massing scenarios and density outputs fast. It's not magic, but it stops you from falling in love with a 200-room concept on a site that can only support 90 keys at the setback requirements.

Aprao does something similar from a development appraisal angle it's built more for the UK/European market but the logic is transferable. You're essentially asking: what can I build here, and does the residual land value math hold at my target return?

This phase used to require a back-and-forth with a local architect and a pro forma jockey. You can now shortcut the first pass significantly.

Step 2: Market Demand Not Just "Is There a Market" But "What Kind"**
Here's where a lot of feasibility work goes wrong. People look at market occupancy (say, 68%) and assume a new entrant can match it. But that number is a blend of a lot of different demand profiles transient leisure, group, corporate negotiated, extended stay and a new 120-key select-service hotel is not going to capture all of them equally.

AI-assisted market modeling is getting better at disaggregating this. You can use tools or even a well-prompted AI session to work through: what's the corporate demand base in this submarket, is it growing or flattening, what's the convention calendar look like, are there any major demand disruptors (new supply under construction, a large employer relocating)?

EstateMaster has long been used for the financial modeling layer of development feasibility it's solid for cash flow projections and sensitivity analysis. Pairing that with AI-driven market inputs gives you a faster loop between "here's what the market supports" and "here's what that means for your IRR."
Step 3: Build the Pro Forma But Flag Your Own Assumptions
This is where a lot of people get themselves into trouble. They build a model, it works, and they stop questioning it.

The smarter approach and this is where AI actually earns its keep is to build the model and systematically pressure-test every assumption. What happens to your returns if ADR comes in 12% below projection in year one? What if construction costs run 15% over (they will)? What if your stabilization timeline stretches from 18 to 30 months?

Northspyre is worth knowing here if you're an owner or developer managing multiple projects it's built for budget and cost management during development, and it integrates real-time cost tracking in a way that keeps your pro forma honest as the project moves forward. It's less about initial feasibility and more about not letting your feasibility assumptions become fiction once ground breaks.

feasibilitypro.ai is one of the newer entrants trying to put the whole feasibility workflow in one AI-native interface market data, financial modeling, scenario analysis. Worth a look if you want something purpose-built for this rather than stitching tools together.

Step 4: Sensitivity Analysis at Scale
A single scenario pro forma is basically useless for making a real decision. You need ranges.

What makes AI genuinely helpful here is running hundreds of scenarios fast varying your occupancy ramp, ADR growth assumptions, construction timeline, cap rate at exit and seeing which variables actually move the needle on your equity multiple versus which ones feel scary but don't really matter.

The output you want isn't "this deal works." It's "this deal works under these conditions, breaks under these conditions, and here are the two or three variables I need to be most right about."

That framing changes how you diligence a deal. Instead of trying to prove the bull case, you're trying to understand your exposure in the bear case and whether you can live with it.

A Few Things AI Still Can't Do Well

Let's be honest about the limits, because the oversell on AI in real estate is real.

Local political risk whether a project can actually get entitled, whether the city council is friendly to hotel development, whether there's community opposition that's still a ground-game problem. No model captures it well.

Brand negotiation dynamics what a flag is actually going to require in terms of PIP, key money, FF&E reserves, and royalty structure is relationship and experience knowledge. The numbers exist in databases but the judgment about what's negotiable doesn't come from a tool.

True comparability of comps automated systems will pull hotel comps based on proximity and category, but they can miss important qualitative differences (a comp set that includes a resort property skews your ADR assumptions badly if you're building a business hotel).

These are the places where your experienced consultants still absolutely earn their fee. The AI tools handle the computational volume and speed. The human judgment handles the things that don't reduce to data.

So What's the Actual Workflow?

If I were walking a hotel site today, the honest answer is: I'd use a combination of AI-native tools for the fast first pass, bring in market research for the demand layer, and use something like EstateMaster or a custom model for the final financial structure with AI helping me stress-test assumptions rather than build the base case.
The sequence that makes sense:

Site feasibility:-massing, density, zoning, rough cost per key (Deepblocks or Aprao)
Market framing:- demand drivers, comp set performance, supply pipeline
Draft pro forma:- ADR/occupancy assumptions, revenue build, cost structure
Sensitivity sweep:- what breaks this deal and at what threshold
Decision checkpoint:- before you spend another dollar, does this still make sense?

The goal is getting to that decision checkpoint faster, with better information, so you're not three months and $50K into a deal before you find out the math doesn't close.

Final Thought

Hotel development is expensive and slow to fail. That's the core problem. Any tool or process that compresses the feedback loop on bad assumptions whether it's AI-assisted massing, faster pro forma iteration, or better scenario modeling is genuinely valuable, not because it's smarter than your team but because it gets your team to the right questions sooner.

The developers I've seen use this well aren't treating AI as a replacement for expertise. They're using it as a way to walk into expert conversations having already killed the obvious mistakes themselves.

That's a pretty good use of the technology, honestly.

How AI Is Reshaping Real Estate Underwriting in 2026

Real Estate Hub — Tue, 12 May 2026 10:26:18 +0000

Real estate underwriting has been done roughly the same way for 30 years. An analyst collects data, builds a spreadsheet, models assumptions, and writes a report. The spreadsheet is usually enormous. The data collection is manual. The model is often a black box that only its creator fully understands.

AI is breaking all three of those parts at once, and the industry is just starting to figure out what that means.

The data problem, first
The biggest bottleneck in underwriting has never really been the modelling. It's been the research. Finding comparable sales, rental rates, vacancy trends, construction costs, and demographic shifts that work is slow, repetitive, and expensive when you're paying an analyst to do it.

The new generation of real estate AI tools (FeasibilityPro.ai, Cherre, HelloData.ai, others) is building what you might call "intelligence layers" unified data stacks that pull from proprietary research, third-party market sources, and live feeds and make that data queryable in natural language.

Instead of an analyst spending half a day pulling comps, the AI surfaces them in seconds, with citations you can trace back to the source. The analyst's job shifts from data retrieval to data interpretation.

That's a meaningful shift.

What's actually changed in the modelling layer
The financial models themselves are getting smarter too, but in a specific way, they're becoming auditable rather than just automated.

The old problem with AI-generated financial models was trust. You'd get a number but have no idea how the system arrived at it. That's fine for a rough estimate, but no lender or investment committee is going to approve a deal based on a model they can't interrogate.

The better tools now are generating models where every cell is cited. You can click a value and see exactly what formula drives it, what assumption it's based on, and where that assumption came from. FeasibilityPro.ai does this through AI-labeled cell references and calculation chain tracing inside Excel.

That's the thing that makes AI models actually usable in professional contexts, not the speed, but the auditability.

The Excel situation (nobody wants to talk about this, but it matters)
Every few years, someone declares that Excel is dying and will be replaced by some purpose-built platform. It never happens. Real estate development firms run on Excel. Investment committees review Excel. Lenders want Excel.

The AI tools that are actually gaining traction understand this. They're not trying to replace the spreadsheet; they're embedding AI inside it. Excel Add-ins, AI-assisted formula debugging, and natural-language cell navigation. The interface stays familiar, and the capability increases.

This is probably the most pragmatic design choice an AI tool in this space can make.

Where the human still matters
Worth being clear about what AI underwriting tools don't do:

They don't know about the informal planning relationship between a developer and a local council
They don't factor in a site-specific contamination issue that's not in public records
They don't understand that a particular submarket is weird because of one dominant landlord who never drops rates
They don't replace a senior analyst's gut check on whether the numbers feel right, given everything they've seen

AI tools in real estate are really good at compressing the mechanical work. They're not good at replacing the domain expertise that takes years to build. The analysts who will win are the ones who use AI to eliminate the grunt work and spend their time on the judgment calls.

The tools worth knowing in 2026
FeasibilityPro.ai:- Excel-native AI pro-forma generation + market research layer
TestFit:- site-to-yield design feasibility for developers in early site testing
Zenerate:- AI-generated floor plans and site layouts for land development
Feasibly:- multi-agent AI for bank-ready feasibility reports (higher price point, human oversight)
Cherre/Cotality:- institutional-grade real estate data platform
AIRE Software:- AI feasibility studies with market-driven financial analysis

None of these tools is doing the same thing. The market is fragmenting by use case which is actually a healthy sign. It means the tools are getting specific rather than trying to be everything.

What to watch for in the next 12 months
The next frontier is AI agents that can run multi-step underwriting workflows autonomously. Not just generate a model but update it when market conditions change, flag when an assumption has drifted from current data, and surface deal risks without being asked.

Whether that's exciting or concerning probably depends on what seat you're sitting in.

Why Feasibility Models Fail to Capture Working Capital Stress

Real Estate Hub — Thu, 07 May 2026 09:22:59 +0000

THE PROBLEM NOBODY TALKS ABOUT
Most feasibility models look healthy on paper. Strong IRR, reasonable margins, clean sensitivity tables. Then the project gets underway, and somewhere around month eight, the developer is scrambling for bridge financing they never planned for. Working capital stress is one of the most common reasons projects stall, and it's rarely modeled properly.
This isn't a skills gap. It's a structural problem in how feasibility models are built.

WHAT THE WORKING CAPITAL STRESS ACTUALLY MEANS IN DEVELOPMENT
Working capital stress happens when a project is cash-flow negative for longer than the model predicted, even if the overall return still looks fine. Construction drawings get delayed. Presales fall short of thresholds. A subcontractor goes under and causes a six-week delay. Each of these events creates a gap between when money goes out and when it comes in.
The model shows you the endpoint. It rarely shows you the journey, and the journey is where projects die.

WHY MODELS MISS IT
The first issue is timing. Most feasibility models work on a monthly cadence at best, and many use a quarterly. That's too coarse to catch the real cash valleys. A project might show positive working capital in Q2 but be dangerously short during weeks three through seven of that quarter.

The second issue is that construction cost drawdowns are usually modeled as smooth S-curves. In reality, they're lumpy. A major concrete pour, a steel delivery, or a façade package can represent 15-20% of total construction cost, hitting in a single month. That kind of concentration just doesn't show up in an averaged drawdown schedule.

The third and most overlooked issue is that revenue receipts are assumed to be on time. They're not. Settlements get delayed. Solicitors take longer than expected. Buyers fall over at the last minute and get replaced. Even in a strong market, there's always a lag between when you expect money and when it actually lands in your account.

WHAT A PROPER WORKING CAPITAL ANALYSIS SHOULD INCLUDE
A credible working capital stress test needs to account for: a construction draw schedule that reflects actual milestone payments, not averages; a revenue receipts schedule that applies realistic settlement lag (not just contract dates); a minimum cash reserve buffer typically 8-12% of construction cost, depending on project complexity; and scenario testing for what happens if 15-20% of presales settle 60-90 days late.
None of this is exotic. It's just rarely done because the standard feasibility template doesn't have a row for it.

THE REAL COST
When working capital stress hits unplanned, the options are all expensive. Emergency bridging finance at elevated rates. Selling down equity to bring in a capital partner. Delays that trigger penalty clauses. In some cases, forced early sales at discounts are used to generate liquidity. Any one of these can turn a 22% IRR project into a 14% one.

The irony is that the model showed 22% all along. It just didn't show you how tight the path to that return actually was.

The Operational Impact of Incorrect Construction Sequencing Assumptions

Real Estate Hub — Tue, 28 Apr 2026 17:31:28 +0000

In feasibility analysis, the numbers don't lie — but the assumptions feeding them often do.

When a developer runs a feasibility study, the headline outputs — IRR, equity multiple, net profit margin — command all the attention. What rarely gets scrutinized with equal rigor is the construction sequencing logic sitting silently beneath those numbers. This is a critical oversight. Incorrect construction sequencing assumptions don't just introduce minor modelling errors — they cascade across cash flows, financing structures, and go/no-go decisions in ways that can be operationally catastrophic.

This article is for the analysts, developers, and asset managers who live inside tools like FeasibilityPro.AI, ARGUS, EstateMaster, and APRAO — and who need to understand why sequencing assumptions deserve the same rigour as yield inputs.

What Is Construction Sequencing — And Why Does It Matter?

Construction sequencing refers to the phased order in which construction activities are planned, executed, and completed. In a multi-stage residential development, for example, sequencing determines when civil works begin, when above-ground structure commences, when practical completion triggers, and — crucially — when presale settlements or income streams are expected to land.

In a feasibility model, every draw-down of construction funding, every interest accrual period, and every revenue recognition event is anchored to these sequencing milestones. Get the sequence wrong and you don't just move a number — you shift the entire cost and revenue envelope.

The problem is systemic: most feasibility analysts default to idealised sequencing assumptions derived from project briefs, indicative programmes, or worse — precedent projects with entirely different site conditions.

The Three Ways Incorrect Sequencing Destroys Feasibility Accuracy

1. Distorted Construction Cost Draw-Down Curves

Construction costs don't land in a straight line. They follow a project-specific S-curve shaped by mobilisation, structural phases, services rough-in, and fit-out. When analysts input a generic draw-down profile — say, 10% / 30% / 40% / 20% across four equal quarters — they introduce phantom cash flow timing that misrepresents peak debt exposure.

In EstateMaster DF, this matters enormously. The platform's debt structuring and interest calculation engine is highly sensitive to the timing of cost draw-downs. A miscalibrated draw-down curve can understate peak debt by 8–15%, which flows directly into a flattering (and incorrect) interest cost figure. When the real construction programme surfaces, the project's feasible land value shrinks accordingly — sometimes below the price already contracted.

2. Premature or Delayed Revenue Recognition

For residential developments reliant on settlement-stage revenue, construction sequence dictates when practical completion occurs by stage — and therefore when developers can call settlements and recognise income. If the sequencing model assumes Stage 1 PC in month 18 but actual programme logic (driven by services infrastructure lead times, council approval milestones, or contractor mobilisation windows) pushes PC to month 24, the feasibility's IRR profile collapses.

ARGUS Developer is widely used for this layer of analysis, particularly on mixed-use and commercial-facing schemes. Its scenario modelling capability is powerful, but only as good as the sequencing timeline fed into it. Analysts who treat ARGUS as a black box — inputting hopeful completion dates rather than programme-derived ones — routinely produce feasibilities that look compelling on screen and fall apart on site.

3. Finance Structuring Assumptions That Cannot Be Met

Construction facilities are structured around a project programme. LVR covenants, interest reserve sizing, and drawdown approval milestones all assume the developer can evidence progress against a credible timeline. When the underlying feasibility model has been built on incorrect sequencing, the finance structure it generates is architecturally unsound.

Lenders increasingly scrutinise the link between feasibility outputs and the construction programme. Submitting an ARGUS or FeasibilityPro.AI appraisal with a 20-month construction timeline when the builder's preliminary programme shows 28 months is no longer something that slips past credit committees unnoticed.

What Industry-Leading Platforms Are Doing About It

The feasibility software ecosystem has been evolving — and the better platforms are building in sequencing intelligence rather than leaving it entirely to the analyst.

FeasibilityPro.AI represents a new generation of AI-augmented feasibility tools that can flag sequencing anomalies by benchmarking user inputs against project-type databases. If a user enters a construction duration for a 150-unit mid-rise that sits two standard deviations below the platform's comparable project dataset, FeasibilityPro.AI surfaces that discrepancy as a risk flag rather than accepting it silently. This kind of embedded intelligence is a genuine step forward — it shifts the platform from passive calculator to active analytical partner.

APRAO, widely adopted by smaller developers and feasibility consultants in the UK and Australian markets, has made progress on construction cost phasing with its cost profile templates. These allow analysts to apply project-type-specific draw-down curves rather than linear defaults, reducing one of the most common sequencing-related errors. APRAO's cloud-based collaboration model also means that when a QS updates the construction cost programme, those changes propagate into the live feasibility — rather than existing as a disconnected Excel annex.

EstateMaster remains the platform of choice for developers who need granular control over staged revenue and cost modelling across complex multi-stage schemes. Its strength is precisely the level of sequencing detail it can accommodate — but that same depth creates risk for analysts who don't use it rigorously. The platform rewards expertise and penalises shortcuts.

ARGUS, operating at institutional scale, is increasingly being integrated with project management and programme data sources. For development funds and institutional developers running large portfolios, the ability to pull live programme data into ARGUS feasibility models — rather than relying on static point-in-time assumptions — is becoming a competitive and risk-management necessity.

The Analyst's Responsibility: Sequencing Rigour as Professional Standard

Platforms can only go so far. The responsibility for sequencing discipline ultimately sits with the analyst.

Here is a practical framework for elevating sequencing rigour in feasibility practice:

Engage the builder or project manager before finalising the programme. Indicative programmes from architects are starting points, not reliable inputs. A preliminary construction programme from a principal contractor — even indicative — is exponentially more credible.

Model at least three sequencing scenarios. Base case, a delayed-start variant (accounting for approvals slippage), and an extended-duration variant (accounting for construction market conditions). Most feasibility platforms — including all four covered here — can accommodate scenario toggling. Use it.

Reconcile your draw-down curve to your programme phases. Don't apply a generic S-curve. Map your cost profile to the actual work breakdown: civil/structure/services/fit-out. If using EstateMaster or FeasibilityPro.AI, use their staging tools to reflect this.

Document your sequencing assumptions explicitly. Every feasibility report should include a sequencing assumption schedule — what milestones were assumed, on what basis, and what the sensitivity is to delays. This is basic professional hygiene that is still, surprisingly, not universal practice.

The Bottom Line

The construction sector is entering a period where feasibility accuracy is under more scrutiny than ever — from lenders, from JV partners, from planning authorities, and from investors who have been burned by projects that looked good on paper and failed on programme.

The tools exist to do this better. FeasibilityPro.AI, ARGUS, EstateMaster, and APRAO all offer functionality that — when used with genuine sequencing rigour — can produce feasibility outputs that are robust, defensible, and operationally grounded.

The question is whether the industry will treat construction sequencing assumptions with the seriousness they deserve, or continue to treat them as background noise in a model that is only as good as its least scrutinised input.

The answer to that question is a strategic choice — and increasingly, a competitive one.

Have you encountered sequencing assumption failures on real projects? Share your experience in the comments — this conversation matters across the industry.

Top 5 Feasibility Analysis Tools for Real Estate (2026)

Real Estate Hub — Thu, 09 Apr 2026 06:12:03 +0000

If you’re building or working in proptech, feasibility isn’t just finance — it’s a system problem.

You’re dealing with:

time-series cash flows
scenario simulation
dependency-heavy inputs
decision outputs (IRR, NPV, risk)

Here are the tools that actually matter 👇

1. Feasibility.pro

Use when: you need a real feasibility engine, not a spreadsheet

What it does well:

IRR, NPV, cash flow modeling
multi-scenario simulation (cost, time, pricing)
live recalculation as inputs change

Why devs care:

behaves like a system, not a file
good for integrating feasibility into workflows

2. ARGUS Enterprise

Use when: you’re dealing with institutional/commercial assets

What it does well:

lease modeling
valuation
portfolio-level analysis

Limitations:

not ideal for early-stage development feasibility
less flexible for scenario experimentation

3. EstateMaster

Use when: you want structured feasibility without building from scratch

What it does well:

detailed development feasibility
project comparison
structured workflows

Feels like:

Excel, but more controlled

4. Procore

Use when: you need execution data (not feasibility itself)

What it does well:

cost tracking
project progress
contract management

Important:

doesn’t calculate IRR/NPV
but provides real data that should feed feasibility models

5. Microsoft Excel

Use when: you’re prototyping or doing quick analysis

What it does well:

full flexibility
easy to start

Where it breaks:

multi-scenario modeling
version control
scaling across projects

TL;DR for Developers

Excel → flexible but fragile
EstateMaster → structured but limited
ARGUS → strong for valuation
Procore → execution layer
Feasibility.pro → closest to a feasibility system

Real Shift Happening

Feasibility is moving from:

Spreadsheets → Tools → Systems

If you’re building in proptech, feasibility should sit as a core computation layer, not a side document.