How GMAO CLOUD evolves

Product evolution gets little attention when comparing maintenance systems, and it’s one of the things that most determines the cost of the next five years. A system that doesn’t change falls behind; one that changes badly forces migrations nobody budgeted for.

Here’s how we do it, and what’s worth asking anyone.

Where the improvements come from

From three places, and the first outweighs the other two combined.

From the people who use it. Most of what gets added comes from a specific situation someone ran into: a missing field, a status that didn’t exist, a case the workflow didn’t cover.

You notice it when you look closely at the product. The fact that preventive maintenance checks whether the day is a holiday and whether the technician is available before generating an order isn’t a design idea: it’s the answer to someone ending up with scheduled checks in August. The fact that statuses can be flagged as do not notify comes from notifications turning into noise somewhere.

From the industry itself. New obligations, changing ways of working, sectors with their own requirements.

From available technology, which is the one that drives the least. A new capability only goes in if it solves a real problem, not because it’s available.

How we decide what goes in

Two criteria.

That it solves a problem for more than one. A very specific need from one particular site usually doesn’t go into the product: it’s solved through configuration, or through the open route — REST API and SQL connection in integrations — for anyone who needs to build on top.

That it doesn’t complicate what already works. This is the criterion that rules out the most things. Every new option is one more decision someone has to make when configuring, and a product with too many options is as hard to use as a rigid one.

That’s why there are features that have been turned down more than once even when requested: because the version being asked for would have made everyday use more complicated.

What we don’t do

We don’t charge per version or per new module. Improvements reach all three plans; the difference between them is in support and resources, not in features.

We don’t leave versions behind. Being in the cloud means there’s no “old version” to get stuck on, which is precisely the problem that shows up with on-premise systems: a major change leaves anyone who doesn’t migrate unsupported, and getting out of that requires a project nobody budgeted for.

We don’t announce what doesn’t exist. There’s code in the product with things started that aren’t in use yet, and they don’t count as a feature until they work.

What to ask any vendor

Four questions that say more than a brochure:

What happened the last time there was a major version change? And who took on migrating the customers left behind on the previous one. The answer describes the vendor better than their website does.

What happens when I need something that isn’t there today? There are three possible answers — it gets configured, it goes into a future version, or it’s billable development. All three are legitimate; mixing them isn’t, and you need to know which one you’ll get, because it changes your budget for the next few years.

Do improvements reach my plan? Or only the higher-tier ones.

How do I get my data out? The most uncomfortable question, and the most revealing.

What’s changed and is noticeable

To make this concrete, three examples of things in the product today that come from real problems.

Counter-triggered preventive maintenance. For years the plan ran purely on a calendar, which treats two identical machines the same even when they don’t work the same. Now an asset can carry hours, cycles, or kilometers with a limit and a warning percentage: when a reading crosses the threshold, the order generates itself. It’s the difference between checking out of habit and checking based on use.

The accumulated-cost alert. An asset can have its replacement cost and a percentage recorded, and the system notifies when repair spend exceeds it. It doesn’t generate an order — replacing something is a business decision — but it puts the figure in front of you right when it matters, instead of inside a report nobody opened.

The connector between installations, in both directions, for when a client and their subcontractor both use the system. It comes from seeing how much administrative work went into reconciling files between two companies that already had the data.

None of these are product ideas: all three are the answer to something someone told us.

What should change

Worth saying, because a product that doesn’t evolve is also a risk.

Mobile operating systems change, and an app has to keep up. Regulatory obligations in some sectors shift. New ways of working appear — full offline mode is one of them, and ten years ago almost nobody offered it.

A vendor that hasn’t touched anything in years isn’t stable: it’s stalled.

What doesn’t change

Above the features there are decisions that stay in place and are worth knowing, because they shape how the product is used:

Unlimited licenses across all three plans. Real offline mode in the technician app — not in the client one. Three separate interfaces by role. And configuration by family with cascading resolution, which is what makes managing hundreds of pieces of equipment viable.

And a way of describing things: saying what the product does not do. That legal maintenance isn’t a module. That no software guarantees regulatory compliance. That there’s no visual report builder in reports. That the works module isn’t a construction-project management program.

If you want to propose something

Much of what’s in the product comes from someone who ran into a problem and told us about it. If you have one, you can write to us.

And if you want to see how it looks today with your own equipment, you can request a demo.