> Confident that our product is fast and accurate enough to solve real-world QA needs, this has been a long journey and many things helped us get to this point.

This sentence has a very common grammatical error called a dangling modifier. In this case, notice that the adjective (i.e. noun-modifier) "Confident" is intended to modify the pronoun "us." But, if we look at the sentence, the subject of the sentence is the pronoun "this"! Because introductory phrases (from Confident... to the first comma) are naturally attached to the subject of the sentence, it sounds like the target of "this", namely "the long journey", is the target of the modifier.

Generally you can catch these by reading your work aloud. Once you read, "Confident that [...], this was a long journey...", hopefully it will throw some red flags that this sentence "doesn't make sense." Another technique (of error location) is shortening the sentence to make the error more pronounced: Confident that we're awesome, this journey has taken us far.

Potential rewordings (of many):

It has been a long journey and many things helped us get to a point where we are confident that our product is fast and accurate enough to solve real-world QA needs.

Confident that our product is fast and accurate enough to solve real-world QA needs, we're reaching a milestone in our long journey.

If we also try to introduce some brevity:

After a long journey, we're confident that our product is fast and accurate enough for real-world QA.

[0]: http://xkcd.com/356/

Edited to add: this is meant to be helpful to the poster, who also wrote the post (I assume). It's not a commentary on their product, since as I said, I never did get past the first paragraph.

Instead, maybe, what trouble did you have when dogfooding? Did you ever run in the situation that you couldn't proceed because of a bug in the then-being-dogfooded software? How did you get by it? Did engineers like it? How about non-engineer team members? Did the dogfooding influence the way you prioritized?

Sure, I like that the second part of the blog post says "we found some new requirements because of this", but for me, as a programmer of another piece of software, it would've been much more interesting to find out how you got to those requirements and how you dealt with them, rather than what the new requirements were. I mean, every software team finds new requirements all the time.

I mean to be constructive here: I strongly doubt blog posts about how awesome your own tool is and how using it yourself made it awesomer is the best approach. By turning it less into promo and more into general experience-sharing, the post may be more generally useful and thus spread further.

How long am I going to wait to get a tester? Does this change over the course of a day? Do you use more than one tester to consider something a 'fail'?

Overall your product looks good, definitely going to keep it in mind.