Development Feasibility Software Problems: The 7 That Cost Developers Real Money, and How to Avoid Them

Why does the appraisal convention problem get skipped in scoping?

Residual valuation is not complicated arithmetic. Gross development value, less construction, less professional fees, less finance, less the profit requirement, gives what you can pay for the land. Everyone in the room agrees on that, so the requirements document says build our appraisal model and the project starts.

The difficulty is that every input carries a convention. Whether contingency sits on construction only or on the whole cost base. Whether finance is calculated on a rolled up facility or a monthly balance. Whether the profit requirement is on cost or on gross development value. Whether acquisition costs sit inside or outside the residual. In a spreadsheet culture those conventions live in whichever file got copied, so your firm has several dialects and nobody has written them down.

The failure is not that the software gets built wrong. It is that it gets built to whichever appraisal was handed over as the reference, and six months later a director says that is not how we do finance. The engine is reworked, historical comparisons become meaningless, and the committee returns to arguing about method rather than assumptions.

The fix is unglamorous and is the highest return decision in the whole build. Before anyone writes code, get your senior people in a room and agree one house standard, then name it and version it. The engine applies it identically to every scheme and shows the derivation line by line with the convention cited. Analysts can still run an alternative convention deliberately, and the output labels it as such. Firms that arrive at a build with a documented standard and a worked example move noticeably faster, and the ones that do not should budget several weeks of genuine debate as project time rather than pretending it is a software task.

What goes wrong when you bring historical appraisals into a new system?

Developers assume the back catalogue comes across because the numbers exist. The numbers exist. The reasoning does not.

What is actually in the archive: files where the tab holding the debt calculation contains a hardcoded number nobody remembers typing. Cost rates taken from a quantity surveyor's email with no date, so you cannot tell whether a scheme was appraised on current or year old rates. Sales values entered as a blended figure per unit type, making the mix impossible to reconstruct. Land consideration reduced to a day zero payment when the actual deal had a deferred element on consent. And files that kept being edited after the committee approved a version nobody locked.

The consequence is that your calibration data is unreliable exactly when you want it most. A properly built system should set sensitivity ranges from your own delivery record, because a firm that consistently comes in over budget by a given margin should run sensitivity around that margin rather than around zero. If the archive cannot tell you what was appraised versus what was delivered, that capability is unavailable for years.

The fix is to migrate selectively. Take the schemes that completed, capture the approved appraisal and the delivered outturn as a matched pair, and accept that anything you cannot reconcile stays as a stored document. From day one of the new system, lock the committee output as an immutable version so the forward archive is trustworthy. Do not attempt to structure a decade of spreadsheets, because the effort is enormous and the result is still an approximation.

Why do the cost management and accounting integrations break after launch?

Keeping the appraisal live through delivery is where a build usually pays for itself, and it depends entirely on an integration that is fiddlier than it looks.

The problem is that the appraisal cost lines and the contractor or quantity surveyor cost breakdown structure do not agree, and were never meant to. Your appraisal has a line for substructure. The cost report has forty. Provisional sums resolve into different lines later, variations arrive with their own coding, and retention and payment applications move money on different dates from the ones the appraisal assumed. Sales are tracked by a different team with its own idea of when a sale is a sale, whether that is reservation, exchange or completion.

What breaks after launch is the mapping. It is agreed once at implementation against whichever cost breakdown the running scheme used, and the next contractor uses a different one. Or a variation creates a cost line that maps to nothing, so the variance report quietly excludes it and the forecast looks better than it is.

The fix is to treat the mapping as maintained configuration with an owner rather than a one time implementation task, and to make unmapped items an exception somebody resolves rather than a silent exclusion. Define sale recognition once and use that definition in the appraisal, the cashflow and the report. The headline then becomes one line: appraised profit on cost against current forecast, with the variances named. Feeding actual absorption back into the cashflow surfaces slippage as finance cost immediately rather than at year end.

What happens when structured land consideration is not covered?

The headline land price is frequently the least interesting part of the deal, and it is the only part generic models represent properly.

