Organising Engineering Documentation with AI – Poelis

Michele Genoni, co-founder of Poelis and an aerospace engineer who spent seven years in industry before starting the company, told us why the bottleneck in hardware development is never the CAD, and why he thinks legacy PLM is treated as a monthly homework assignment.

PLM as a Homework Assignment

What is the problem you are out to solve?

I am an aerospace engineer by background, and what I experienced firsthand is that the real bottleneck to accelerating a hardware product is not having a faster solver for your structural or fluid dynamics analysis. It is having every team on the same page, exchanging data correctly and at the right time. Having a sort of harness that links the different teams and systems, but most importantly the documentation. Because like it or not, documentation is still in 2026 the official interface for communication. The decisions, the geometry, the placement of objects inside a satellite, eventually it all ends up in a document.

And the slow part is not the calculation and the design. It is what we call engineering bureaucracy. Change management, supplier management, co-design, going from BOM to an order in the ERP. These multi-department workflows could be much quicker. What makes them slow is the fragmentation of the data, and the fact that they go through multiple people in different teams.

So the road to faster development is not a better CAD system or a better solver. It is getting rid of that bureaucracy.

Yeah. What I often say is that in the seven years I worked in the industry, not a single project was delayed because the CAD designer was late. It was because someone forgot to exchange some data with another team, it went for testing, and then a month is lost because the whole test campaign needs to be carried out again. Or there was misinformation between the suppliers and the engineering side. All of it is a coordination problem.

Where do legacy PLM systems fall short?

They do not act as a harness for the teams to work on. They act more like a homework assignment. When I was at Airbus, Windchill was the environment we used for that “homework”. It was a thing my manager told me to do every month, to go and update some documents about the system I was working on. It is completely uncorrelated to the day-to-day work these groups of people actually do. They serve the purpose of organising things and having signature loops, but completely miss the purpose of helping people coordinate. It is a container rather than a tool.

They are meant to be a tool for engineers and they are not treated like one. Why has nobody fixed that?

I think the issue is at the genesis. The three companies that lead the market are all 40-plus years old, and their product roadmap is admittedly – it is public on their websites – an acquisition roadmap. They are not product companies anymore, they are money-making companies. They make their money serving Airbus, Renault, Stellantis, and when you sell to those giants, the last thing you discuss in a meeting about a multi-million dollar contract is whether this team needs these features.

Management has a goal to implement a system of record, so they run a bid, and there is a lot of politics, with nations siding with their own. So to disrupt this industry you need to start bottom-up, where the decision maker is very often the user, and your differentiation is that the thing is actually useful.

Organising and Exchanging Data with AI Automation

So what does Poelis do?

We help these teams organise all of the data and keep it consistent with the interfaces between the different systems. Then on top of all that context we automate the end-to-end processes, so you go from weeks to literally one day. We think the container can stay, because you do need an official archive, but it should also be a proactive system that updates the documents and the links and all the boring stuff.

We are pretty young, having been around about a year and on the market for a lot less. With our early clients we are doing two things. One is organising the data and mapping the real-life sources of it, which happen to be mostly email and SharePoint. The second is working out which processes are still very manual and add little value, so we can delegate them to the system.

On the first stream we have already built all the primitives, the basic functionality an engineering team needs – versioning, approval loops, linking, referencing, units of measure. On the second we have what we call Poelis AI, a set of agents and skills you can use on top of your data.

You are on a quest to become a PLM but not quite there yet. What are you at this point then?

Right now our value proposition is helping engineering teams organise and exchange their data and leverage AI to automate most of their manual work. When I say we are not yet a PLM, I mean the breadth of what we can do. Software development speed is so much faster than it was 40 years ago, but Windchill has been developed for 30 years and Poelis for four months.

Our goal is based on the belief that the next generation of companies will just work in a very different manner. That monthly homework assignment is not going to be in the realm of what engineers do in ten years’ time. Just like people do not really check pull requests themselves anymore, because a code reviewer does it. Engineering has a lot more inertia, but it will come, and we want to be the system that pioneers that.

Where is the AI actually doing work? Give me an example.

Change management is the clearest one, and it applies to any sector. You change something and you want to see whether any past project has done something similar, and what the impacts are. Not only on the product, but more stupidly, which documents do I now need to update.

Imagine it starts as a client request. I forward the email to Poelis and ask it to check across our portfolio and tell me which product is the closest match. It comes back and says “This one, but you need to thicken the walls because the client wants it to withstand a much higher pressure”. Then you ask whether any client in the last five years has asked for something like this, because maybe there is a finite element analysis you already carried out at that range of thicknesses. For a small company, that saves you €10K.

And then what, it drafts the paperwork?

Then you say, to use software terms, “Branch off from that product in the catalogue and update all the documentation so it is ready to go”. So the time from receiving the customer requirements to having a set of documents and a preliminary sizing and performance assessment – something that would require different people and maybe even different teams – is compressed to half a day rather than one or two weeks.

Your website claims up to 70% less documentation time. Where does that number come from?

This concrete number comes from our main client, an aerospace company. One of our agents is an in-app editor for Excel and Word, so the same template with the same type of data can recreate a document or update it. Our medium-term goal is to remove documentation management from the activities of engineers altogether.

The percentage of documents where the writing is part of the design, where the engineer actually thinks, is very little. There are some. A trade-off study is one, or a very technical document in the design phase, where you learn as you write it. You plot the curves, you look at what they tell you, and the conclusion comes out of doing that. There, the writing is the engineering. But 90 percent are pure data documents – system design descriptions, interface control documents, user manuals, statements of work. It is really the same document over and over with slight changes.

You cannot write my user manual from nothing though. You need my existing manuals for similar products to be there already.

