FAQ

The questions that actually decide this.

Including the one we cannot fully answer on a web page, because it depends on how your deployment is set up. It is marked, rather than papered over.

We already have SAP PM. Why would we need AMS?

Because they do different jobs. SAP PM plans, schedules and costs work extremely well. It was never designed to be the place a tradesperson records that a coupling guard is cracked at six in the morning, three levels up, with no signal.

AMS is the layer that captures that, scores it, and hands it back as a properly coded notification — object part, damage code, priority, photo, and the round it came from. Your planners see work arriving in the system they already live in, correctly classified, without anyone retyping a clipboard.

If that job is already being done well at your site, you do not need us, and we will say so on the call.

Do you replace our CMMS?

No, and we would argue against it. There is no preventive maintenance plan authoring in AMS, no costing, and no intention to add them. The entire architecture — no database of its own, everything over HTTP, a published REST surface in both directions — exists to make AMS an overlay rather than a system of record.

A migration project is the fastest way to make an inspection improvement take three years and fail. This deliberately is not one.

Can you connect to Maximo, or our CMMS?

Not today, and we are not going to imply otherwise. The only ERP integration running in production is against SAP Plant Maintenance, and it was built for one customer against their configuration, their catalogues and their API gateway.

Architecturally nothing stands in the way — AMS already talks to everything over HTTP and publishes its own REST hub, so your system could read and write through that with no changes on our side. But a real integration to a system we have not worked against is scoped work with a price and a timeline, not a configuration switch.

Where does our data live, and who hosts it?

Two parts to this, and the first is more interesting than vendors usually admit.

What AMS holds. AMS keeps its own register of the equipment you inspect and the company, area and location structure around it, plus every inspection answer, defect notification and risk measurement it records. It holds all of that through the DDF API rather than in a database that AMS owns and connects to directly. Your equipment master, work orders and functional locations stay in your system of record.

Where it physically sits. That depends on how your deployment is configured, and we are not going to publish a generic answer that turns out not to apply to you. Bring it to the technical walkthrough and ask specifically about tenant, region, backup and retention. It is a fair question and it deserves a specific answer rather than a paragraph.

The architecture behind this

What happens to our records if we stop using AMS?

Your inspection history is not locked behind a screen. Registers and logs export to Excel directly from the product — the employee register, org positions, work order search results, the risk measurement log and the authored rounds. The REST hub exposes documented read routes for planned rounds and risk assessment logs, which your own systems can call with an API key.

A full structured export on exit is part of the commercial conversation rather than something we can promise generically here. Ask for the terms in writing during an evaluation — and ask every other vendor you are looking at the same question.

Who are Dynamic Build Systems, and how big are you?

A software engineering consultancy in Technopark, Stellenbosch, South Africa, working with manufacturers since 2016. The practice is led by Gert Coetzee, who has spent more than twenty years designing and implementing the systems that run manufacturing operations — from furnace control rooms to plant-wide analytics.

AMS is not the only thing we build. We also do IT governance, Microsoft 365 and Azure work, and plant analytics for manufacturers closer to home. The rest of it is at dynamicbuildsystems.com.

We are small. That is the honest answer and it cuts both ways: the engineer on your call has read the code path you are asking about, a configuration question gets answered in the conversation rather than raised as a ticket, and there is no account manager to get past. But we are not a multinational, and you should not evaluate us as one. The next question on this page follows from that, and it is fair to ask it.

What happens if Dynamic Build Systems is not around in five years?

The right question to ask a small vendor, and here is what can be said factually.

AMS holds your records through an API and exports them to Excel today, so the data-recovery half of the risk is already partly answered — you are not facing a proprietary binary nobody can read.

The rest of it — source escrow, handover terms, what a transition would look like — is a contractual question rather than a product one, and the answer belongs in your agreement rather than on a web page. Raise it in the evaluation. A vendor who gets defensive about that question is telling you something.

What does it cost?

There is no price list on this site, and a made-up range would be worse than none. What can be said is what is not a surprise line item: the Syncfusion component suite AMS is built on is included in a deployment, not something you go and license separately.

The shape of it is a licence for the deployment plus scoped work for the parts that are genuinely bespoke — loading your master data, and any integration against your system of record. Configuration is not billed as development, because your engineers do it.

The number itself depends on your site, and we would rather work it out with your estate in front of us than publish a bracket that is wrong for everyone. Ask on the first call; we will not make you sit through three meetings to get to it.

Do you have public reference customers?

Not on this site, by policy. We publish customer work as sector, asset estate and function — no names, no logos — because using a customer’s trademark as an endorsement needs their written sign-off and we are not going to assume it.

If you need a reference conversation during an evaluation, ask and we will tell you what we can arrange.

Who configures it — us or you?

Both, and the split matters. Inspection rounds, question catalogues, per-site variants, risk variables and the formulas behind them are all authored in the product by your engineers. That is the whole point of the Builder: a reliability engineer changes a round or a scoring formula the same afternoon, without a release and without us.

What we do is the initial setup, the master data load, integration work against your systems, and being available when a configuration question turns out to be a product question.

Does the mobile app really work with no signal?

Yes, and it is worth testing rather than taking our word for. Master data is cached to the device, the round runs entirely against that cache, answers and photos are written to a local database, and the queue uploads when the network returns. Sign-in sessions are cached too, so a crew that authenticated at the gate stays authenticated on the plant.

Ask for the demo with the phone in flight mode. That is the only version of the demo that proves anything.

Ask us the awkward one

The questions above are the ones worth asking. If yours is not on the list, put it in the message box and we will answer it before the demo rather than during it.

An unhandled error has occurred. Reload 🗙