Why I Built Strand Labs

A Script and a Realisation

A couple of years ago I wrote a script that scraped hotel rates from Booking.com. It wasn't sophisticated. Copy output from the browser console, paste it into a file, run the script manually. But it worked. I used it as an internal resource at the company where I work, and that was that. A useful tool, nothing more.

Around March last year I came back to the idea. In the intervening months, AI coding tools had improved dramatically. What had previously required careful manual construction now happened in minutes.

After a few weeks of building with these tools, something became clear to me that I think is still underappreciated: even if the models never got any better than they were at that moment, they would fundamentally change how software is built and, by extension, how a great deal of knowledge work is done. The ability to generate working code from plain language generalises to an enormous number of tasks. It doesn't guarantee you can do any specific job, but it removes a barrier that previously kept most people, including me, from building the tools they could imagine.

This realisation carried two feelings simultaneously. The first was a recognition that my own role, or at least the desk work side of it, financial modelling, the detailed analytical grind that I genuinely enjoy, would be substantially different within five years. Not necessarily gone, but altered in ways that made me question whether I was positioned well for what was coming.

The second feeling was excitement. I had wanted to build software since Apple first released Xcode, its iOS development platform. I tried repeatedly and never got far enough to make anything real. Now, suddenly, I could.

The Marble Run

Naturally I pointed this new capability at the work I knew best. I thought back to the experience of getting a new deal staffing as an analyst at Eastdil Secured, that moment when a new property lands on your desk and you're looking at a day or more of foundational work before any real analysis can begin. Pulling rate data, finding comparable properties, building the financial model, assembling the memorandum. Hours of structured, repetitive effort that follows broadly the same pattern every time, yet somehow still takes a full day because each step requires just enough judgement to resist simple automation.

This is where the interesting technical insight emerged. The non-determinism of large language models — the fact that they don't produce the same output every time — is simultaneously their greatest strength and their most significant limitation. It allows for entirely new chains of functionality: you can combine deterministic processes with LLM-driven steps in sequences that were previously impossible.

A basic example: rather than writing an exhaustive list of synonyms for the word "good" in a sentiment analysis system, you can simply include an LLM instruction to evaluate sentiment. The model handles the ambiguity that rigid code cannot. But that same non-determinism means you cannot simply hand an LLM a complex task and expect reliable results. For work where precision matters — and in finance it always matters — this is a serious problem.

I keep coming back to an analogy that I think captures this well. Imagine a messy room. A marble sits on the floor in one corner. The goal is in the opposite corner, high up near the ceiling. Large language models are like giving the marble an engine. It can now move forward, accelerate, navigate around obstacles. But it can't fly. It makes wrong turns. On its own, reaching that goal in the upper corner is not reliably possible.

The solution is to build the marble run — the structured pathway that channels the marble's new capability toward a defined outcome. Before the marble had an engine, building the run would have been pointless. The marble couldn't move. Now that it can, the combination of the engine and the structure is what gets the marble to the goal.

Wilton

Wilton is a marble run. It channels the capability of language models through a structured pipeline of deterministic and non-deterministic steps to produce a financial model, an investment memorandum, and a website in under ten minutes.

Each step is designed so that the parts requiring precision are handled deterministically, and the parts requiring judgement — market sentiment, qualitative assessment, narrative synthesis — are handled by the model within tightly defined schemas. The model is never asked to simply produce a document. It is asked to fill specific roles within a larger system that controls the overall output.

Beyond One Workflow

As I built this, I began to see something that extended well beyond one workflow at one type of firm.

There is a widespread assumption that AI adoption in enterprise means giving employees access to a chatbot, a ChatGPT subscription or a Copilot licence, and waiting for productivity to improve. I think this is fundamentally wrong, or at least dramatically insufficient. General-purpose AI tools are useful for general-purpose tasks. But the work that defines most organisations — the specific, structured, domain-particular processes that consume most of their time and resources — requires something more deliberate.

Companies need to build their own marble runs. But before they can do that, they need to understand what belongs in the top corner of the room. What the actual goal is, expressed precisely enough that a structured system can target it.

A lot of current AI solutions are designed for an idealised version of how work should be done, requiring significant organisational change before they deliver value. I think there is a more practical path: take the outputs people are already familiar with, the formats they already trust, and fundamentally improve the process that produces them.

With Wilton, that means delivering a PowerPoint deck, an Excel model, and a website — formats that every analyst and principal in real estate recognises. But assembling them through a process that takes minutes rather than days and incorporates thousands of data points that no human could manually compile. The disruption is in the underlying process, not in the deliverable. The person receiving the output sees something familiar. The person who would have spent a day producing it sees something transformative.

Strand Labs exists to find these processes. Structured, repeatable workflows in complex industries where the combination of domain expertise and carefully scaffolded AI can deliver genuine, immediate value. Not by replacing the people who do the work, but by changing what the work involves. The goal has always been the same: raise the floor so that the ceiling can go higher.