An early development underwriting report should disclose what is being tested, where each important input came from, and which assumptions could change the decision. It should let a reviewer trace the proposed layout through area, cost, revenue and timing without treating unresolved inputs as facts.
This is a review framework we propose for early site work. It is not a lender's document checklist, a valuation standard or a promise that a project is ready for finance.
Start with the site and the decision
Name the site boundary, intended use and scenario being reviewed. State whether the decision is to investigate further, compare options or commit more work to a defined proposal.
A report for a first land screen should not look like a completed acquisition review. If the boundary is approximate or the project brief may change, put that on the first page. The detail that follows must carry the same limit.
Show where the inputs came from
Attach a source, checked date and evidence status to each input that could change the result. Separate a verified record from a working assumption or an unresolved question.
For an Indian site, that may involve the relevant state, city and project documents. For a US site, it may involve the local ordinance, official map and site-specific conditions. These are examples of evidence to check, not a universal legal checklist. The sources must match the actual location.
A link alone is not enough. Record the section or condition used and explain how it affects the scenario. If the team has not checked the source, say so.
Keep area definitions separate
Show the land area, permitted counted floor area, achieved layout area and saleable or lettable area separately. Explain each conversion used in the financial model.
A floor-area allowance is not the same as a physical fit. A physically possible layout is not automatically the area that can be sold or leased. When the model changes from one area basis to another, the report should make that change visible.
State the cost and revenue basis
Label each rate as a quote, a dated benchmark or a modelling assumption. State what is included, what is excluded and which area or quantity the rate is applied to.
A construction rate without its area basis is hard to review. A revenue rate without a defined product and saleable area has the same problem. Keep finance, fees, contingencies and other project assumptions visible rather than hiding them inside one total.
This checklist supplies no default rates. The team must establish appropriate inputs for its own site and scope.
Connect timing to cash
Show when costs are expected to be paid and when receipts are assumed to arrive. State which start, approval, construction and sale or lease dates are assumptions.
A scenario can have the same total cost and revenue as another but a different funding need because the cash arrives later. Let the reviewer see the timing used rather than only the final return figure.
Show what could change the choice
Test the inputs most likely to alter the decision and identify the next fact worth verifying. Explain whether the preferred option remains useful when those assumptions change.
The aim is not to print every possible sensitivity. It is to reveal the assumptions holding up the current conclusion. If access, achievable area or a cost quote is still unresolved, name the person or evidence needed to close that gap.
Use the report to choose the next check
End with a decision, the evidence behind it and a dated next action. Keep the report preliminary when important checks remain open.
Keystone AEC connects site inputs, planning options, unit mix, estimated costs, timeline, feasibility and underwriting for early development review in India and the USA. Bring a site boundary and the decision you need to make; the useful first conversation is about what the evidence can support.
See the boundary-to-scenario workflow and how to keep unknown inputs visible.