By Geoffrey Guilly, Chief Executive Officer.
Most software companies begin with a technology looking for a problem. Aitenders began the other way around. Before it was a product, it was a problem I lived, for more than twenty years, on every side of the tender process.
I spent my career in finance, operations and complex infrastructure across three continents, mostly at two of the world’s largest infrastructure engineering groups. The businesses I ran depended on tenders: public-private partnerships, concessions, operations and maintenance, consulting engineering. I was a bidder, an approver, and an adviser to the authorities issuing the work.
“I did not discover this problem. I lived it.”
The weekend that repeats
For part of my career I was the regional gatekeeper, with five or six major bids in the pipeline at any time. Different countries, different teams, different rules, and deadlines so strict that missing one by an hour put you out of the running.
The documents would land on my desk late on a Friday. Over the weekend a small team and I would price the bid, challenge the contingencies, check the legal exposure, weigh the country and currency risk, and go through our internal rules line by line. On Monday morning we presented to a committee that could spot an inconsistency in seconds. Then we did it again the next week, with five bids in parallel, each worth tens of millions, each capable of damaging an entire business unit if we got it wrong.
“The people were excellent. The system around them was not.”
The problem was never the people
What I could not accept was not the pressure. It was what the pressure did. Senior, capable people were spending two or three days of every week on the most basic task in the whole process: finding information.
A tender is not one document. It is thousands of pages, the request, the annexes, the technical specifications, the contract, the local regulations, and the risk is rarely in any single line. It is in the relationship between them. So before anyone could make a decision, the team read everything by hand and copied it into spreadsheets. By the time the analysis was done, there was almost no time left to actually think. And the same mistakes came back across bids, countries and years, because the person who had seen it before had moved on, and nothing the company had learned was ever captured. Every bid started from zero.
Why it had to be built for the work
In 2016, during an executive MBA, I spent three days in a class taught by one of the people who led the development of IBM Watson. I left convinced that this technology could change the work I had been doing every week for twenty years. I went looking for a tool. There was nothing built for tenders.
So I started building one myself, with no coding background, one prototype at a time, until I hit the limits of what I could do alone. I found Julien through his open-source work, hired him for a short assignment, and we became friends and then co-founders. I left my job at the end of 2018, and we started Aitenders in early 2019. From the beginning we built it with customers, in the industry, for the actual workflow, not as a generic tool pointed at construction.
The outside view, seven years later
In July 2026, McKinsey published its analysis of AI in this industry. It placed the first wave of value on exactly the work I had struggled with: the decisions made before construction begins, from bid analysis to proposal drafting to tracking obligations through delivery. It said the durable advantage comes from capturing a company’s own project data as the work happens, and keeping it separate for each customer.
We did not write that analysis. We had been building that company since 2019, with real customers and real revenue, in one of the hardest industries in the world to enter, before raising a dollar of venture capital. The most credible voice in the sector had just described, from the outside, the problem we had been solving from the inside.