We, at Maximl, think it’s a case of AI to the rescue.  

In 2025 AI dominates the zeitgeist. While the investments are welcome, they tend to be aimed at making the already software-rich even richer. As we have discussed before, there’s no practical way to measure the RoI of minutes (or even hours) shaved off the white-collar employee’s workday. Many experiments underway in the realm of agentic AI are failing to go beyond the pilot stage.  

When applied judiciously, AI, both classic and the generative variety, can transform industrial software:  

Here’s how:  

• Automate data entry. At the average plant, there are many places to get historical data from – past plans, job hazard analysis assessments, work packages, permits, job lists, inspection reports, and more. After decades of trying, the discipline of machine learning has got to a point where algorithms, code, and approaches to determining similarity between natural language documents, extracting entities from such documents are mature. The supporting software and compute infrastructure makes the economics of using AI viable for margin-constrained industrial manufacturing. Therefore, a lot of the heavy lifting involved in making the platform data rich enough and useful enough for the first user can be done by AI. That insurmountable barrier (three months of training and six months of usage before the tool becomes work critical for anybody) can finally be overcome. The risk of a significant investment reduced to shelfware goes down. Plans, work packages and permits can be created on the fly. A combination of classic and generative AI makes this possible.  

• Extracting ‘tags’ from unstructured docs, as the equivalents of primary keys. Top-down data model design is the norm in enterprise software, which presupposes two things. First, that processes have a level of standardization across enterprises. Second, that there is a willingness among users to adapt to the data model designed top down. Neither holds for industrial software. The level of structure that is within the realm of the possible is a tag, such as an asset ID that connects an element of the plant hardware, a work package, and a permit or a certificate together. The interrelationships between assets too are important. In effect, a knowledge graph of the plant – assets and maintenance workflows can be constructed with such tags  These determine what sort of work can be done simultaneously, in a safe and compliant manner (welding work when there is a possibility of flammable vapor ingress requires the performance of rigorous safety procedures). The knowledge graph is the de facto approach to creating the structure for industrial software. AI makes this possible.  

• Connect entities and attributes in a way that makes operations safer and faster. A particular asset requiring a particular kind of maintenance might require a scaffolding of a specific height (and a whole list of scaffolding check boxes), fall prevention measures, and PPE. Information pertaining to the above are locked in documents. These entities must be retrieved, their interrelationships with each other (what work packages require a scaffolding) established, and the entities with their attributes (scaffolding of what height). The heavy lifting can be done by AI.  

• Voice as UX. For on-site personnel, even texting on a mobile device might be hard under certain circumstances, such as at a height. The principles in industrial software remain the same. Use AI wherever applicable. Use the tool usage modality appropriate for the users, unlike cubicle dwellers, work with both their hands and minds. 

• AI for recommending the best/safest action. There’s a wealth of literature on the best course of action in a specific operational situation. And AI disciplines such as natural language processing (NLP) have advanced to the point where recommendations can be made. Might some sort of work at height operations be inadvisable at a particular wind speed? An AI agent could tell you.  

We believe Maximl is well placed to address the industrial software space due to a fortuitous set of circumstances: 

• We started at a time when big data was the rage. Maximl incorporated in 2016, when the big data wave was sweeping tech. We therefore have an AI-first approach to getting most out of the data that exists. 

• Focus on UX and configurability stems from the same late start. Many of our peers started in the aughts or even earlier, at a time when lengthy training sessions were acceptable. We got our start in an emerging market in the mid-2010s where the appetite for extensive training did not exist. These circumstances led to our UX being like interactive paper, and much focus on workflows and rules that do not force the client to call IT.  

• Efficiency was the primary goal for our early clients. Our peers built their software for high-income jurisdictions where regulatory requirements were stringent, and this overarching objective was compliance. In our case, it was efficiency. Maximl’s focus on configurability (workflows, rules authoring tool) and use of AO stems from this origin story.

Building software for the on-site deskless worker poses some unique challenges.  

The deskless employee or contractor cannot be expected to do much data entry when working in excavations, inside columns, next to Exchangers, on high scaffoldings, working valves, blindings, flanges – with both hands. Something possibly built on AI/ML, should do the heavy lifting on data entry. The possibilities are many.  Plants have been around for decades. Maintenance activities are standard. The taxonomy, SOPs, and best practices are all established. Filing work – be it for planning or reporting, should be largely automated. This is a natural language generation task, based on past plans, the large corpora of industry guidelines, permits, and more. In addition, there’s the hands-free mode of documenting work from the plant – voice to text.  

Due to some of the reasons mentioned before, software usage cannot be mandated. The software has to be of tangible, immediate value to the very first user.  

