The Fourth Little Pig - Postmortem

Alex Kotenko and Niall McConnell · London, September 2026

For roughly two years we were working on a software and delivery system meant to change how houses get designed, priced, and delivered. We operated a small garden rooms business under the trade name Precision Rooms, a testbed for proving the technology. We started this work in July 2024, bootstrapped it without outside funding, and decided to fold in August 2026. This is what we got right and wrong, what we would do differently, and the practical technical conclusion that came out of this work.

What we built

At the centre of the system was a machine-readable digital model of a building. Not a 3D shape, but an exact description of every part — every stud, joist, sheet, fixing and layer — and how they all fit together. This included shapes, dimensions, materials, mechanical and structural properties and the relationships between them. A full digital twin with all necessary details.

The model was generated from a customer's inputs using an elaborate set of procedural generators. Everything else was built on top of that model:

• A web-based design tool, where a customer shapes their building in 3D and sees the price update as they go.
• The structure itself — foundations, frame, roof, insulation, cladding and interior — generated from the design, with structural members sized by calculation to British timber standards.
• A full bill of materials, priced against current supplier prices, and a quote produced from it.
• Cutting lists optimised to minimise offcut waste, and step-by-step assembly instructions for the crew on site.

The model was the single source of truth from the customer's design through pricing and procurement to the build on site.

What that meant in practice

The model described the building at the level of the individual piece, combining the CAD, BIM, structural engineering, and customer presentation into a single machine-first model. Every aspect of the model was procedurally generated from simple customer inputs, and every generated part and system came out structurally sound and ready to build. The model was the single source of truth for the entire process, from design to delivery.

The generated systems were calculated and optimised for best cost and performance. Joists and header beams sized to BS 5268-2, not just overbuilt to a span table, but sized to minimise materials cost while passing bending, shear, deflection and bearing checks. Floor and roof deck sheets verified to Eurocode 5. Electric cables sized to BS 7671 according to expected load and length of the run.

Bill of materials was not just a collection of parts, but a fully priced list against best available current suppliers. Cutting plans optimised with Stock Cutting Problem algorithms to minimise offcut waste. Precise assembly instructions generated as finished engineering drawings, with step-by-step guidance for the crew on site.

What it does to the value chain

Removed outright. The bespoke design costs, the structural engineer review, the project manager preparing the quote. In our system these are not cheaper, they are absent: the same pass that produces the building produces its calculations, its drawings and its price, in seconds, for every design a customer tries.

Compressed. Procurement becomes an order list that falls out of the model, one consignment per supplier. Coordination between trades becomes generated instructions with clear upfront specification and defined hand-offs instead of negotiation on site. Waste falls because cutting is optimised across the whole job. Sales compresses into the customer quoting themselves, and the quote is the build specification. Framing and carpentry is not depended on crew calculating and making sizing decisions: the parts are cut to fit exactly, the plans account for all buildup layers and tolerances, and customer-facing result is built precisely to spec. In practice we built with hired labour and minimal training on our system.

Untouched. The timber, the glazing, the screws, the van, and the hours somebody spends on site standing up the walls in the rain. That is the whole finding, and the case study below puts numbers on it: labour and materials were about 85% of what the building cost us, and the work the software replaced is not a line on that sheet at all, because it never happened.

Why AI does not already solve this

The fair question in 2026 is whether any of this still needs building, or whether a general model can simply do it. Having built it, our answer is that AI changes the cost of building the tooling, not the nature of what the tooling has to be.

• The output has to be exactly right, not just sound plausible.
  A bill of materials that is 3% short is a van going back to the merchant and a day lost. An undersized joist is a structural failure, an oversized one - waste of material. The parts of our system that mattered are deterministic and auditable: a calculation against a published standard, validated against published tables.
• Models are not ready yet.
  Existing frontier models can reason about individual parts and, in most cases, probably get it right individually, but even a small building far exceeds the available context size of any model, and the relationships between parts are not just complex, they are brittle and unobvious. A model plugged into CAD via MCP can help the CAD engineer and simplify his work, but it does not replace the human engineer by any stretch. Our system does.
• The data does not exist.
  There is no corpus of part-level, machine-readable, trustworthy and accurate building designs to learn from. The industry's output is drawings, PDFs, spreadsheets and knowledge in people's heads. The CAD models that do exist are in proprietary formats that are difficult to turn into learning data. The industry is not structured to produce the data that would be needed to train a model to do this effectively. Somebody has to build the structured model first, and that is precisely the expensive part.
• Someone has to be accountable.
  Building control and warranty providers need a calculation that can be signed. A sheet showing the load case, the factors and checks that can be audited and signed. This has to be a precise calculation based on the correct implementation of the standard, auditable and trustworthy. A model that produces a plausible-looking structural calculation answer through an obscure reasoning chain is not enough, and the industry is rightly not willing to accept that.
• The remaining cost is physical.
  Even if design, estimation and coordination were free — and in our system they very nearly were — 85% of the cost is people and materials on a jobsite. And the remaining 15% is subcontracted services — other trades not on our payroll, the van, waste removal, the small unavoidable costs of running a site. Cheaper information does not move it.