Yeah, exactly. First, we need to really master how we orchestrate all of the data, so that our agent has the context and can write correct things. Second, there is the company-specific style and the company-specific templates. Our clients can create the templates and the sections and whatever they want written in each document. And when our agent writes a certain type of document it can go and look up the previous version of that same document, or similar documents within the same product, or you point it at the right sources of inspiration.

So you are taking a tedious job off engineers. Do they still have to review the output?

That depends on the industry. In aerospace the review, and especially the signature, is legal liability. In my previous company we had a joke that paradoxically if the aircraft we were making was going to crash, it was the chief engineer going to prison, not the CEO. But that is not about AI. Whether it is the intern, the AI or another engineer who wrote it, it is for the chief engineer to review it.

For less critical documentation I think it follows the same path as coding, and it gets there faster, because a document is less critical than code. At the beginning it is just the tab, predicting your next sentence from the documents your company already has. Then you get a swarm of agents doing the review and flagging the critical aspects. With time we’ll trust more and more how AI will write down the descriptions and statuses of the projects.

Freeing Up Time to Fight the Staffing Problem

Who is using Poelis today?

We have only been on the market a few months. At the beginning we focused on aerospace, because of my background. That is where we know the day-to-day work best, and one of those clients builds satellites. Since then we have added a heat exchanger manufacturer and a straightforward industrial manufacturer with no long development programme. I think we will lean much further that way, partly because there are far more of those companies and partly because we see more use cases there.

The website says you are for complex systems. Where does the line between complex and simple actually run?

Complex does not have to mean what you think. A satellite is obviously complex, at least to most people. A heat exchanger, and you are a mechanical engineer so you know this, is a piece of metal with some holes. The complexity there comes from two things. One is volume and combinations. You sell one satellite a year but a thousand heat exchangers, so there are a thousand customers with slightly different requirements, because it is still a little bit custom. The other is tracking it. Different clients, different deadlines, slightly different analyses you have to repeat anyway or you do not get the certification. Pure monkey work, and almost none of it is automated.

Who is the best fit customer right now and what’s the main thing you solve for them?

If you start bottom-up, which in our case means European SMBs and startups, the biggest problem for an SMB is staffing. It is very hard today for an Uncle Joe kind of company to hire good talent when you are not in the big hubs and not doing very cool stuff. So we try to keep the throughput constant and fill that gap with AI automation.

Anything customers found surprisingly useful?

A publish button, so a document can be shared online with suppliers and clients instead of downloading it and sending it. My CTO built it in less than a day because he was in there anyway, and we got so many requests. It is also useful as go-to-market, because it puts our documents in front of suppliers and clients, who then ask what this is.

Pilot Program or Start Using Right Away

Where does the data live? I assume everybody in aerospace asks for on-premise.

Either on the cloud, so a standard cloud application, or on premise at the client. We have the on-premise option. The only caveat is that we released it a few weeks ago and the AI part is missing, because that does not depend on us. If the client does not have even a small number of GPUs to run an AI model, there is nothing we can do about it. But that is something we are going to work on, because we think private AI in this world can be very interesting.

What does onboarding look like?

If the sales cycle is smooth we just go there for a few days. I go to the client, or we do it online, and onboard the key people who are going to use the software, and set up the first instances of their products and whatever integrations they need.

If it is a longer cycle, we do a paid pilot. We have done one and two month pilots with some key objectives, and if those are met it converts to a yearly contract.

And how does it integrate with the rest of the engineering stack?

We have a bunch of native integrations we built ourselves. SolidWorks and Catia to import the materials, and Odoo to generate manufacturing orders and purchase orders directly from Poelis. We have a library for MATLAB and Python, so analysts can link the data directly. I can read data from Poelis inside MATLAB, but I can also write, so if they run an analysis and the new desired mass is six kilos instead of five, they can update it via code.

Innovation Needs the Right Culture

Every software vendor is bolting AI onto what they already have. Do we actually need AI-native tools, or could the existing PLMs just switch AI on?

To me the question is not whether it can be done. It is whether those vendors are the right people to innovate. I am looking very closely at what Salesforce is doing. They are pushing for headless, which is something I have been very surprised by. Out of the blue they say do not use our interface anymore, we will give you all of the APIs, you point your agents at them and do whatever you want. That is the disruption opportunity.

The engineering industry is still conservative and it has not been product driven for probably 20 years. I just do not see them doing it. I was working for Airbus and then I went to a startup in aviation, and at Airbus there were far more talented and experienced people than we had at the startup. Nonetheless we got done in two years what Airbus has yet to do in hydrogen aircraft. Everybody expects they can do it. But does their company culture support it?

Say you are successful. What will the picture look like in five years?

Success looks like being the benchmark, so that any new hardware startup starts their journey on Poelis, and most SMBs and traditional engineering companies have at least heard of us. In five years we could have 5,000 or 6,000 clients, small clients of course. And we need concrete success stories in the enterprise. Maybe not at the corporate level, but teams or divisions of big companies.

On a scale of one to five, where one is AI assisting engineers in niche corners and five is AI building rockets on its own, where are you for the foreseeable future?

About three and a half. At some point somebody still has to get their hands dirty, and that part is physical. I love humanoids, but I do not think we will have them building Starships any time soon. And I do not think you will be handing the design of a rocket to AI either, the hardware or the software.

Any other interesting AI companies in engineering you would highlight?

Everybody knows them by now, but Flow Engineering. I was a user in 2023 and 2024 when it was very young, and they inspired me to quit my engineering life, because I saw you could build new software for engineers and actually beat the legacy systems.

Then CoLab, who I like a lot. They bring a certain kind of value to 3D design and 2D drawings, and we are working on bringing that same value to documentation and processes. Documentation is broader and more human, but most of what they solve applies to it too. Lessons learned, change management, updating things automatically, drafting things automatically.