Firstly, I disagree with the Assembly model, but that is another discussion for another day. Salesman rule for product pricing (something I need to adopt mysel

Firstly, I disagree with the Assembly model, but that is another discussion for another day. Salesman rule for product pricing (something I need to adopt myself): price your product at a cost that is similar or cheaper to your competitors. Go cheaper if you have less features, but keep adding more and you can possibly steal away customers from your more expensive competitors. If you have no competitors, your client-base and their usage should've given you an indication of where to start pricing. Companies pay ridiculous amounts for things as trivial as chatrooms, so if you're automating away DevOps/System-Administration, you can charge a decent chunk of change that will come cheaper than say $4,000 per month for a senior system administrator. I've also heard of a theory where if a product is too cheap, some companies feel that it is a weaker/inferior product. For any startup/side-project type person, create a special tier where you reel them in and hook them onto your services. Paying $25 per month to monitor servers 24/7 and avoid downtime[1] is an asset for 2/3-man teams. I also agree with taprun about the free tier. Would you run RunBook on that free shared-webhosting site? There's tons of people who would like things that aren't free to be given for free. This is called "free-riding" in economics and you are basically swallowing their costs. IMO, giving the source-code away for free is good enough. Create a trial period and have a pay-only service. You'll end up on-boarding shitty customers (which are probably at +10 to 1 of your paying ones). [1]: Like everyone else, I don't actually know what your service provides (clearly). To me it seems like an automatic server-monitoring service that detects and tries to fix errors.