After carefully considering what you've said, my first question is what development experience you do have. On the one hand the "finished product" overview you've provided could simply be for conciseness, or it could be lack of experience. (My point is that I have no idea.)

On the surface you're describing something that's been done many many times (kinda obvious). On the one hand this means you could find someone to work with to help you on this fairly easily, on the other hand you're looking at 5 figures easily... which is likely why you're trying to figure this out yourself, now I think about it :)

I'm hesitant to suggest looking at existing off-the-shelf solutions; I get the impression that finding systems that haven't rusted together in the areas you need flexibility is touch-and-go and hard to figure out in advance. It may go incredibly well, or you may end up maintaining a massive headache that's incredibly hard to fit-out for your needs. One possible idea that may work to some extent is finding open-source projects that implement some or all of the functionality you want; they may be useful for parts/ideas or real-world answers to "how did they solve this bit," or even better you may find they actually work for you (yay free stuff!).

While you may come up with extra defining/deciding context/requirements, the main decision point I'm thinking of is whether you consider it a must (or a huge-value add) for things to be partially functional if there's no consistent network connection. This applies to sales/management (on a train, or at exactly the right vortex point between a bunch of buildings, and cellular just dropped out?) as well as plant operators (hypothetical contrived example: a non-essential machine just went bezerk and is spouting so much RF the Wi-Fi just died). That said, generally supporting transient network loss is... hard; you need a database design that, at every point in read/write, can tolerate "another client may have committed an update but that data might not be in the query we just did yet," which the application design must be built with awareness of (it's so fundamental it can't be abstracted).

If "the plant Wi-Fi just died" disrupting operations is okay (for example, you have somone on-site who can rapidly diagnose a wide range of issues, you have spare APs and related kit available, etc), then you'll save yourself a lot of time by just developing this as a webapp. Others may argue for native apps, but if you do a webapp, you can target desktop (Win/macOS/Linux(?)) + mobile (Android/iOS) just by using media queries. Suddenly several thousand lines of Swift and Java disappear :)

With enterprise setups like this, you also get to call the shots on what you contractually agree to support Android/iOS-wise; you get to specify the minimum versions, and you can also check the user agent and throw warnings or blocking error messages for versions you don't like. This isn't a public Web site, so you don't have to work for everybody. And so you get to guarantee that certain Web APIs are available :)

In all fairness there is the AppCache and ServiceWorkers+IndexedDB can cache web apps for offline use, but I wouldn't rely on them because the storage areas they use can be cleared.

Now I think about it, you could build minimal Android/iOS shells that load your HTML/CSS/JS into a WebView with some simple caching tacked on to guarantee code availability in offline situations. That could work quite nicely, and the native codebase would be tiny. With this Wi-Fi dying isn't a problem but now you need to go back to mentally modelling eventually-consistent database schemas.

On the backend side, what sort of traffic volume do you intend to handle? Do you intend to have the backend be on-site? (You could do a managed on-site setup where you have (monitored) SSH by contract but the system runs on client servers.) This would distribute processing load across the sites. If you want to centralize everything then you need to think about how many clients you want - then double or triple that figure (and then maybe multiply it by itself) - and you should have a good idea of the sort of volume you need to be able to process. There's a reason all the "how we process 1.21 jigabytes of messages every second" posts on here are so popular! You may need to look into high-throughput, easily-shardable datastores.

Regarding those graphs... well... note that you're looking at the revenue the guy who built those graphs is getting! :D I can see there's a fair bit of intelligence in the graph displays, and fine-tuning a similar system with a quarter of the functionality is something that would take a bit. Certainly possible, but it would take a bit.

Unfortunately I have very little advice to offer in the area of actual Web development; I haven't explored the scene much yet. I know that there are a dizzying number of developer offerings available. Your best bet is to forge ahead trying them and see which one you like.

I'm not a developer myself (in that I don't have a software engineering position - nor the mindset for one, just yet); I just spend all my time on HN :)

I wonder how much more specific you could be (for the benefit of everyone) without giving anything away.

By the way, thanks for mentioning the Baremetrics demo - that's really cool that they're open like that.