Where AI does change things, it changed them for us: it made the system materially faster to build, allowed to generalise and automate small business management tasks that previously were tedious and labour intensive. Both of those helped reduce the overheads to nearly-zero, but they did not change the fundamental economics of the problem.

Timeline

We spent 18 months in development and early testing, from July 2024 until late 2025. We built two pilot projects during this time, so we have proven that the system can operate and that we can build. In Q4 ’25 we went out of stealth and started taking on commercial orders.

• July 2024 — Alex starts developing the software.
• 2025 — two non-commercial test builds, alongside the software development.
• October 2025 — precisionrooms.co.uk goes live, and commercial orders start coming in.
• January–August 2026 — eight commercial orders built.
• August 2026 — we stop taking on commercial orders and give notice to our employees.

What we did well

We commercialised the technology quickly. Within a year of the first test build we had a functioning construction company: a live website, a pipeline of commercial orders, and employees. By the time we stopped, we had delivered eight commercial builds on top of the two test builds. Our customers were happy — seven Google reviews, all 5-star.

The system did what it was built to do. It took a customer's design all the way to a priced quote, a bill of materials, cutting lists and assembly instructions, and real buildings were built from its output.

The finished buildings were built to a high standard. The system produced a full digital twin of the building, and the buildings were built to that specification. Digital twin was accurate and realistic, and the result "as built" matched the digital twin closely.

The construction costs data collection and analysis was done to a very high standard. We instituted and executed a reliable, low-cost, and very detailed daily time sheet system that, with AI help, was turned into per-hour breakdown of labour costs, attributable to cost categories.

We did not stop because we failed as a construction company. We stopped because we could not make it a breakthrough, runaway success, and running a small local construction company is not what we wanted to do long-term.

Failures

There are two kinds of learning here. One kind is personal and organisational — failures that are not novel in essence, but that we lived through in detail. The other kind is non-obvious technical findings from actually building and running an integrated construction digital-twin software system, delivering real projects.

We value the technical insight more than the personal and organisational, because personal is largely not novel and you can find this out in other high-quality sources (e.g. YC educational materials).

Technical software insight applied to construction is rare, and this is what we'll cover first.

Technical

Here's what the research and the build actually taught us about construction cost. Before starting this we didn't know for sure, and didn't have reliable third party data that would answer the following question.

Could we materially reduce the cost of construction by entirely removing the cost of overheads and materials waste from the process, and optimise delivery, without changing the way the buildings are actually constructed?

The answer is simple - no, we could not.

With a conventional existing building system, even if you exclude all management overheads completely and assume a perfectly running project, that is not enough to materially move the needle on costs. You do get some benefit, it is not completely useless. But the benefit is not material enough to give you an unfair advantage in the market, and not groundbreaking to make it really count.

There is no silver bullet. Construction costs are extremely fragmented: many trades, many things that have to happen, in the right order, with a lot of materials and tasks, most - in a poorly controlled environment of a jobsite. Construction Physics has a good explanation of this. It is a complicated management problem — but even solving management completely, and removing that cost into software - does not solve the raw labour and materials cost of getting the project built.

At higher scale — full single-household houses, not garden rooms — service costs (architecture, structural engineering, design, planning approvals, management overhead) are a bigger part of the equation. Software might still somewhat move the needle there, but again - not enough to be a breakthrough.

At scale there is also a bootstrap problem:

• You need to build a lot of software with little external input first, before you can test it on a real construction project. That takes a lot of capital and time (less now with AI, but still a lot).
• Testing on real construction projects is slow and complex. Each iteration will take months if you're lucky, not days. All while you burn more capital on project maintenance, research and further development.
• The industry is inherently territorial and cannot scale fast even if the software is solved: geographical constraints make it hard to expand wide and quick to create meaningful ROI.

Assuming the central thesis of reducing the construction costs materially through software would be true, iterating on construction would fund itself if you could find enough commercial projects to work on while improving the software. This was our plan and we had enough commercial orders to keep iterating. But the central thesis was false, and so the plan was flawed.

In short: for the garden-room / ADU class of work that we chose as the proving ground, absorbing overhead into software does not create a material cost advantage against the market. The same approach will probably matter more for full houses. But on its own it will not be groundbreaking, so will that be enough remains an open question. The capital and time required to find that out cleanly are large, and it is not obvious how to produce a compelling enough ROI narrative to fund this discovery.

Case study: our best-case build

We never built without the system, so we have no before-and-after comparison. What we do have is a best case: the cleanest build we analysed in detail, with all labour hired in and minimal involvement of our own.

• 3 × 5 m garden room, 2.5 m high, in London.
• Cedar cladding on the front and left walls, thermowood on the other two.
• GRP roof.
• Fully insulated: U-values of 0.25 W/m²K for the walls and 0.20 W/m²K for the ceiling.
• uPVC double front door and a letterbox window.

We priced it competitively against builds of similar quality from other companies. Leaving out the avoidable problems — mistakes that did happen on site, but did not have to — the build made a profit of 3.7% over cost. As it actually happened, avoidable problems included, it made a 2% loss. The avoidable problems alone added almost 6% to the cost.

