1. For the most part, with Reploy, users either
a) Use a staging db
b) Seed their environments with fixtures or test data.
c) Do a db dump of a common db
Each of them have their own tradeoffs, which, from your knowledge of the space, are probably not worth describing in depth. The most ideal situation given your description is probably (c) because you can control what data is being seeded into each environment and introduce test data that everyone's staging env can then use.
2. I agree, but the problem here is that "any number signifying quality" isn't very easy to metricize. From our current users, Reploy is generally a no brainer. i.e. they go through the flow of having to spin up so many staging envs (or are annoyed by the lack thereof) that they use our product. In the near future, however, from a marketing/sales perspective we do want to do work to figure out who exactly is feeling the pain the most, as this is who we want to target.
What's your background building these types of tools, if you don't mind me asking? Definitely down to discuss more!