To illustrate, consider plant operations. Building a map of the asset hierarchy and the asset interrelationships helps create a knowledge graph connecting equipment and maintenance workflows, ensuring a particular item of work planning and execution happens in the context of the state of the plant and the many other work streams happening on site at a point in time. With a CRM solution, that no two salespeople approach the same account is achieved through a CRM administration function (most often with manual staffing) and rules governing territory – accounts manually assigned or rules manually authored, and above all a unique ID, a primary key for a unique client account.  

In industrial operations, such manual work is often not practical. Therefore, making the software useful for the first user and setting in motion a virtuous cycle is the responsibility of the software maker. To continue with the CRM analogy, sales leadership wants to get reports out of the CRM system – what percentage of opportunities are at what stage of the sales pipeline. In CRM, this is achieved by much data entry by salespeople. Manually uploading contacts, and details about pursuit activities and interactions. The salesperson does this over and above the standard sales work week – busy with cold emails, cold calls, social media prospecting, travel, networking at events, and more. The data upload that the salesperson does yields no immediate, personal benefit. It is done for a higher purpose – managerial decision making. Such top-down mandates are hard to enforce in industrial operations.  

There isn’t enough structure for a primary key either. The primary key could be an asset ID locked in an engineering diagram that needs to be extracted. This brings us to the next point.  

Software for deskless last mile operations is therefore caught in a vicious cycle where the lack of structured data leads to lack of software, and the lack of software guarantees data will never be captured in a usable form. The entire discipline is therefore trapped in a low-level equilibrium where decision makers accept antiquated approaches to managing safety and production efficiency.  

The difficulties involved in building software that helps improve industrial operations has led to software’s scope being limited to compliance, GHG reporting, and similar. These serve real needs, but the scope of industrial software can be much wider. It’s hardly the case that the banking software serves SOX compliance and nothing else. Retail, for a long time, was considered a hopeless tech laggard. That changed with e-commerce. We aim to be part of a similar paradigm shift in asset-heavy industries.

Mention ‘industrial software’ to even those in the global techno-capitalist complex, and you will hear something about ERP, IoT, and the supposed miracles drones will bring about. These are all relevant. But do not come close to the core of industrial software, which is how maintenance work might be brought under the purview of software. 

We think it is down to two things. First, industrial work is unfamiliar to the white-collar workers who make software. The product managers, software engineers, architects are physically and culturally distant from the reliability engineers and turnaround managers. The latter’s needs simply don’t reach the former. The marketing team, or insurance agents might be just one Facebook friend request or a few cubicles away. But the plant is worlds away.  

Second, the nature of manufacturing is such that the managerial cohort cannot mandate strict data sharing to the working cohort for no immediate benefit to the workers themselves but for the higher purpose of better decision making by the cohort of managers. The worker in manufacturing is oftentimes on a scaffold 40 feet above ground, operating a valve, wearing a harness. The worker, literally, has both hands full. The worker is also working a 12-hour shift, and if the managerial cohort mandates a full field report after the shift, the results are often unusable. The theatre of industrial operations isn’t like a sales floor with a gong where the sales leaders can demand CRM data hygiene stays top notch, while the pipeline remains full.  

Therefore, anybody designing and developing software for the industrial worker might work towards the following:  

• The software must be so well populated with data that the first user should see immediate value in using the tool. With industrial software, the ‘train 100 people for three months’ approach to making the software valuable doesn’t really work.  

• The software must be extraordinarily easy to use.  

• The UX must consider the physical circumstances of the field worker – both hands full, mobile device only, attention focused primarily on the job and safety.  

The above is a tall order. And some of it simply wasn’t possible at scale until the recent democratisation of AI. We think it’s this unalterable fact of industrial software that has kept this potentially large market limited thus far.  

It can change.  

The line of thinking we consider unreasonable is the idea that industry is somehow inherently, and immutably conservative on the issue of technology adoption. Well, it was said about retail as well. The rise of e-commerce and the consumerization of tech. When circumstances changed, retail did. Industry will too. 

We explore the two impediments to a larger industrial software market in two articles.  

Software people don’t understand manufacturing 

Industrial software must focus on the end user, not the corporate check writer.  

Software people don’t understand manufacturing  

It began in the last few decades of the 20th century. The university system, all across the world, started graduating fewer electrical, mechanical, and chemical engineers. Alongside the decline came the rise of computer engineers. In its early days, programming or coding wasn’t thought to be in the realm of engineering. But programming came to be considered a branch of engineering as mere writing of procedural code gave way to abstractions, Object-oriented programming, systems thinking, and the idea that those working with bits and bytes were building things of scale that’d last, just like their counterparts working with atoms.  

In the early years, the craft of programming was also tied to manufacturing sectors such as aerospace and defence. This gave way to banking and financial services becoming the dominant consumer of software engineering services. Then came the iPhone, the consumerization wave, the explosion of e-commerce, the profusion of enterprise collaboration, the primacy of front-end engineering all cultural ties between software engineering and the traditional engineering disciplines were severed.  

