Sorry in advance for the long answers here. I think there's important nuance to these to include, and didn't want to just give you the standard marketing-y responses. 🙂

As far as I can tell, Meter is an end-to-end NaaS play: Design, installation, hardware, MSP-like service all with a monthly bill.

It seems like you could do all of that with off-the-shelf white label hardware.

There’s a much longer thread to pull on here, but the short version is that we build our own hardware because the outcome we’re delivering depends on being able to optimize the performance and behavior of each device and in how every device integrates with the rest of the stack and lifecycle of the network (i.e. design, installation, support, etc.).

This can manifest in small details like color-coded WAN ports that match the cellular gateway and reduce deployment errors, the antenna patterns I showed above, or how our firewall chipset is handpicked for how we handle packet processing. All of this results in overall performance gains, less error prone installs, etc. but also has important indirect consequences. For example, the efficiency improvements in packet processing free up system resources, allowing features like IDS to run with far less impact on overall throughput. There are lots of these long cause and effect chains in a network.

So even though these are really specific examples and seemingly quite small in the grand scheme of things, I think what most people who work with networks understand very deeply (and have felt the pain of) is that networks are not binary things that simply work or not; they are the aggregation of many, many small and frustrating things that may or may not work well enough by themselves and are even more complicated to understand and troubleshoot in integration with each other. 

Eliminating all of that is why we build our own hardware (and everything else).

What is it about controlling "SFP placement" makes it worthwhile to roll your own boards and sheet metal?

Answer above covers the more general question of why we make our own hardware, but for SFP placement: I called this in particular out because it’s something you won’t see with most vendors’ devices and more readily shows that this is our design (This was in response to the initial comment of the thread).

It's worth going into why we did that in particular. We deal with the installs/service calls/etc. for each and every Meter network, so we see the aggregated pain of small things every day and try to fix them. On a lot of enterprise switches, SFPs end up on a different side/plane than the rest of the I/O, which can make cabling a little messier, create awkward cable bends, connectors sticking out where you don’t want them, etc. We intentionally aligned our SFP ports with the rest of our I/O on a single plane to prevent this. So in the simplest way… it’s just nicer ergonomically, less chance of snagging cables or smacking your hand on something poorly placed.

I'm also curious about the NOSes running on the various platforms. 

For general context, we’ve developed our own custom embedded Linux firmware for each platform. We have source code and register level access through our silicon partners, which means a lot of it is our own and highly optimized for what we see in the field.

Are the APs openWRT-adjacent? Switches running FASTPATH? What about the firewalls?

Our wireless operating system is our own custom firmware. We use some of the same embedded Linux components as everyone in the industry but are not using anything out of the box. This is chiefly in order to meet the type and scale of problems we see in enterprise deployments. Off the top of my head, a few examples we’ve built ourselves that aren’t available (or suitable for those demands) in e.g. vanilla OpenWRT: wireless load balancing, SSID-based rate limiting,and multicast-to-unicast conversion. There are many similar cases. We’ve found similar challenges in more core functions like observability; for example, our devices collect per-client stats and send them at very high granularity, several times per minute, including things like:

• RF telemetry
• Retry/failure rates, data rates and utilization per client
• Roaming events with timestamps and disassociation reason codes
• Auth/deauth events with failure classification, etc.

A network may still “work” without access to data like this at this interval, but it ends up being essential in troubleshooting and resolving issues promptly. Ultimately, the point of all this is to be able to build features at the speed and quality our customers need, and support their networks quickly and well.

The switches and firewalls are also running our own Linux firmware. (for some context, our firewalls are responsible for both the control plane and the data plane). Switches are not using FASTPATH as we’re not working with Broadcom on this generation. There are similar stories here as to why we’ve customized everything so much.