Pitfall of over-engineering

I have mentioned earlier that building the wrong thing is what kills most startups. Going to great length building too much too early comes close second.

A grand vision

Sometimes I get overexcited and that kills the product more than anything else.
Here is the thought process behind SQL App:

• We really need a fast and powerful SQL query writing tool. Everything out there sucks.
• We have powerful SQL parsers with static analysis. Refactoring is going to be so easy!
• Ah, and autocomplete is such a crap everywhere. We could be pulling so much more context out of the code.
• By the way, cloud databases are really not accounted for in existing database managers. People are actually managing their data over WAN!
• And everything is so slow. Did anyone hear about a 100ms response time being a standard for snappiness?
• And those managers almost always work only on Windows, or only on Mac, or they suck even more than usual.

A minimal feature set

All right, so we need to build something that:

• Works on Windows, Mac, and Linux
• Is super-fast and responds in less than 0.1 seconds
• Has a clean and intuitive UI
• Is built as a native application and not a slow, memory-hungry, bloated Electron app
• Can also work in browser to support working with remote databases efficiently
• Needs to be deployed in all regions of all major cloud providers
• Can be deployed in private companies for security considerations
• Allows instant connection switching with all state preserved
• Allows continuing work from exact same state on a different computer so one can work anywhere
• Supports all major databases from day one, with full database-wide static analysis, because really we can't go below that level
• Supports largest databases and result-sets efficiently even if you connect over browser to a server on the other side of the world
• Is also our test-bed for SQL code translation engine
• ... and much more

I wonder why we had trouble building it.