What you propose overall sounds like a good approach (and is not dissimilar to what I’ve been working on for the past couple of years). In terms of how to package it up, keep in mind that a single snap can contain multiple “apps” / services. So for a start, it sounds like the best approach would be to just package everything up together - or at least there is no fundamental reason not to do that. This approach also comes with the advantage that if you make are any changes, all services are guaranteed to be upgraded in sync - i.e. you don’t need to worry about maintaining backward compatibility among the different apps.
That said, you can of course also package things up as multiple snaps, which potentially even share files via the content interface. Off the top of my head, here are some cases where it may make sense to have multiple snaps:
- Where your suite contains core services/libraries that rarely change, as well as peripheral functionality (or provisioning configurations) that change more frequently. This way you can avoid re-downloading the core every time the peripheral functionality needs to be upgraded. There’s some discussion of this here: Breaking up snap into inter-dependent parts
- If different appliances will have different (modular) sets of functionality that you don’t want to always bundle together