This is the cost with the overheads already absorbed by the system and our own involvement kept to a minimum. What is left is almost entirely the raw cost of getting the building built: labour and materials together made up about 85% of it.

By trade, the foundations and the structural frame came in well under quote. The overruns were in on-site finishing work: the roof membrane, the cladding and the interior all cost more than quoted.

A healthy margin needed a price 10–15% higher. That would have put us into premium territory — which, quality-wise, would be probably accurate. But the goal was premium quality at mid-market prices, and the system did not cut the cost of delivery enough to get there.

Personal

These fall in three layers: tactical, strategic, and cultural.

Tactical

Initially we took on orders worth about half a year of work. We priced all of them based on the rather naive v1 pricing system, and we did not reprice.

We signed contracts. After analysis of the first commercial build showed that we were barely breaking even on the v1 pricing structure, we still did not reprice the other orders.

All those orders were sourced in late 2025. The first commercial order was finished by mid February 2026. At that point we should have stopped and reassessed unit economics — whether the pipeline made sense at all. We had the analysis. It was bad, but we refused to acknowledge that and did not stop.

So instead of treating this as proof of system viability, we acted as if it was already proven, and as if the remaining problem was to scale the order pipeline. We never properly confirmed that the unit economics worked, and the pipeline made sense in the first place.

Strategic

We asked the wrong question, or approached the right one the wrong way.

The question that actually mattered was:

If we build an automated, vertically integrated software system that removes most building overheads, does that move the needle on the actual self-cost of delivery enough to be materially better than the market average?

We discussed that at the start. Alex was adamant that we must build the system, and that building it would give us the answer. Niall did not challenge that hard enough. It did give us the answer — in about two years. Eighteen months to get the answer, and another six months to admit that we had it and did not like it.

A better path, in hindsight, would have been not to build the system first. Secure several commercial orders and validate the cost structure instead of building a system.

• First order (friends and family), designed and managed by hand, no system. We are sure we could have done this manually — spend two weeks preparing by hand what the system generates in seconds, versus far more than two weeks to build the system in the first place.
• Second order (still friends and family), similar approach, with an early pricing model and more confidence in delivery.
• Use that experience, media materials and early models to secure a couple of commercial orders.
• With reporting and data gathering that we have put in place, collect the same analysis and test financial viability for the idealistic case — assuming the system takes out most of the overheads.

With this we would know whether, with overheads stripped out, we had an unfair advantage worth building for, or whether we would just be another small construction company: maybe slightly better, but not enough to matter.

We could have arrived at the same answer in six to twelve months rather than two years.

Cultural

We let the engineering run ahead of the business. Alex was preoccupied with building the system, which was the most enjoyable part, without asking hard enough whether it made business sense to build. Niall was there to keep the business case honest, and did not ask the hard questions early enough.

We both failed, and the failure was shared. Alex let enthusiasm for the build outrun the business case. Niall did not hold us to account on goals and path. Neither of us forced the question while it was still cheap to answer.

We did not face the music when the first financial report was prepared. We assumed unit economics will improve with experience. It did improve — but not enough to turn it around.

After the first report, it was reasonable to try once more. After the second commercial build and the second financial analysis, we should have faced it: the unit economics did not work; we were not making enough profit if we price it competitively. And if we priced it to make money - we were not competitive.

We should have stopped, cancelled or repriced the outstanding contracts. Instead we doubled down on building more at the same pricing model that left us around zero margin.

We built the system. It answered the question we should have insisted on answering first. The answer was that what we've built did not provide enough of an unfair advantage, and that perfecting delivery through software was not enough to change the unit economics in a way that mattered for this product category.

Thoughts for those coming after us

• Test the unit economics first. Deliver the first jobs by hand, with your best guess at the costs the system would remove. Software should scale an answer you already have, not be the way you find out.
• Don't be afraid to reprice. Every contract signed on an unproven pricing model locks in its losses. It's better to go back to the customer and say that you cannot deliver the project rather than to deliver it at a loss. Even if you decide to deliver at a loss, understand exactly why it makes sense to do and how much you expect to pay.
• Decide target numbers in advance. When the analysis comes back bad, a threshold agreed beforehand is much harder to argue with.
• Don't expect management alone to bend the cost curve. Removing overheads helps, but a step change in cost needs building differently, not just more efficiently.
• Budget for slow iterations. Each real-world test takes months, not days, and construction scales one geography at a time.

Closing

A digital twin system and advanced software for construction management are necessary and are definitely helpful, especially at scale, but to achieve material progress in the overall cost, you need to make advancements in the physics of construction: build things differently, not just more efficiently.

Future directions

There is still an open question whether this would make more sense for higher-scale, higher-complexity buildings. Our gut feel is that it probably would, but also that it may not be enough to justify the investment necessary.

Another direction may be a pure software+AI system that would provide this kind of tooling to many construction companies and so scale without attachment to geography. Making this work will be non-trivial as well, for a number of reasons, but it is worth exploring.