Methodology: how DevPartner calculates, and what it will not claim
A feasibility is only as trustworthy as the discipline behind it. This page sets out how DevPartner computes, what is user-stated versus engine-derived, how runs and report versions work, and the limitations we would rather state plainly than hide in a footnote.
1. The engine is deterministic
Given the same inputs and the same engine version, DevPartner returns the same outputs — every time, for every user. There is no sampling, no model inference and no hidden adjustment inside the calculation chain. That property is what makes a result defensible: two people can reopen the same run months apart and see identical numbers.
inputs (all user-stated) -> planning capacity : buildable and saleable area, yield, parking -> cost build-up : construction, fees, statutory, external, contingency -> revenue : mix x rate, phased by absorption -> programme : approvals, construction, sales -> cash flow : peak funding and finance cost -> structure : outright / area share / revenue share on one base -> decision : verdict against your stated criteria outputs (each traceable to the inputs above + an engine version)
2. What is stated, what is derived
| Category | Source | Examples |
|---|---|---|
| Site facts | You | Extent, frontage, access, deductions, ownership position |
| Planning inputs | You, from the competent authority or your consultant | FSI components, coverage, setbacks, parking norm |
| Cost rates | You, from your own contracts and recent projects | Construction rate, basement rate, statutory rate |
| Market inputs | You, from transaction evidence | Sales rate, absorption, other revenue |
| Deal terms | You | Asking price, share percentages, deposit |
| All computed outputs | The deterministic engine | Saleable area, GDV, cost total, residual, margin, verdict |
DevPartner does not ship a national database of planning rules or market rates and does not infer one. Where a value is unknown, the analysis reports a gap rather than inventing a figure that would look authoritative and be wrong.
3. Runs, staleness and frozen versions
- A run is immutable. It records the inputs it consumed, the engine version that computed them and the outputs produced.
- Changing an assumption marks the run stale. Nothing is recomputed behind a report you have already circulated.
- A report version is frozen. Once created it reopens unchanged, which is what makes it usable in an investment committee or a negotiation months later.
- Every metric can be traced. The trace shows the inputs and the arithmetic that produced the figure on screen.
4. Ranges, not single points
A single-point answer implies a precision no development appraisal has. DevPartner presents scenarios and a sensitivity grid across the two drivers that move the result most — typically the achievable sales rate and total development cost — so the decision is made against a range with named drivers.
5. The free calculators are deliberately simpler
The public tools — FSI / FAR, development potential, construction cost, residual land value and joint development — are single-page models, separate from the workspace engine. They do not phase a programme, model drawdown or compare structures across a cash flow. Their starting values are visible placeholders you are expected to replace, never a statement of what applies to your site.
6. Known limitations
- No statutory rule database; planning inputs are yours to verify.
- No market data feed; rates and absorption are yours to evidence.
- No title, encumbrance, litigation or environmental due diligence.
- No tax, GST or stamp-duty computation beyond the figures you enter.
- Outputs are decision support, not a valuation or an approval.
Related reading
- Land feasibility
The seven-step sequence a full feasibility follows.
- Developer feasibility
The viability measures and how each is calculated.
- Sample decision report
What a frozen, traceable decision report contains.
- Disclaimer
The formal limits on how DevPartner output may be used.
Frequently asked questions
- Does DevPartner use AI to calculate feasibility?
- No. Every number is produced by a deterministic engine: the same inputs and the same engine version always produce the same outputs. Language models are used only to explain, summarise or extract — never to compute, and never to alter a calculated result.
- Where do the default values come from?
- The free calculators open with clearly visible starting values so the page is usable immediately; they are illustrative placeholders, not market rates or statutory rules. In the workspace, no material assumption is invented — if a value is missing, the run reports it as a gap rather than filling it.
- Does DevPartner know the planning rules for my city?
- It does not claim statutory coverage of every Indian authority, and it will not pretend otherwise. FSI, coverage, setbacks, parking norms, premium and betterment charges are inputs you set from what the competent authority or your planning consultant confirms.
- What happens when I change an assumption after running an analysis?
- The existing run is not silently recomputed. It is marked stale, and the earlier run remains readable exactly as it was. You re-run deliberately, which is what keeps a circulated report auditable.
- Is a DevPartner report a valuation?
- No. It is decision support built from your assumptions. It is not a valuation, an audit, a statutory approval, a lender's appraisal, investment advice or a legal opinion, and it should not be presented as any of those.
Take this from a calculator to a decision
A single-page calculator cannot phase a programme, model cash flow, compare structures on one base or freeze a report. DevPartner's deterministic engine does — with every assumption traced back to the value you entered.