What Happens When a Construction Manager Builds Software With AI

I need to be upfront about something: twelve months ago, I didn't know what an API was. I couldn't tell you the difference between a database and a spreadsheet with ambition. I'd spent thirty years managing construction projects, not writing code.

Today I have a multi-tenant SaaS platform with 27 specialised tools, AI integrated into the architecture, a vector database for semantic search, row-level security across 186 tables, and live users managing real projects on it.

I'm not telling you this to show off. I'm telling you because it fundamentally changes what's possible — for construction, for small businesses, and for anyone who knows their industry inside out but assumed they needed a dev team to do anything about it.

How It Started

Like most things in construction, it started with frustration.

I'd spent years watching software companies try to build tools for our industry. They'd hire developers who'd never set foot on site, run a few discovery workshops with contractors who told them what they wanted to hear, and produce something that looked impressive in a demo but fell apart the moment a real QS tried to process a payment application with it.

The drawing registers didn't understand revision control the way construction uses it. The variation tracking didn't follow JCT or NEC workflows. The RAMS modules were written by people who thought CDM 2015 was a postcode. Everything was close, but nothing was right.

I'd been saying for years that someone who actually understood construction needed to build this. Then AI coding tools hit a tipping point, and I realised that someone might as well be me.

The First Month Was Brutal

I won't pretend this was smooth. The first month was genuinely painful.

I started by describing what I wanted to an AI assistant in plain English. "I need a drawing register that handles revision supersession, links to tender packages, and extracts metadata from title blocks automatically." The AI would generate code. I'd have no idea if it was good code or terrible code. I'd paste it in, something would break, I'd describe the problem, and we'd go round again.

I didn't understand error messages. I didn't know why a page that worked five minutes ago suddenly showed a white screen. I once spent an entire evening trying to fix a problem that turned out to be a missing comma. A comma. I've managed £180m construction programmes and I was defeated by punctuation.

But here's the thing about construction people — we're used to solving problems we don't fully understand. You don't need to be a structural engineer to manage a structural package. You need to understand the principles, ask the right questions, and know when something doesn't look right. The same turned out to be true for software.

What AI Actually Does Well

After twelve months of building with AI, I can tell you exactly where it earns its keep and where it doesn't.

It's exceptional at translating domain knowledge into code. This is the killer capability. I can describe a construction workflow in detail — how a payment application moves from draft to submitted to certified, how retention works under JCT, how a drawing revision supersedes the previous issue — and the AI generates working code that implements it. Not perfectly every time, but close enough that the refinement cycle is hours rather than weeks.

A developer without construction knowledge would spend days researching how interim payment applications work under the Construction Act. I can explain it in five minutes because I've been doing it for thirty years. The AI handles the translation from domain knowledge to code. That combination — deep industry expertise plus AI coding — is genuinely powerful.

