We realize that some similar apps charge per server rather than per site. In fact, we used to too. But there are important reasons why we felt we needed to change to limiting by site instead of by server:
Bad incentive. By charging more for additional servers, we would be incentivizing customers to cram as many sites onto a server as they can, leading to servers running out of CPU, memory, disk space, etc and a poor experience. Charging per site is better aligned with our advice to keep the number of sites per server to a reasonable level.
Value. If you take a step back and look at SpinupWP, most of the value it provides involves sites. Once you spin up a server, the rest of the functionality in SpinupWP is about sites. Configuring DNS, Nginx, HTTPS, databases, backups, etc are all site-based operations and almost all the features we plan to ship this year are site-based as well. Our costs are directly related to the number of sites you are running.
Fairness. When we charged on a per-server basis, we analyzed how many servers and sites our customers were running and we were surprised to see that some of our largest customers were paying very little. They were spinning up beefy servers and cramming dozens of customers onto them. Not only is this bad practice and against our advice (as mentioned above), but it is unfair to customers with fewer sites. For example, one of our largest customers was hosting 147 sites on 4 servers and paying just $24/month, while another customer had just 16 sites on 6 servers but was paying $34/month. Not fair at all.