Civil Analytics
An AI platform that tells you what can be built on a piece of land, before you hire anyone.
Role
Product designer
Industry
Real estate, AI product design
01 / OVERVIEW
Finding out what you can legally and profitably build on a site takes months and a roster of expensive consultants.
Before anyone breaks ground — or even buys a parcel — someone has to answer a stack of questions: What does zoning permit here? What are the setbacks and height limits? What will construction actually cost? Is the return worth it? Getting those answers conventionally means engaging architects, engineers and planning consultants, and waiting.
Civil Analytics set out to compress that. The product gathers jurisdictional data, site conditions and building codes, analyses what can be built on a specific parcel, and returns a structured feasibility report with cost estimates, zoning constraints, sustainability guidance and a 3D visualisation of the potential development — reducing a months-long process to days or minutes depending on project size, and letting users understand what's possible before they commit to consultants.
The users: property developers, real estate agents, and individuals who want to build.
02 / THE PROBLEM
We started by mapping the problem space properly, before anyone drew a screen.
I ran a product definition workshop with the founding team covering the core proposition, the problems we were solving, the ideas on the table, the product vision, and the specific pains we'd eliminate.
01 — Inefficient resource allocation
Over- or under-utilisation of materials and labour, causing delays or inflated costs
02 — Budget overruns and delays driven by inaccurate forecasting
03 — Fluctuating material costs, tracked and predicted manually
04 — No real-time data on material prices and availability
05 — Manual, disjointed processes — project managers relying on multiple tools, spreadsheets and hand-entered data to track progress, produce status reports, and communicate with contractors, suppliers and clients
Managing large-scale development is complex and costly when you face unpredictable costs, inefficient resource allocation, manual tracking, and compliance uncertainty.
Three-step system model: get the data source → identify system and user prompts → generate the report.
03 / PRIORITISATION
The workshop produced 7 feature categories. Shipping all of them would have produced nothing.
The prioritisation workshop laid out the full ambition across seven areas: cost forecasting and budgeting, resource allocation and management, project planning and tracking, material sourcing and procurement, risk management and predictive analysis, investment and ROI analysis, and user experience and collaboration — roughly two dozen features between them, from Gantt charts and automated purchase orders to a supplier marketplace and role-based access control.
So we cut to the one thing a user could get value from on day one: tell me what I can build here.
Of all the ideas on the board, land development feasibility was the only one that delivered standalone value without requiring the user to already be running a project on the platform. Cost forecasting needs a live project. Resource allocation needs a team in the system. Procurement needs suppliers onboarded. Feasibility analysis needs nothing but a parcel and a question — which makes it the only viable entry point.
That reframed the MVP entirely: not a construction management platform, but a feasibility engine — with three report types as the product surface:
Feasibility and Zoning Report
Environmental and Sustainability Analysis
Full Design and Development Report
04 / DESIGN DECISIONS
The parcel comes before the conversation, because everything downstream depends on it.
The user searches by location or zip code, sees candidate parcels highlighted against the cadastral map, and selects one — at which point the system knows its acreage and can proceed.
05 / CONVERSATION PLANNING
Repair & failure matrix
07 / REFLECTION
Reflection
Designing the intake sequence was straightforward. Designing what happens when the user is vague, contradicts themselves, or asks for something the zoning code forbids is where the actual product lives — and it's where an AI feature either earns trust or quietly loses it.