I’m back from a delayed holiday vacation. Please see inline.
- If it turns out that support or maintenance take much less time than expected, how would you deal with that? For example, will you bill ZOMG for less?
We’ve been consulting in one way or another for 15+ years. In that time, we’ve come to learn that billing for time and materials is a poor way of aligning the interests and motivations of the value creator and beneficiary. It also introduces time and attention consuming overhead that often negates any value to the beneficiary in disputing charges, etc.
What we’ve done instead and with success over this time is to try and bill for value provided. This means agreeing to the value a deliverable provides prior to the project starting, then tracking whether that value was delivered.
That said, the approach we’ve taken in the pricing is to combine a T&M approach with a value based approach. This results in the flat fee. The flat fee is basically the mid-point of a range of time estimates.
So rather than track time, we’d much prefer to agree on a value up-front, with measurable parameters, then track those parameters. If we come-up short against the parameters, we don’t get paid the full fee. (In a symmetric example of this, a service provider gets paid the full fee if they meet expectations, lesser fee if they don’t and greater fee, i.e. bonus if they exceed them.) We feel this maximizes the alignment between the Zcash community and us, the service provider.
- Do you have a sense of who will use this in the period it’s available for? This seems a bit tricky because even if in general we want this to be available, it’s hard to fund if it seems unlikely that people will use it. Do any existing wallets need a “backup” solution in case their main server goes down? Are there any teams that need a testnet solution?
The way we approached minimizing this risk (and others) was by limiting the project’s duration. The idea was that after the initial period of performance, the community would look at the value created, including usage, and determine whether the project was worth continuing. (Hence PoC 
in the title.)
We could also then adjust our original quote to expand it over a longer-term, amortizing any start-up costs in this original post, while applying learnings to possibly reduce ongoing costs, if possible.
Of course, one risk with this approach is that the services aren’t around long enough to gain traction. Yet as I’ve been saying all along, we’re in this for the long run and are glad to provide services as long as it makes sense for both sides to do so.
Our sense was that the Zcash community has recognized the need for additional infrastructure. It’s to that
stated need we submitted this grant application. We have’t done direct user research to validate demand. In these early days, we feel an empirical approach is the prudent one, rather than trying to estimate user demand. Yet we can imagine that any developer who wants to get started building on zcash quickly but doesn’t want to deal with the hassle of running infrastructure would find this service valuable.
I hope this response answers your questions. Please let me know if it doesn’t and I’m glad to fill in the gaps!
I will be keeping an eye on notifications moving forward!