I work in IT and support customer-facing web apps. Almost daily, I’m amazed at the requests we get for “improvements” to the system. Some make perfect sense, but some are just one-off oddball things.
I think part of the issue is that the software is designed to work a certain way. Because I keep reading “beta” in the comments, I suspect that the software is very immature. The way the software lifecycle has to work is unfortunate.
These are my comments as I see software lifecycle and have ABSOLUTELY no reflection on the products I support or the views of the company I work for. This is simply “how I see it”.
- You have to create software with low cost to market (in other words, you have to get the product to generate revenues as quickly as possible for as inexpensively as possible). This means you start with a core system with basic functionality (though limited).
- Stability is of the utmost importance. If the software isn’t stable, you have nothing to sell.
- Expand functionality, which WILL introduce new bugs, which WILL impact stability. You try to limit that stability to the new functionality (leaving the core product alone as much as possible).
- You have to triage the requests for functional improvements. The number and revenue generated by the customers requesting a specific feature must be weighed against the time and cost requirements to implement a proposed improvement.
I believe that where the OP is at right now and where the software is at, is #4. I feel that the industry norm is to have a single delivery fee. While ordering a supreme without onions may be what the customer wants, right now, if you don’t want onions, you have to type it out. Unfortunately, this will lead to human error on the make line.
If you don’t like the product the way it is right now, there’s not much that can be done – RIGHT NOW. I would advise you to request feature enhancements, get ticket numbers assigned to each specific feature request, and keep track of where they are in the product lifecycle.
The WORST thing the provider can do is start making “enhancements” every time a customer calls. This would be new builds multiple times per week, lousy levels of QA testing prior to deployment, and the other customers will be subjected to any bugs brought about by these new features.
To properly track a feature request, you need the following information:
- Feature request ticket number
- Current version of the software
- Which version your feature request is roadmapped to.
- Avg time to release (how many versions per year?)
- Target date for the roadmapped version release date for your specific request.
Note that #5 is the hardest part. Target dates change as priorities change and your feature may be pushed to a different release (later OR sooner, but usually a later version).
Once you understand where your enhancement request is slated, you can determine whether you can wait that long or not.
Each release will have multiple bug fixes and multiple feature enhancements unless a version slips out with a major bug and then that bug will be patched and a quickfix deployed.
Version numbers are as follows:
x.x.x (1.4.2, for instance)
1 is the major version. Major versions happen infrequently and sometimes almost seem like a complete re-write. The user interface may get a complete overhaul in a major version.
4 is the minor version. These are normally enhancements and can actually be numerous enhancements.
2 is the build number. If it’s just 1.4, the build number is 0. Most stable versions aren’t .0. 
For fun, the Windows control panel app in XP is 5.1.2600.0. Microsoft uses 4 sets of numbers for theirs. 2600 changes in the control panel app. WOW. However, that doesn’t mean that there were 2600 different published versions. Most versions never see “production”. But every minor change, even a space requires a new build number.
Right now, you’re simply suffering from having a young company using a young software product. What you’re seeing is, unfortunately, inevitable.