How I built a dashboard, mobile app and AI automation in 1 month to streamline cooling tower inspections.
Working in Iceland
While working on my AeroVia project full time I needed to earn some money to be able to afford my 2-month USA trip coming up. So I started working at a cooling tower company in Belgium. I initially started with doing manual labour for them in Iceland in an aluminum processing facility. I worked there for 2 weeks and we fully rebuilt a cooling tower that was only operating at a third of its capacity. It was an awesome experience to see the big facilities up close and also see the beautiful country of Iceland.
We worked with a team of 10 people of which 3 were from Belgium (myself included) and 7 from Birmingham, England. I had to translate between French and English, so my colleagues could communicate. I also very quickly took up a coordinator role to communicate with the local Icelandic management and the team.
This was my first time actually working in cooling towers but I learned a lot very quickly. I was “the guy” looking at the technical drawings and figuring out how everything should be built. Those technical drawings were unfortunately not that simple because they were created for multiple types and sizes of cooling towers and so that made it harder to understand what we needed, and which dimensions or quantities to use. After long hours for 2 weeks, it was finished!
Back in Belgium
When I came back, I did a few more inspections and manual work for the company, until I was talking to one of the bosses one day about my side project “AeroVia’. I talked about how I built a whole ecosystem with websites, mobile app, backend, automated AI agents and he looked impressed but probably also thought I was full of it. So right after our conversation I built a dashboard with the initial version of the inspection tool, in 1 hour with lots of parallel agents. This first version was highly simplified and only based on that first conversation. You could fill out a checklist and have AI analyze it and generate a full report, similar to the ones they were already making. Instead of manually putting together the PowerPoint and Excel files, the dashboard would do that for them. So I told him we should discuss this more in detail later that day. We discussed all the bottlenecks for carrying out an inspection and creating a report. The inspections were extremely inefficient and needed more attention now that the company was growing rapidly and they were becoming a bottleneck.
Even though the requirements and issues weren’t fully defined, I started prototyping the next few days and slowly over time, the issues and solutions became more and more clear. I redesigned the dashboard and mobile app multiple times and after a full month of work, they were intuitive and had all the features needed.
Problems it solves
Cooling towers usually need to be inspected at least once a year and this is done by technicians following a checklist and taking pictures. After that, they have to send those pictures and checklists to the office where someone reviews it all and selects the most important pictures and notes, and converts those into a presentation report to inform the client. This report includes all findings and actions suggested to perform, such as repairs or cleaning. This is a sequence of actions that all take a lot of time and have a lot of pain points. Here are a few:
- Missing information meant asking technicians for photos, clearer notes or measurements they could double-check.
- Separate photos and checklists had to be sent over and manually matched together.
- Creating reports could take a whole day of sorting pictures and copying explanations from older reports.
- Different languages added more work to keep reports consistent in English, Dutch and French.
The goal of the dashboard and mobile app was to address all of these issues while also improving the efficiency and automating the operations with AI.
Product decisions
I have experience building mobile apps that are intuitive with great design, so I started off by looking at my previous projects. I chose the best technologies I have used before that fit the project and determined which pieces I could already copy to speed up development. Here are a few product decisions made over time that improved the UI and UX a lot.
Keeping information together
The first versions of the app still thought about the checklist and the images as separate items. Eventually I was able to simplify by making the checklist the single entry point and source of truth. No more separation between checklist, images, separate notes, emails, text or phone calls. This means that every checklist item should have all the necessary info attached to it. I was able to boil this down to 2 types of information, image + text/voice input, together as a single package. I also removed a lot of clicks over time so that clicking a checklist item immediately opens a shared capture/notes UI where you can do everything extremely quickly and then go to the next.
If the technician needs a measurement for the checklist, they take a picture of what they are measuring + leave a voice note of the result of the measurement. For the office, they have the exact measurement + a picture to double-check what was measured and the result.
If the technician needs to document a problem they found, like a loose bolt, they take a picture and leave a voice note. Now the office understands what the problem is and has the relevant pictures together. For anything outside the checklist, technicians can take “additional images” or leave “additional notes”. Those now stay together with the rest of the inspection.
Foreshadowing: the combination of images + voice note is also very important for the AI automation. The AI understands the identified issue through the image and notes left, and is not wondering if that image is related to something else in the background. More on that later…
Flexibility without confusion
Another improvement that this workflow brings is that a technician can skip an item in the checklist when it is not applicable. In the past, they could take a picture but forget to mark the item as finished, leaving the office to figure out which pictures belonged to which items. Now the information stays together and the status is clear: untouched items stay grey, partially completed items turn orange, and finished items turn green. Before submitting the inspection, the technician can also see the completion percentage. It is not possible to submit partial information, like an image without a text/voice note, but they don’t have to fill out items that are irrelevant. This balances the technicians’ freedom with the office’s need for usable information.
Simple checklist
Each checklist item needs to be understandable for the technicians, so the initial version had multiple lines of text and sometimes additional images for clarification. However, this made the checklist very cluttered and difficult to scroll through. So based on feedback from the employees I redesigned it to show a title with only a few words for each checklist item. Any additional guidance like text or helper images is now hidden under an “info” button right next to each item. This gives experienced technicians an easy overview, while new technicians can still get more guidance when they need it.
Only the relevant projects
In the past each technician had access to each project, which meant they had to search for which one was relevant today and could cause mistakes or confusion. I redesigned this so the office prepares the projects beforehand and attaches the right users to the project, while keeping the project active for only the relevant days. This fits into the existing workflow because project managers in the office already need to prepare the communication and project in advance, now they just attach which technicians should get access to the project and what dates. Now the technicians only see their own projects in their mobile app which means they can get to work quicker without searching through unrelated projects.
From inspection to report
Once the inspection is finished, it has to be converted into a report, which is the actual valuable piece that the owner of the cooling tower cares about. This could mean looking through 100–300 pictures, checking the checklist for context and measurements, and copying common explanations from older reports to put everything together. The goal of the AI automation is to automate this whole process, leaving the office with just a simple review pass.
The most important goal is making sure that it has similar or higher quality output. So it’s important to give the agents the right prompt, context, and tools. I will break these down one by one.
Prompt
The prompt was the easiest part of the AI automation. It was about making sure the end-goal, and the steps to get there, were well described. This meant explaining to the agent that a report must only include the images that are related to an identified problem or that support the overall report, such as overview pictures. It meant explaining that not all images must be included and that most pictures taken during the inspection are for our own record and don’t need to be included in the report. From my own experience, the prompt part has become easier as the models become more capable and understand ambiguity more. I noticed with AeroVia, my aerospace data platform, that the prompt being too long actively hurt the agents because they were following guidance that might be outdated or not the perfect method for a task. Describing the end goal is usually the best way to align them. This caused the agent to find the right balance between the number of pictures to include, while still being flexible if there are way less or more images than usual, instead of setting exact boundaries like “use 20% of the images”. I improved the prompt over multiple runs with different images and notes to get it dialed in. In the future skills could also be added so that the agents can invoke those when they deal with specific scenarios or problems.
Context
The context is the part that took the most compute and planning to get right. The goal was to replace the old method of checking older reports to find patterns and reusable parts, with a full library of common problems that can be reused across reports. I used 10 agents running for 24+ hours to process around 120 old reports, slide by slide, and find common patterns and high-quality examples. This was then all compiled into 1 single library that can now be used by agents creating reports. I did this analysis within the Codex/ChatGPT app with all the threads working together and communicating. This analysis also extracted images/diagrams from older reports that show problems clearly and attached those to the library items. When generating the report this means that actual images from the cooling tower + additional images/diagrams can be included. Another step in this analysis was the translation of each item in the 3 primary languages the company uses: English, Dutch, and French. I asked my agents to do this with subagents. The translations were then reviewed and gave very good results that did not need immediate changes. Over time they might still need some adjustments, which is part of the maintenance I will explain later.
The biggest improvement with the AI automation results came after this full library was included. Earlier runs relied on the AI’s internal reasoning while now a lot of the reasoning and company knowledge was integrated into this library.
Right now the titles, summaries and actions from the whole library are included in the context window when preparing the report. The full library text in all 3 languages only takes around 3% of the context window of GPT-6 Astra, and we send even less because we only use one language. So context size is not an issue yet. Only including the relevant library items might also help with accuracy, but I did not have time to test that. I included this as an experiment in the maintenance guide handed over to the company. As the library grows, this could be replaced with a toolcall so the agent can find relevant items through a simple regex search or semantic search (RAG), instead of including the whole library in the context window.
Tools
I use the Vercel AI SDK to send the images and notes to AI models and get back a structured list of selected pictures with the relevant chapters and actions. My code then checks those results and saves them through a Convex mutation. In my other work with agents, I have found that fewer tools make it easier for the agent to understand how to use them and you can usually break down the actions to take into a few core ones.
The images are processed in batches of 10, together with their notes and the library. Once this is finished, the office can review the selected pictures, chapters and actions in the dashboard and make changes before exporting the report.
The PowerPoint and Excel files are created with PptxGenJS and ExcelJS. These libraries create those files from the reviewed report data and also ensure consistency between reports going forward. Another important point is the fact that I am using Convex, which provides real-time queries. This means multiple people can use the dashboard at the same time and see each other’s changes without having to refresh.
Results and maintainability
I remember being told that building a report manually took around 6 hours. Now the AI processing takes around 10 minutes, followed by a review by the office. So the whole preparation step only takes 30 minutes now.
At the end, each report has a standard cover with project details, slides with explanations, recommended actions and a summary at the end. The report is also generated in all 3 languages so you can easily export which one the client you are working with prefers. In 1 month I was able to simplify/automate the operations to create an inspection, hand over the information to the office, and then create a report. While removing a lot of bottlenecks and problems along the way. Making it easier than ever for technicians and also saving the office employee a lot of hours every week creating the reports.
The whole app is built so the company can maintain it themselves. You can manage the users, permissions, checklists, projects, chapters and AI prompt. I also wrote a Markdown document explaining the goal of the application and the most important architectural choices. It also explains how to deploy the website and publish updates for the mobile apps. The document mentions the fact that it will be used by non-software engineers to continuously improve the dashboard and mobile app. The employees just need to point their agents to the document and explain what they want to change.
This is how I built a dashboard and mobile app to improve the inspection operations of a cooling tower company.