It is a bit of an XY problem: what you really want is isolation, but you think that you need subnets to implement it - not really!
Any competent LAYER 2 managed switch can make certain ports be "isolated", i.e. they can only exchange traffic with non-isolated ports. The router (I assume from the ISP) would be plugged into a non-isolated port, and each office's switch would plug into the port configured as isolated. This will do the isolation part, but it won't provide subnets: but you don't really need subnets. All nodes will be on the same subnet, but nodes in any one office won't be able to exchange any traffic with nodes in the other offices.
You may now consider delegating some administrative authority to each office - i.e. letting each office allocate some static IP addresses, without worrying about conflicts. If you'll go modern and have all internal nodes run IPV6 only, then this is not a problem: there realistically won't be any IP address conflicts if you assign the static addresses correctly (i.e. the non-prefix part must be random). No "subnetting" necessary.
If you want to support IPV4, you can act "as if" there were "subnets" for machines with static addresses. First, let's say that the router will be configured for LAN subnet to be 10.0.0.0/16. You can then agree that each office only allocates static IP addresses in some fixed 10.0.x/24 block - but this would be for the purpose of address allocation only, the subnet wouldn't change. This would be one practical way of delegating static address assignment authority to the offices. E.g. offices 1-8 would be allowed to statically assign addresses of the form 10.0.office.n, where office=1..8. The DHCP server on the router would of course be configured to assign addresses outside of the fixed range, e.g. it could assign from 10.0.16.1 to 10.0.23.254. As long as the dynamically assigned address range doesn't overlap the statically assigned address ranges, all is good. Port isolation is handled by the most rudimentary of managed switches, so all this is easy to set up and a viable solution.
If you want to go the full "subnet per office" route, you have some choices too:
If the router provided by the ISP handles VLANs, then you can go the classic "one subnet per VLAN" way. On the router side, you'd assign one vlan to each subnet. Then on the LAYER 2 switch, configure each office's port so that it considers that VLAN as "native", i.e. that matching VLAN traffic gets the VLAN tag stripped on leaving the port, and non-tagged traffic gets the VLAN tag appended on entering the port. You can also forbid/drop all tagged traffic on the office ports, so that there'll be truly no way for an office to be in the "wrong" segment. The router will see only VLAN-tagged traffic, the office ports will see untagged traffic and automatically tag/untag it, and all is fine.
If the router provided by the ISP doesn't handle VLANs, then at least it should support multiple IP addresses (and thus subnets) for the LAN port, and thus also an individual DHCP server configuration for each subnet. Port isolation on a LAYER 2 switch would be all that's needed then. If the router is "semi competent" and provides multiple IP addresses per LAN port, but doesn't handle multiple DHCP subnets, then sometimes the "LAYER 2/3" switch may let you configure a DHCP server for each subnet.
If the router provided by the ISP handles neither VLANS nor multiple IP addresses on the LAN port, then the router has to be configured with the "big subnet" 10.0/16, and a single IP address. The switch would then need to offer some functionality to bring the packets from the router into the individual VLAN based on the MAC or IP address (the VLAN would be totally virtual and within the switch only). Various "LAYER 2/3" or "LAYER 3" switches handle this differently, so there's probably no way to know ahead of time without reading the detailed documentation for a particular switch. E.g. Aruba/HPE switches (I'm familiar with the 5400 family) don't generally do packet rewriting, but their packet filter can do packet categorization, so a packet in a given category can be sent to a given port, letting the packets destined to the router "escape" their VLAN and go to the router port).
If the ISP-provided router is too dumb or too buggy to do what's needed, the other option is to configure the router in bridge mode, and plug-in a dedicated router box between that and the offices. There are various affordable but proprietary "small business" routers that would have the necessary number of ports and bandwidth to handle this job easily. If you want a non-proprietary solution, then a pfSense "box" would do it - then it's up to you how nice vs. cheap you want the hardware to be. There's bespoke pfSense-compatible hardware packaged in "router-like" boxes, essentially a specialized Linux box (with Intel or ARM CPU). Or you can just buy any off-the-shelf PC with a minimum of two PCI-E slots, and stick two 4-port gigabit cards into the slots. The upstream port would be the one on the mainboard. You'll find that a number of "competing" solutions will end up costing roughly the same if they'd be in the same performance ballpark, so there's no "here's the only way to do it" recommendation possible.
A lot depends on the amount of administrative/maintenance effort you are willing to devote to all this. Some breakdown of options:
A "hands off" yet affordable solution with "overnight" warranty service for cheap may well be used HPE/Aruba router or L2/3 switch that is still under support (i.e. you can see relatively new firmware downloads available for it on HPE site), as those have rather generous lifetime warranty (but check that of course) and cost a lot when new to cover the cost of that - you probably don't want to be paying for a support contract. These don't need any maintenance other than occasional firmware upgrades if a security fix warrants that. Most other enterprise vendors offer no free support, e.g. if you buy used non-consumer Cisco gear, you have to pay for a support contract just to get firmware updates (AFAIK).
A "hands off" solution with "just buy a new one" that's also cheap would be some brand-name "small business" or even "prosumer" router - those are provided by many vendors, e.g. Asus, and any current product will have the port speeds and throughput you need, and should support port isolation and VLAN-per-subnet (but of course check that). The level of their dedication to firmware support may not be as good as that of big enterprise brands, but there'll still be relatively timely updates that fix security bugs - that's most of what you would care about anyway.
A somewhat less "hands off" solution may be any sort of a pfSense box, although when set up the right way those too can be very easy to upgrade and keep going - maybe even easier than enterprise-class gear - the key is to have the configuration supported by the base packages, and that'll certainly be the case for what you have in mind. I'd suggest not to be tempted to add "bells and whistles", since those can easily introduce various kinks that will need troubleshooting/configuration time. E.g. don't worry about a local DNS proxy, etc. Keep the functionality limited to what you absolutely need, and resist the urge to tinker other than doing necessary software upgrades to stable pfSense releases.
As for what to do WiFi-wise: I'm using UniFi at home, but that's not end-all, be-all. UniFi access points are awesome, but their routing solutions (UniFi Dream Machine [Pro]) are not worth it: do routing/firewalling with a dedicated device, and use a UniFi Cloud Key (a current generation one) to run the controller needed to manage the access points. At home, I went with UniFi Dream Machine Pro and it's rather a touchy setup - the purported benefits of "unification" are good on paper, but the feature set in practice is has many unimplemented corners. OTOH, using a Cloud Key to run the UniFi Controller to manage the access points works very well in my experience. That plus a prosumer/gaming Asus router is pretty much all you'd need for a totally functional setup with both wired and wireless links. The access points support VLAN-to-SSID mapping, so there'd be seamless roaming, with each office using their own SSID, while kept within their VLAN.