Last October, HSS Hire Group- a business established in 1947, with a network of 130 physical depots – sold itsrental operations to a private equity firm and became, overnight, a zero-asset technology company. Nowarehouses. No fleet. A digital marketplace pairing construction managers with a network of suppliers acrosstools, equipment, fuel, training and materials.
That is the short version of the story. The longer version is more useful, because it explains why we made the technology choices we did, and why AI is now central to how the platform operates – not as a feature, but asinfrastructure.
The Problem We Were Actually Solving
Construction hire looks deceptively simple from the outside. A company needs a digger, they order it, it arrives.But a hire transaction does not end at the equivalent of a checkout. It extends across days, weeks, sometimesyears. A digger hired for three days might be kept for three months. Extensions trigger different rate structures.Equipment gets damaged, swapped, returned in pieces. Compliance documentation has to follow every asset inthe field.
As I have said before: “You don’t sell one item at one point in time. You take something on site, you deliver it,then after a few days or weeks or years, you go pick it up.” That non-linear lifecycle is the hardest problem inour domain. Standard e-commerce logic does not come close to solving it.
The financial consequences of this complexity are severe. If your system cannot track the full lifecycle of everycontract in real time, you end up with manual reconciliation, surprise invoices and a finance team permanentlyfirefighting. We needed a system that could reason about every contract, every day, and recalculate the financial position automatically if anything changed.
We called it a self-healing finance system. It is the engine at the core of the platform; built under a product werefer to internally as Brenda.
Why Functional Programming, and Why It Matters Here
To build something that behaves predictably in a genuinely messy environment, we chose Scala as our primarylanguage, supported by the Cats library for pure functional programming. This is a choice more commonly associated with high-concurrency fintech than construction logistics, and that is precisely why we made it.
The key concept is local reasoning: the ability to understand and test a specific piece of code without needing tohold the entire system in your head. In a distributed platform with complex financial state, that property is notan academic nicety. It is how you avoid the kind of cascading bugs that make systems impossible to maintain atscale.
The power of pure functional, particularly in a messy setting, is that you can reason very locally about elementsof code. Scala was built as a scalable language for large systems. With Cats, you add pure functional disciplineon top, which makes it easier to maintain and easier to change without breaking things elsewhere.
The rest of the stack is built on PostgreSQL, with Kafka for event streaming and OpenSearch for discovery.The entire architecture is headless and API-first – which matters when your supplier network includes businesses that are still operating on paper and phone calls.
Where AI Comes In and What It Actually Does
Because construction remains, in many parts, a digitally immature industry, we cannot assume that everyparticipant in the supply chain will interact with the platform through a clean APL Suppliers send proof ofdelivery and collection confirmations by email, in whatever format suits them. Customers make requests, raiseissues and provide updates through email too – and increasingly through other channels beyond it.
We are already live with an agentic workflow that reads incoming supplier emails – proof of delivery, collectionconfirmations – classifies them, and automatically translates them into API calls that update the platform in realtime. Nothing changes at the core of the system. The AI sits at the edge, converting noise into signal.
We are now extending the same logic to customer communications, starting with email but with a clear intent toingest from any channel – because the medium should not determine whether an interaction gets processed accurately and quickly.
The next step takes this further: using the same agentic layer to communicate outward. Rather than simply reading and processing incoming messages, the platform will generate and send contextually appropriate responses and updates back to customers and suppliers – proactive notifications, confirmation of statuschanges, exception alerts – through whichever channel they use. The goal is a fully bidirectional AI layer:one that listens, acts, and responds, without requiring either party to change how they work.
The framing matters: “Instead of asking any technical effort from not very tech-savvy businesses, we areshifting our model. That unstructured data, it’s now possible to turn into structured data that we push into oursystem via APis.” The supplier or customer does not change their behaviour. The platform adapts to them.
This is AI doing what it is actually good at: pattern recognition across high-volume, lowconsistency inputs, at aspeed and scale no human team could sustain. It is not replacing judgment. It is eliminating friction at theboundary between our system and the real world.
What This Means for Builders and Investors
The HSS story is sometimes framed as a digital transformation narrative, which is accurate but undersells thespecificity of the choices involved. The lesson is not that construction companies should digitise. It is about the sequence.
We did not start with AL We started with the hardest operational problem – financial exceptions and non-linear contracts – and built a system that could handle it reliably. The architecture that solves that problem is also the architecture that makes AI integration tractable. If the core is messy and manual, adding AI at the edge justaccelerates the mess.
For anyone building in complex operational domains – logistics, construction, facilities management, fieldservices – the same principle applies. The return on AI investment is proportional to the quality of theunderlying data model. Agentic pipelines that route unstructured communications into structured API calls onlywork cleanly when the API itself reflects the actual complexity of the domain.
There is also a market dynamic worth noting. By becoming a pure-play digital conduit, HSS now surfaces real-time demand data back to its supplier network. Small hire businesses can see what construction managers aresearching for and adjust their equipment portfolios accordingly. The platform becomes an intelligence layer forthe whole supply chain, not just an ordering interface.
The Part That Is Harder Than the Technology
I will be direct about something that does not often appear in articles like this: the technology was not the hard part.
Pure functional programming in Scala is well-understood. Agentic AI pipelines are increasingly well-documented. What takes longer – significantly longer – is taking an organisation with seventy-five years of physical operations and helping it understand why these choices matter, what the new model looks like fromthe inside, and how to build confidence in a system that works differently from everything that came before.
It was a long journey because, as usual, things are much more difficult from a human process perspective. Itwasn’t the lack of the technology. It’s simply that you need to take people on the journey.
That remains the most underestimated variable in any serious digital transformation. AI accelerates operations.It does not accelerate organisational change. The businesses that will see the strongest returns are those that invest equally in both.