It's fast for repetitive patterns. Once you've built one CRUD module (create, read, update, delete — I've learned the jargon now), building the next one is dramatically faster. "Build the same pattern as the drawing register, but for submittals, with these fields and this approval workflow." The AI understands the existing architecture and replicates the pattern. What took two weeks the first time takes two days the fifth time.

It's good at finding bugs. Describe the symptoms — "when I click save, the form submits but the data doesn't appear in the list" — and the AI can usually trace the problem faster than I could by reading the code myself. It understands the codebase, remembers decisions made months ago, and can cross-reference multiple files simultaneously. Like having a QS who actually remembers every variation instruction from the entire project.

Where It Falls Over

It doesn't know what it doesn't know. AI will confidently generate code that looks correct but has subtle problems — security gaps, performance issues that only appear with real data, patterns that work for ten records but break at ten thousand. Early on, I had database queries that returned correct results but would have been catastrophically slow with production data volumes. The AI didn't flag this because it was focused on correctness, not scale.

This is exactly like a graduate site manager who produces a programme that's technically logical but practically impossible — the durations are right but the sequencing ignores resource constraints. You need experience to spot what's missing, not just what's wrong.

It can introduce inconsistency. Ask the AI to solve the same problem on different days and you might get different approaches. Without discipline — coding standards, architectural patterns, consistent conventions — you end up with a codebase that works but is held together with five different approaches to the same problem. I learned this the hard way and had to go back and standardise.

It doesn't understand your business context without being told. The AI doesn't know that in UK construction, a payment application has to follow specific timelines under the Construction Act. It doesn't know that RAMS documents need to comply with CDM 2015. It doesn't know that drawing revision P01 means something different from C01. You have to teach it all of this, explicitly, and keep reinforcing it. The domain knowledge is yours. The AI is the tool.

What I'd Tell Someone Starting Today

If you're sitting there thinking "I know my industry better than any software company, and I've got an idea for something that should exist" — here's what I wish someone had told me.

Start with the data model, not the interface. I spent the first two weeks obsessing over what the screens would look like. That was completely backwards. The important decisions are about data: what entities exist, how they relate to each other, what needs to be scoped to which organisation. Get the database right and the interface follows. Get it wrong and you'll be rebuilding foundations while the walls are going up. Sound familiar?

Write everything down before you write any code. I documented every module specification before building it. What fields does a drawing record need? What statuses can it have? What's the revision workflow? How does it relate to tender packages? This documentation became the brief I gave to the AI. The clearer the brief, the better the output. Same as construction — a good specification produces better work than a vague one.

Build one module properly, then replicate the pattern. Our drawing register was the first module. It took weeks. But the patterns we established — how services are structured, how API routes work, how the UI components fit together — became the template for everything that followed. Submittals, RAMS, RFIs, correspondence — all built on the same bones. Like having a good set of standard details that you adapt for each project.

Don't skip security. This was a hard lesson. Multi-tenant software — where different organisations share the same platform — needs rock-solid data isolation. Every query needs to be scoped to the right organisation. Every API endpoint needs authentication. Every file upload needs to go to the right place. I had to go back and retrofit security patterns that should have been there from day one. If you're building anything that handles other people's data, get this right first.

Accept that you'll rebuild things. I've rebuilt some modules three times. The first version worked. The second version worked better. The third version worked properly. That's not failure — that's iteration. Same as construction. Nobody gets the programme right first time. You build, you learn, you refine.

Why This Matters Beyond My Story

The point of all this isn't that I'm special. It's that the barrier to building software has collapsed, and it's going to keep collapsing.

Every industry has people like me — thirty years of domain expertise, deep frustration with existing tools, and clear ideas about what should exist. Until recently, those people had two options: convince a software company to build what they wanted (good luck), or raise money and hire developers (expensive, slow, and the developers still won't understand the domain).

Now there's a third option. Build it yourself, with AI as your co-pilot. It's not easy. It requires discipline, patience, and a willingness to learn things you never expected to learn. But it's possible in a way that genuinely wasn't two years ago.

For the construction industry specifically, this matters enormously. Our tools have been built by outsiders for decades. People who understand software but don't understand construction. The result is platforms that look professional but miss the details that actually matter on site — the revision workflows, the contract administration timelines, the cost code structures that tie everything together. That's why construction needs purpose-built software designed by people who've lived the problems.

What happens when the people who understand the industry can build the tools themselves? You get software that works the way construction actually works. Not the way a product manager in San Francisco imagines it works based on three customer interviews.

The Uncomfortable Truth for Software Companies

If a construction manager with no technical background can build a working platform with 27 tools in twelve months, what does that mean for the companies charging £30,000 a year for something similar?

It means their moat isn't technology anymore. It's data, it's switching costs, it's the inertia of "we've always used this." Those are real barriers, but they're not permanent ones. And they're certainly not a foundation for long-term confidence.

The value is shifting. Away from the code itself — which AI is rapidly commoditising — and towards the domain knowledge that makes the code useful. Understanding how a QS actually processes a payment application. Knowing why drawing revision control matters on a live site. Recognising that a RAMS document needs to protect operatives, not just tick a legal box.

The companies that will thrive are the ones where the people building the product genuinely understand the industry they're serving. Not from research. From experience. That's always been true, but it used to be expensive to act on. Now it isn't.

Where I Am Now

Twelve months in, Construction AI has 27 tools across four modules. Project management, financial tracking, site management, and tenders. The AI assistant reads drawing title blocks, drafts correspondence, generates RAMS, and answers questions about your project data in plain English. All built around how UK construction actually works, by someone who's done it for thirty years.

It's not finished. Software never is — same as a building, there's always a snag list. But it works. Real contractors are using it on real projects. And every week it gets better, because I understand the problems and the AI understands the code.

If I can do this from a standing start, imagine what's coming next. Not just in construction — in every industry where the people who understand the work have been waiting for tools that actually fit.

The barrier is gone. The only question is who builds first.

---

Steve McKenna is a Chartered Construction Manager and founder of Construction AI — a purpose-built, AI-native project management platform for the UK construction industry.