I have to admit, I have been going on for years and years because I can see that it will work, no matter how much I hate it at a particular moment. I can't claim that this is the best approach, or even a good one, but that's what I'm doing: not quitting. I guess it's not really a decision. In the past, a free competitor caused me to quit - but that was a mistake, because mine was still valued, so I unquit that project (but I was uninspired, so I focussed on the next one - I guess inspiration is another factor).

You need information to make these decisions. I like Steve Blank's idea that your startup is a process for finding answers to questions, like here's my idea, I think these people will need it - do they? Try to get this information as early as possible - before version 1.0, before version 0.1, before any version, before any planning or design. Some questions will require a version 0.1 to find the answer.

So, try to formulate the specific questions, that if you had factual answers to them, it would be obvious to you whether to stick/pivot/quit. Then work at obtaining those facts (instead of at "keep pushing forward".) Some of them, by their nature, might take a long time or a lot of work to obtain; but because they are concrete, specific and factual, it's easier for you to decide whether it's worth finding the answer or not. Or, just by thinking in these terms, a brilliant short-cut for getting this information might come to you. [Note: I haven't actually talked to customers, which his approach says to; but I have researched my questions in other ways, which was very revealing.]

Some startups also have engineering questions, is this technologically feasible, can I get this to work? A similar approach applies, where you try to solve the bare essence of the problem first; customers can't tell you about this aspect. [Note: I do this all the time; unfortunately the basic "is it usable?" question can require a substantial prototype - a lot of work]