It naturally became much easier for tech founders to dive deep into a challenge desk workers faced, however minor, than attempt to solve a problem in an industry they weren’t exposed to.  

This might change, however, as AI destroys entry level coding jobs, particularly in front-end engineering and as reshoring becomes a theme in several high-income nations. 

Some of the STEM talent is indeed moving into manufacturing. Also, a quarter century of tech primacy has led to a large contingent of Silicon Valley millionaires. A section of this elite cohort is now bringing its smarts, systems thinking orientation, and – above all – software engineering skills to manufacturing. This bodes well for the ‘undesked’ industrial worker 

Then there is reshoring. High-income jurisdictions tend to have high labor costs and stringent regulations pertaining to worker safety. These require smart tooling. This too bodes well for the ‘undesked’.  

We now turn to the final question in this series, which is – the innate challenges of building software for the ‘undesked’ industrial worker.  

Software categories far less consequential and lucrative have received way more analyst, media, and investor attention than Turnaround digitalization. We hereby make this claim and then test it. Consider the following.  

• Collaborative work management 

• Contract lifecycle management 

• Digital experience monitoring 

• Document management 

• Marketing mix solutions  

• Marketing work management platform 

The markets have all been deemed important enough to merit a (much coveted) Magic Quadrant. These markets feature the enterprise software majors, the likes of IBM and Microsoft. They see venture funding in the tens of millions. Sometimes the founders are popular figures in the trade press. A few have even entered the mainstream media, and through it…popular culture. 

There’s no such equivalent in industrial software. 

Industrial software has vendors only insiders know about. They do great work – in obscurity. Private equity investment is the norm. Venture funding is rare. 

A closer look at the categories mentioned earlier in the article will reveal the following: 

• They are essentially slightly better ways of doing things white collar workers can already do with core productivity tools common to all modern white-collar work. The benefits are incremental. 

• The ROI of the software is somewhere between hard and impossible to measure. If a team currently manages its marketing collateral with ad hoc tools that are often cumbersome, and graduates to one purpose-built tool that makes collaborative digital work slightly easier, time is saved, and the quality of saved work presumably gets better. But how does one measure save time, and how does time thus saved translate to productive work elsewhere? How does one measure improved quality of output, where the output is routine marketing collateral? There are no clear answers to these questions.  

• No lives, limbs, or careers are lost over inadequate collaboration. That the level of collaboration is insufficient might be a challenge. But it is a challenge that’s infinitely distributed – across the entire workforce. Losses from suboptimal collaboration do not show up on anybody’s budget or KPI sheet.  

Of course, there are no regulatory requirements mandating more efficient collaborative white-collar work. No fines. No jail time.  

When a Turnaround at an oil refinery goes wrong, the losses are so big they turn up in SEC filings. The regulator worries about local spikes in gasoline prices. There’s of course the ever-present danger of injuries and fatalities. A refinery fire is front-page news everywhere.  

Yet the STO space has a handful of vendors, no Magic Quadrants, Forrester Waves, or equivalents. There’s no, as far as we can tell, venture funding either.  

Clearly, economics doesn’t explain it.

ERP is a data model, with an analytics overlay. It is rigid by design. A system of record has to be. Reliability trumps flexibility. The target audience is not the worker, but the decision maker. This used to be true for all software, even by desk workers. Decades back, desk workers (such as those settling insurance claims) had to do the actual work using tools that offered not much structure –  such as Word docs, PDFs, email, and spreadsheets, But the industry evolved systems that empowered the worker while ensuring said work did not happen outside the purview of formalized enterprise software. Collaboration tools, content management platforms, business rules, business process management, the variants of business process management such as case management – all worked towards bringing the desk employee into the web of corporate software.  

No such thing has happened for industrial software.  

Economic considerations alone do not explain the gap. The potential in industrial software is huge. Take just one use case in the industrial software landscape we at Maximl are familiar with – turnaround planning, scheduling, and execution.  

Certain heavy industries deal in chemicals that are hazardous and can potentially cause city-scale damage. Think petrochemicals, oil refineries, industrial gas producers, power generators, and downstream, metals. Due to the potential hazards, such plants must be run with extreme caution, and every element of the complex hierarchy of assets must be periodically inspected due to damage by corrosion and deposition. In addition to addressing concerns around safety and compliance, there is the question of efficiency. For peak operating efficiency periodic inspections are necessary.  

The heavy industry’s approach to solving the above is to take the entire asset offline for a few weeks every few years.  Oil refineries call them Turnarounds.  Power generators call them overhauls. Sometimes they are known by acronyms such as STOs (shutdowns, turnarounds, and outages), TAs or TARs. The periodicity and asset offline time vary. But the principle remains the same. 

This is also a big spend item for the companies considered. Consider the following: 