Real deals carry a deferred payment on planning consent, an overage clause paying the landowner a share of value above a threshold, an equalisation arrangement across multiple owners, or a landowner taking equity instead of cash. Every one gets approximated as a manual adjustment, and the approximation is precisely where value is created and destroyed. A deferred payment on consent transforms the finance profile and the equity requirement, and an overage clause can quietly take most of the upside you thought you were bidding for.

The same applies on the capital side. If you have an equity partner with a preferred return, a catch up and a promote, that partner will model the waterfall exactly, and you should not be the party working from rougher numbers.

The fix is to make land consideration a structured set of payment events with triggers: date based, milestone based such as consent or first completion, and formula based such as a share of value above a threshold. Each flows into the cashflow when it triggers, so the model values the actual deal rather than a simplified one. Equity waterfalls get modelled as tiers rather than as a percentage split. Ask any prospective developer to whiteboard an overage clause and a consent triggered deferred payment before you discuss price, because the answer tells you immediately whether they have built this before.

Should you build custom or configure what you already own?

If you run fewer than about 10 appraisals a year, or build one product type in one market with conventional freehold land purchases, do not build. Altus ARGUS Developer is a defensible industry standard that lenders and valuers recognise, which carries real value when you are raising debt, and it imposes consistency, which is exactly what a firm with a spreadsheet problem needs. If your main pain is version control and collaboration rather than structural modelling gaps, Feasly solves that more cheaply than a build will.

TestFit is worth buying regardless of what else you do. Massing and yield studies are a different problem and it solves that one well, and feeding a yield study straight into an appraisal turns a scheme change into a land value in minutes rather than a day.

The tipping point for building is deal structure complexity, not volume. A developer doing eight highly structured land deals a year has a stronger case than one doing forty clean freehold purchases, because the value of the build is in expressing exactly what the spreadsheet approximates. The other triggers are multiple jurisdictions with different obligation regimes, capital partners whose waterfall you must model precisely, and wanting the appraisal to remain the baseline through delivery.

How do hidden costs get into the quote?

• Product type count. Build to rent, build to sell, student, senior living and commercial have genuinely different revenue and valuation mechanics. Each is real scope, not a setting.
• Jurisdictions. Affordable housing obligations, planning contributions, land taxes and sales tax treatment are local and do not generalise. Two markets is more than twice one market.
• Joint venture and fund structures. Waterfall logic with preferred return, catch up and multiple promote tiers can be as complex as the appraisal engine itself.
• Cost and accounting integration. This is what makes live tracking work and it is the fiddliest interface in the project, with an ongoing mapping burden rather than a one time cost.
• Convention debt. The weeks your senior people take to agree one house standard is real project time, and it cannot be outsourced.
• Sensitivity calibration. Deriving input ranges from your delivery record requires matched appraised and delivered pairs to exist, which usually means a data exercise first.

What separates a build that works from one that fails here?

The ones that work make comparison the primary use, not a report. One opportunity carries a shared assumption set, and variants override only what differs, so changing a cost rate once updates every variant. The comparison view puts residual land value, profit on cost, peak equity, peak debt and programme side by side, which is the table a committee wants and rarely gets. Phasing is modelled as real timing on the cashflow rather than as an average, because it changes peak debt, which changes finance cost, which changes the residual. An appraisal that reports profit without reporting peak equity is answering half the question.

They also make the committee output immutable. What was approved, on which assumptions, under which convention version, locked and retrievable. That single discipline removes the most common argument in a development business six months after a decision.

And they replace the two variable sensitivity grid with something usable. Vary every input across a defined range, rank by impact on residual land value and equity return, and express the answer as break even thresholds a person can hold in their head. Price against cost grids hold everything else static and usually understate the assumptions carrying the real risk, which are typically absorption, planning outcome and finance cost.

The ones that fail build a calculator with the firm's terminology on the screens and none of its logic inside. Ask a prospective developer to explain residual land value back to you before they quote, including where finance and profit interact and why profit on cost and profit on gross development value give different answers. If they cannot, they will build you an expensive spreadsheet with a login.