The Lots Co Project

First of all, did it? Short answer – yes. Has it changed the world? …

Lots Co is a tech company concentrating on a range of residential development tools. These tools re-vision the development process at smaller scales, removing risk by achieving certainty, accelerating timelines, creating quality. Although transitioning to a B2B service, it has also created a front-facing platform (lotsco.nz) aimed at customers with little or no development experience. By virtue of its unparalleled feasibility accuracy, other real use-cases for the tech have also evolved over the last few years – valuation validation (for purchase, lending, sales) and testing of court evidence.

The Lots Co business model was to initially pitch directly to non-professional property owners, de-risking and providing them the support to engage in the development of their land directly (see lotsco.nz). As the feature-set was built out, their business model has shifted to a B2B service, white-labelling to group-housing companies, survey/engineering/planning consultancies, architects, developers, real-estate agencies…

The Lots Co Project

The Lots Co origin story can be found in discussions among a group of planners and infrastructure consultants at Auckland Council just after the launch of the Auckland Unitary Plan in 2016. Realising the AUP might open up a flood of cheap, low-amenity infill housing and knowing Common Ground’s work in medium-density design tools, the idea was hatched of developing a technology that could, by its approach, deliver better outcomes.

To us it was a systems problem. The spatial slack of large sites provides the buffer for a slower evolution of the business model and scheme. When you’re down to the last 100mm on a small site there’s none of that. You have to get it right before you start. Therefore, you need a different system for development, at least for the time through to construction.

We framed the core issue for this kind of development as risk. With no room to move, risk should be inversely ordered against cost as a linear sequence. The greatest risk should be settled for the least cost in the shortest time. A small-scale system asks four questions. Each must be answered in order, and the answer must be emphatic, or you shouldn’t progress:

1. • Is the site even developable? (Can you develop?)
   • What is the best business case for development? (What should you develop, is it feasible?)
   • Will the development get a consent?
   • Is the development able to be funded? (Can you get funding?)

Just as task order is critical, it’s vital that answers are received quickly, at low cost, and with a very high degree of accuracy. Flow-chart the process and two massive stumbling blocks crop up at the second step.

Most designers can quickly generate ‘a’ development scheme that experience tells them will be quite good, but the industry simply cannot afford to repeat this process half a dozen times to determine the ‘best’ possible scheme – best is often not the biggest. The first thing we needed to do therefore, was design a different design system.

The second thing we needed was to know exactly how much everything would cost – but before we’d actually designed it!

So this framed Common Ground’s brief. A design system was required that:

• Was fast, highly adaptive, and cost almost nothing
• Was extremely light and easy to use
• Contained significant explicit content detail
• Was capable of object property quantification and linking within a data and cost framework
• Could drive design expression in later project tasks and correctly anticipate the data outputs from them
• Could produce graphic output for use in the app

A primary data engine, in other words. Written out like that, it didn’t seem too hard of an ask. Building a highly accurate and complete feasibility modeller in behind it, well, that was a totally different matter. And thank goodness, not our job.

The project was structured in three parts:

• Design Engine
• Feasibility Modeller
• Development Manager

The Design Engine

This is Common Ground’s main contribution to the project. A principle of medium-density development is to always to design the buildings first, then construct the lot plan around them. We already had design tech to do that, used in-house for large-scale masterplanning projects. Extending that for a slightly different purpose was ‘relatively’ trivial, taking only 3—4 months for the first working version. What needed to be added was:

• The correct Typology as a classing structure
• Actual building designs for the primary Type set
• A system for Type variations
• All planning control geometry embedded in the 2D/3D building models
• A data format for consent compliance reporting
• A data format for site design
• A redesigned record format to report all data required for development modelling and decision-making
• A compatible interface with a back-of-house development modeller

The end result is our most complete iteration so far of a typology design model. A more detailed general description of typology modelling can be found here – Typology Design.

We were also interested in whether Lots Co services could be generalised for larger developments. In 2019 we got the opportunity to test it on a 110-lot scheme (see Aeronautic). The answer there was a resounding ‘Yes’, the whole project being completed in a staggeringly short 50hrs.

The Feasibility Modeller

There are, broadly speaking, three levels of feasibility calculation in the industry:

• The Thumb Suck (intuition, or the envelope back)
• The Bulk & Location (full of PC sums, near enough is good enough)
• The (Actual) Development Model (after consent, detailed design and once all contracts are in and all costs locked down)

The Lots Co aim was to achieve the certainty of the last stage at the level of the Thumb Suck. In other words, how do you get all the cost information of design detail without actually having a design?

Most of the answer to that (seemingly nonsensical) question lies in the achievable granularity of data and the extent drivers can be linked to data – especially when links may be multiply contingent.

For task and item costing it means everything must be identified and valued. The obvious exception is civils’ costs which you only really know after the first scrape of the digger. The saviour in this has been one of Lots Co’s development partners – MainBridge Civil. They’ve developed a (somewhat mysterious to us) Thumb Suck calculator they use in the first 10 minutes of looking at a job, and, if it’s worth it and once all the design-work and consents are complete, a ‘proper’ qs and costing process they use for their fixed-price tender applications. They say the two calculations have never varied by more than $20k. Good enough for us, then. Their Thumb Suck has been coded into the application.

Complex development feasibility models exist in the industry. Our thinking was that if we deconstruct the best of these and then refine, well, that can’t be too hard. It was hard. It took years. It had to accommodate the LC project concept – that the app was a decision-making tool. Therefore it had to allow for the interrogation of task and cost variables; to incorporate tax and gst calculations; to calculate Sell, Hold, and Sell & Hold outcomes; to model every kind of Returns format for these (residual land value, development profit, total profit, net profit, LVR, and so on). And so on.

But does it work? Answer: a resounding Yes. In most cases, a baffled, jaw dropped, fall-off-the-seat and almost unbelieving ‘yes’. Output has been validated by a number of professional developer customers using their own developments nearing completion. The results are an accuracy exceeding 98% eg using our design engine and the feasibility modeller in the first week without any ‘design detail’ returned a project value of $7.5M. The developer’s value at completion was just over $7.4M.

Management System

Process design is getting things in the right order, vertically as well as horizontally. Horizontally so you don’t end up paying for things prematurely or when it turns out you don’t need them at all; vertically so you see and have to deal with only the thing that matters at that moment. Getting it right slashes timelines (critical in development) and results in forward-planning certainty for consultants, contractors and suppliers.

The certainty achieved through the Design Engine and the Feasibility Modeller enable project management to a level usually only enjoyed by very large-scale commercial development.

In our view, using the Lots Co development tool is imperative for small-scale (<3ha) residential development. For medium-sized (<50 unit) medium-density development it’s still very useful, increasing certainty and development timeframes considerably. Larger-scale development operates differently, and although, for medium-density, the design part of the app should be, in our view, mandatory, the feasibility component as it stands is not appropriately scaled. That may be addressed in time, although it seems odd to detune something to be less precise. Sometimes it’s better to just focus on the knitting. So, having gone a long way to fixing small-scale development problems, what would be next? World peace?