• Marathon Petroleum Corporation, one of the largest downstream specialists in the US, spent US$1.2 billion in planned turnarounds in 2024. This is about 1 percent of operating revenues. The planned turnaround cost figure is more than a quarter of the figure from income from continuing operations net of tax. This should put the TA problem in perspective. (Source: annual reports) 

• TA costs are material enough for downstream specialists such as Marathon Petroleum Corporation and Valero to report them in SEC filings. The former reports TA costs per barrel as well. (Source: Annual reports) 

• Going by the cost per barrel numbers reported in SEC filings, and the refinery output in the US and elsewhere, the world spends about US$50 billion per annum on TAs. 

• The question is – how much of the above could be software? 

• According to data from a federal agency tracking downstream oil, a fairly representative Turnaround would last 29 days and cost US$39 million in 2007 (Source: US Energy Administration). The most tangible source of ROI in this category is reducing Turnaround time. Every day the asset stays offline costs the refinery millions in lost sales – and maintenance bills. With a TA digitalization solution bringing in data about assets, manpower, and maintenance workflows, planning is better, and adherence to the plan is improved through the mobility modules of the TAR  digitalization solution. The theory is that the TA digitalization can reduce offline days, and the software maker can capture a fraction of the value accrued to the client – the refinery. The question is how many days and what fraction.  

• According to a Forrester Research report on ROI of industrial data platforms, shaving five days off Turnarounds is realistic. (Source: Forrester Research) 

• The same Forrester Research report says the ROI from the software is 400%. So, on average, a quarter of the value generated accrue to the software maker. (Source: Forrester Research) 

• According to the federal agency monitoring refineries, the US market sees about 100 planned Turnarounds a year. (Source: Hydrocarbon Publishing Company) 

• The US accounts for 19% of the global refined crude output. That adjustment needs to be made to estimate the size of the global Turnaround Digitalization software market. (Source: US Energy Information Administration) 

• We did the above. It stands to reason that parts of the world are less inclined to spend on tech. Therefore, a factor (0.75) has been incorporated in the modelling.  

• In addition, oil is just one industry that does Turnarounds. Process engineering industries such as petrochemicals, inorganics, metals, non-metallic minerals, specialty chemicals, and paper & pulp also go through planned capital projects that require the entire asset to be offline. Metals cover both ferrous and non-ferrous. Specialty chemicals covers a wide range of industrial projects such as adhesives, agrichemicals, cleaning agents, colours, cosmetic additives, construction chemicals, food additives, industrial gases, lubricants, fragrances, water management chemicals, oilfield chemicals, catalysts, sealants. There are chemicals with consumer applications such as in pharmaceuticals. Using industry size in terms of revenues and energy expenditure as proxies for spending on large maintenance projects, we arrive at 7.14 as the factor to multiply Turnaround spending on oil refineries with – to arrive spending on asset-heavy process industries.  

• 7.14X is a large multiple. It must be treated with caution. Not all asset-heavy industries have reached the level of awareness and technology adoption as downstream oil and petrochemicals. Not every industry is scrutinized as much by regulators and the financial markets. We apply a large deflator to 7.14.  

• After doing all the above, we arrive at an approximate figure of US$2.5 billion for the global Turnaround digitalization software market.  

• We have made conservative estimates at every step. This is likely the lower end of the range.  

Now, a total addressable market (TAM) of US$2.5 billion is a sizable market. But most in the technology industry have never heard of this category. Why?  

It is this question we turn to next. 

Industrial software for long has lagged the sector-average growth of the rest of the enterprise software market and in sheer size. Solutions for desk workers, who are always connected and often, chronically online, draws much media interest, risk capital, and talent. Industrial software much less so. 

Industrial software categories are either small or slow moving or both, relative to major and trendy enterprise software sectors (refer to Figure 1.).  

What Maximl does

Maximl, founded in 2016, offers AI-powered industrial automation software that helps major oil refineries, optimize maintenance operations, reduce downtime, and be safer and more compliant with regulations and industry norms. Maximl’s software is live at some of the largest oil refineries in the world, including the largest (Reliance, Jamnagar).

In addition, we serve various process sectors: petrochemicals (such as Haldia Petrochemicals), metals (Hindustan Zinc), power generation (Vedanta Power), and upstream oil (Vedanta Cairn). These are some of the largest companies in their sector – globally.

We offer software in two areas – Shutdowns, Turnarounds, and Outages (STO) and Control-of-Work.

The philosophy of software design guiding Maximl’s products

Maximl has several levers to achieve the ask of a 10X improvement:

An UX purpose built for the target group – the deskless industrial worker

For the industrial workers doing or supervising the maintenance work on site, the UX is mobile, resembles paper-printed forms with coloured labels, and works well in the offline mode (syncing when the connection

comes back up).