The interface argument is the surface. The unit of work moves from a file to a query, and when that flips the whole category resets.
Most conversations about “the future of feasibility software” are conversations about user interface. Better dashboards, cleaner inputs, nicer charts, mobile views. These are surface conversations. The actual transition underway in this category is architectural, not visual. The unit of analytical work is moving from a file (the spreadsheet, saved, versioned, emailed) to a query (a question asked of a system that holds the institutional context). When that flip completes, every property of the category, the workflow, the deliverables, the team structure, the buying behaviour, resets to a new equilibrium. The vendors and the developers who recognise this early have a window of advantage that closes within roughly 36 months.
The file-to-query paradigm shift
A file is a static container. It holds a state of analysis at a moment in time. To use it, you open it, modify it, save it, send it. Every interaction is a complete handling of the entire artefact. Files do not naturally compose, do not naturally version, do not naturally surface their own metadata. They are the analytical equivalent of paper.
A query is a question asked of a system. The system holds the underlying context (assumptions, comparables, market data, project history, institutional memory). The query returns the relevant slice. The next query refines the answer. The querying interaction is incremental, conversational, and traceable. Each query and its answer can be saved, versioned, audited, and combined with others.
The analytical capability of “show me the IRR of this project under the following six combined sensitivities” is trivial as a query and onerous as a file operation. Multiply this gap across the dozens of analytical questions that get asked in a real feasibility cycle and the productivity, accuracy, and defensibility difference is structural. The category has not yet absorbed this because the dominant tools are still file-based and the operators have adapted to the constraints of files.
What querying assumptions means in practice
In practice, the querying paradigm changes the daily work of an analyst in three observable ways.
First, the analyst stops opening “the file” and starts opening “the project”. The project is a system state, not a document. They ask the project for the current feasibility view. They modify the assumption that needs revisiting. They ask for the impact across linked metrics. The work is conversational, not document-handling.
Second, sensitivity stops being a pre-computed table and becomes an ongoing dialogue with the system. The analyst asks “what is the breakeven sales velocity holding cost ratio constant” and the system returns the answer, sourced. The next question builds on the last. The analytical density of a one-hour session multiplies by a factor that is hard to communicate to anyone who has not seen it.
Third, the deliverable to the investment committee is generated from the system, not constructed manually from the file. The committee sees the same view the analyst sees. Their challenges are answered live. The analyst is not the interpreter between the file and the room. The system is.
The institutional memory angle
The deeper consequence of the query paradigm is institutional memory. A file-based feasibility carries no memory beyond the file itself. The reasoning, the comparables consulted, the challenges raised, all of this lives outside the file. When the senior analyst leaves, the institutional context that makes their feasibilities trustworthy leaves with them. Every developer in this region has experienced this and treats it as inevitable.
A query-based feasibility carries memory in the system. The reasoning is captured. The comparables are linked. The challenges are recorded. The institutional context survives the departure of any individual. New analysts onboard against a system that already knows what the firm knows. The firm’s analytical sophistication compounds over time instead of resetting whenever a senior person changes employer.
This single property is, in my view, the most valuable consequence of the transition, and it is the one least visible from outside the workflow.
How the new UX flows from the architecture
Once the architecture is right, the user experience is downstream. The interface looks different from a spreadsheet not because designers decided to make it look different, but because the underlying paradigm requires different affordances. There are conversational input fields. There are query histories. There are surfaceable assumption objects. There are scenario explorers. None of these are imposed UI choices. They are the natural surfaces of a queryable system.
This is why “AI-enhanced Excel” is a category dead-end. The architecture is wrong. No amount of UI polish on a file-based system produces the affordances of a query-based system. The same logic explains why the current generation of AI-bolted-on PropTech tools is going to be replaced by a different generation of AI-native tools, and why the rebuild cost is high enough that the bolted-on vendors will resist acknowledging the transition until it is too late.
What this means for development teams
The teams that adopt query-based feasibility in 2026 and 2027 will operate differently from peers within twelve months. They will run more deals. They will challenge each deal more rigorously. They will produce decision packs that look obviously stronger than peer decision packs. Their CFOs will defend feasibility outputs with confidence that the file-based peers cannot match.
The team structure will adjust. Senior analysts will stop being template custodians and start being interrogators of the system. Junior analysts will be productive faster because they are not reconstructing the firm’s logic from scratch. The team produces more, with smaller headcount, at higher quality. This is not a cost-reduction story; it is a capability-expansion story. The same team becomes structurally more capable.
The early adopter advantage in this transition
There are roughly 36 months between now and when query-based feasibility becomes the regional standard. The developers who adopt early will compound an advantage. The developers who adopt late will pay the rebuild cost in a market where their competitors have already absorbed it. The decision to adopt is not primarily a software-purchase decision. It is an operating-model decision. The leadership commitment required is comparable to the commitment required when ERP systems came in 25 years ago. The firms that took ERP seriously in 2000 outpaced the firms that did not for the following decade. The same dynamic is repeating for feasibility tooling now.
I have spent the last two years close to one specific instance of this transition, working as a consultant on a feasibility platform that has approached the architecture problem at the layer I have been describing. I am not going to name it in this post. I will say that the developers who are paying attention to which tools are file-based and which are query-based, in this specific window, will identify the transition before the market does. That identification, in itself, is worth the read of this post.
Something is coming in this category that is not Excel and is not previous-generation feasibility software. The teams that are early on the transition will look, in three years, like they were running a different game from peers. From inside 2026 it will look like a tooling decision. From 2029 it will look like a strategic one.
Related Reading
- the Excel problem
- why most PropTech fails at the architecture level
- the operator’s case for AI-first feasibility
- the two-model AI workflow that sits underneath it
Key Takeaway
The next generation of real estate feasibility software will not look like Excel with a better UI. It will look like a decision co-pilot with scenario memory, AI-assisted assumptions, and an audit trail by default. The shift is architectural, not cosmetic.
Frequently Asked Questions
What does next generation real estate feasibility software look like?
It looks like a decision co-pilot rather than a calculator. Scenarios are versioned and comparable by default. Assumptions are surfaced and challenged by AI. The output is a defensible decision pack, not a 40-tab spreadsheet.
How is this different from existing feasibility tools?
Existing tools largely replicate Excel inside a web interface. The next generation rethinks the workflow around scenario velocity and decision speed, with AI handling the mechanical steps and the operator focusing on judgement.
When will GCC developers adopt this category?
Adoption typically follows two triggers: a board-level audit finding on Excel-based underwriting risk, or a competitor closing deals faster on the same data. The first trigger is already happening across the GCC.
Naumaan Khan is a Digital Growth and Transformation consultant in Muscat, Oman. He builds AI-native growth systems for enterprise organisations across the GCC.