Maybe you meant "Question your assumptions, often." You can't get anywhere constantly verifying things ahead of time. In the extreme case, imagine writing a test suite for printf just to be sure it works as advertised.
The way forward for a startup is to make only the right assumptions. Failing that, make as many assumptions as possible, but correct the failed ones in a reasonably short amount of time. Some minimal cost/benefit analysis on the assumption would also be good.
As a corollary to this, try to arrange that any failures will occur as quickly and obviously as possible. For instance: Component X, which is essentially a black box to you, will be a small but critical part of your project. You don't have time to extensively test it, so you make assumptions about its behavior. Ideally, you should start integrating Component X into the full project immediately such that it's heavily used in development and testing environments, so that any violations of your assumptions will show up incidentally to other work.
On at least a couple occasions, I've been bitten by assuming that a Component X (which I thought I understood) would do what I expected and thus leaving the final integration until near the end of the project. This sounds like an obvious, easily avoided mistake, but it's surprisingly easy to make in the heat of the moment.