I am a big fan of SOA, which means my projects tend to be made up of a large number of very small services. With the current pricing structure, if I only do one commit a day to one of many services (builds take a couple minutes) I have to pay $80 / month. Compare this to someone working on a monolithic project doing 50 commits a day (builds take 30 minutes) who only pays $40 / month.

The current pricing structure is nice for people with monolithic projects, it just doesn't work out very well for someone working on an SOA based project.

Personally, I would like to see commodity pricing similar to Amazon/Azure where I pay for what I use. By pricing by usage (per build-hour and/or build artifact storage costs), developers such as myself who have many small projects can start with a fairly low monthly cost that will increase unboundedly as I utilize the service more.

Advantages to AppVeyor for commodity pricing:

• Lower cost barrier to entry for startups. Get people using AppVeyor on their private/business projects with minimal financial commitment and they are likely to stick around as they grow.
• No need to limit concurrent jobs. Jobs will kick off with every commit which means several commits in a row will result in several jobs, which translates to more payment.
• No need to limit the number of saved builds/artifacts. By charging for artifact storage (at a markup) you not only push the cost of large artifacts off to the customer but you also profit off of them.
• No need for limits on repositories. You can charge a minimal fee per month per repository to cover costs of monitoring the repos for commits. Users also won't hesitate to throw their private repos at AppVeyor. Under the current model, someone on the $40 plan is going to be hesitant to throw their apps at AppVeyor, possibly using other competing products for their secondary repositories. Also, someone on the free plan is likely to hesitate before committing to $40/month for their first private repo.

I don't believe that there is any compelling reason to not offer both commodity based pricing and bundle (current) pricing. They cater to two different groups of people with bundle pricing being good for those who want to have fixed costs while commodity pricing works better for those who want the build system to dynamically scale with their needs (unbounded concurrent builds and build history storage).