How automated feasibility helps developers compare sites faster

A Mombasa developer evaluating sites in Nyali, Bamburi, and Shanzu faces the same questions for each: What can I build here? What will it cost per square metre? What rent can I expect? Do the numbers clear the return threshold? Traditional feasibility means three separate spreadsheet models, three sets of assumptions that drift apart between versions, and a week of consultant time per site before the developer even knows which parcel to focus on.

REDM automated feasibility tools collapse this to hours. Each site runs through the same model with the same cost benchmarks from the REDM costbook and the same rental assumptions from the market module. The developer sees at a glance which site clears the IRR threshold, which is marginal, and which fails on zoning or ground coverage before a shilling is spent on detailed consultant fees.

The difference is structural: manual feasibility compares sites on different assumptions because each spreadsheet was built at a different time by a different person. Automated feasibility compares sites on the same assumptions because the model is shared. When a developer presents three sites to the board with confidence that the comparison is apples-to-apples, the quality of the investment decision rises materially.

Every experienced Kenyan developer has a feasibility spreadsheet. It lives on the managing director's laptop, was last updated two months ago, and references construction rates from a QS report that nobody can find. The problem is not the spreadsheet itself; it is that each new project gets a new spreadsheet, assumptions drift between versions, and six months later nobody remembers why the rental rate was set at KES 45,000 per unit or why the finance cost assumption is 14 percent.

When assumptions are not documented and linked to source data, feasibility becomes advocacy rather than analysis. The developer wants the project to work, so the assumptions drift toward optimism. By the time the board sees the numbers, the feasibility is a sales pitch dressed as a financial model. Automated feasibility tools solve this by tying every assumption to a named, versioned source: the REDM costbook for construction rates, the market module for rental benchmarks, county GIS for plot coverage limits, and professional fee schedules from the service catalog.

A developer using REDM can test optimistic, base-case, and conservative assumptions on the same site and compare them side by side. The tool remembers what was assumed and why. Six months later, when construction costs have risen, the developer can reload the feasibility, update the cost assumption, and see the impact immediately. No rebuilding the model from scratch. No guessing what the original numbers were.

The most valuable question in feasibility is 'what if.' What if construction costs rise 15 percent because cement prices spike? What if the rental market softens and units achieve KES 35,000 instead of KES 45,000? What if we build a hotel instead of apartments on this parcel? What if we reduce the unit count but increase unit size for a different market segment? Manual feasibility makes these questions painful; each 'what if' means rebuilding the model or creating yet another spreadsheet tab.

REDM feasibility wizard answers them in real time. Change the building type from apartments to hotel and the tool recalculates coverage limits, parking ratios, cost benchmarks, and rental assumptions instantly. Adjust the unit mix, modify the construction cost assumption, change the finance rate, and every downstream calculation updates. A developer can test five scenarios in an hour and arrive at a board meeting with evidence, not just conviction.

This is not theoretical. On a Mombasa coastal parcel, the difference between apartment development and hotel development is the difference between long-term lease revenue and nightly room revenue; between residential parking ratios and hospitality drop-off requirements; between one set of county approval triggers and another. Manual feasibility makes comparing these two paths a two-week exercise. Automated feasibility makes it a five-minute toggle. The developer who can test more scenarios makes better capital allocation decisions. Reference the construction-costs-kenya-mombasa-2026 article for current cost benchmarks by building type.

Automated feasibility does not make the investment decision. It makes the decision criteria visible, consistent, and comparable across projects. A developer can set explicit go/no-go thresholds in REDM: unlevered IRR above 18 percent, equity multiple above 2.0x, peak debt below 70 percent of gross development value, profit on cost above 20 percent. The tool flags which sites clear the threshold, which are marginal, and which fail.

This removes the emotional attachment to a site that 'feels right' but does not work financially. Every experienced developer has a story about the parcel they loved that the numbers killed. Automated feasibility kills it faster, cheaper, and with evidence the board can review. The developer moves on to the next site with time and capital preserved.

For developers managing multiple projects, this is portfolio-level discipline. The REDM project file carries feasibility assumptions through to design, construction, and asset management stages, so the original investment thesis remains visible throughout the lifecycle. When the project delivers, the board can compare actual returns to the feasibility that approved the investment. That closed feedback loop sharpens every subsequent feasibility. Reference the IRR-equity-real-estate-kenya and NOI-and-property-economics-kenya articles for metric definitions and the financial-modelling-property-development-kenya article for the full methodology.

Automated feasibility covers what can be modelled: construction costs, rental revenues, development timelines, plot coverage, parking requirements, professional fees, finance costs, and basic return metrics. It does not cover what requires human judgment: political risk in the host county, community opposition to the development, title disputes that GIS cannot detect, contractor reliability, or market timing.

These remain the developer's domain, supported by the professional team the developer appoints. The architect assesses site constraints that spatial data misses. The QS validates cost assumptions against current tender returns. The lawyer confirms title. The developer reads the market. Automated feasibility provides the financial scaffold; the developer and the professional team provide the wisdom to interpret it.

The most dangerous feasibility is the one that looks precise because a computer produced it, but rests on assumptions the developer never questioned. REDM makes assumptions visible, traceable, and changeable. That visibility is the real value of automation: not that a machine decided, but that the developer can see exactly what the decision rests on and test alternatives before committing capital.

Run the REDM parcel tool on any address or plot number you are considering. If the site passes zoning and flood screening, move to the feasibility wizard. It connects parcel constraints to construction costs, rental assumptions, and go/no-go thresholds in one workflow. Test at least three scenarios on your shortlisted sites before commissioning detailed consultant feasibility studies.

Document every assumption in the REDM project file: cost per square metre, rental rate per unit, finance rate, absorption period. When your board or lender asks 'why these numbers,' the answer is in the file, not in your memory.

Present feasibility comparisons as a table: site A versus site B versus site C, same assumptions, same metrics, same date. The board should see the comparison, not three separate models stapled together. REDM generates this comparison view from the linked project files.

Pair this guide with the feasibility study article for what a full feasibility covers, the financial modelling article for the methodology behind the metrics, and the construction costs article for current Mombasa benchmarks. The how-REDM-turns-a-plot-check-into-a-project-file article shows the end-to-end tool chain from parcel to project.

Before the next fee milestone, confirm who signs, who certifies, and who records, then hold one coordination meeting with minutes. Developers who rely on informal email trails pay twice: once for rework and once for dispute advice.