It would be worth spending 10 minutes to write up some quick copy to that effect. When I entered my URL, I felt like it went into a black hole as there was no mention of "what happens now".
During all the months of work on this, at what point did someone tell you, "I've been looking for something exactly like this."
At the risk of straining the analogy, the pizza might be tasty, and the box might be attractive and functional, but if a pizza delivery guy showed up at your door unexpected and unannounced, would you just pay him, or would you be more likely to say, "I didn't order this."
I wouldn't claim to be any kind of expert, but the advice you need to hear right now is: start. Write about what matters to you. Don't wait to come up with a coherent thesis or mission statement about what your blog is before you've written the first post. If you start writing regularly, you'll find what you care abut and what resonates with others, and that's the sweet spot where an audience can potentially be found.
The article had a few good insights in the first few paragraphs about the problems they were looking to solve: "pogosticking", structuring of search results, steering users toward the features that their data showed mattered most, etc.
There are two approaches that I would consider. The first is simply to ask: does your development work absolutely require large test data, or might it be possible to reduce the size through more precise selection? And more to the point, if such is possible, is it possible with a reasonable amount of effort? This is such a common problem that my guess is you're not the only one trying to solve it.
If the size of the data set is essential to your development, then could you set up a development database server on dedicated machine (could be an old workstation/laptop) on the local network that could act as common infrastructure for the whole team? This would only work if your application supports connection to a remote database, but it would solve the problem of externalizing the need for a database and sharing that resource among your development team rather than having each of you running a big DB locally.
Most long-term predictions tend to be made by people living in pockets where the future has already arrived, but it seems appropriate to recall Gibson's prediction about uneven future distribution. Trying to extrapolate based on local maxima will always produce a trendline that outpaces reality. To his credit, I don't see any flying cars here; the author bases many of his predictions on innovations and trends that are already to some extent or other in progress. But in order to bring a change from possible to widespread, it has to be commercialized first, and I struggle to see a profit motive for some of these things, even in the next 30 years - i.e. energy consumption monitoring by Google when electricity is cheap thanks to nuclear fission, etc.
Seems like a weird strategy. I admire the focus shown, but what if Thomas Edison had decided after 10 years to rebrand GE as Something Something Light Bulbs, Inc?
The article isn't clear on it, but there have been studies (http://baymard.com/blog/making-a-slow-site-appear-fast) that show the perception of fast loading is actually more important than the real thing. Showing the user a "Loading..." graphic is the most common manifestation of this, but there are others. (Unfortunately, the original Forrester-Akamai study seems to be unavailable.)
There's no such thing as easy money, and I think most people will tell you that going from $0 to $1K MRR (and sustaining it) are a hell of a lot harder than the journey from $1K to $2K.