Fred Brooks, in his 1975 book "The Mythical Man Month" makes a lot of sensible points that are still true today (albeit some of writing is quite gendered and could do with an overhaul). On the subject of estimation, he suggests planning to throw the first version of software away ... on the grounds that you'll probably bin it anyway, so you might as well plan for it. With the caveat that the maxim applies to new or unfamiliar technology rather and routine coding work, I think this is very sensible advice.
It's important to be clear about when in the software life cycle this applies. By it's nature, the startup world brings a lot of uncertainty, so it's tempting to think that a product will need to completely re-engineered during it's lifetime. It is important to get a product into the hands of real customers as quickly has possible, to begin the process of feedback and iteration. But if you understand your customers reasonably well and you've been through a process of even rudimentary co-design with them, it's unlikely that your MVP will be completely wrong and destined for the bin.
In my experience, provided you've had input from a few likely customers and you've listened to them, the first few versions of your product are likely to be evolutions, rather than completely new.
But in the very early stages of technical planning for a new project, when you're making the early architectural decisions, it's unlikely that you will know all of the questions you need to ask - let alone the answers. At this stage, it's highly likely that you will make some choices that turn out to be incompatible on a fundamental level, or that something dismissed as an edge case early on turns out to be central to the way a system needs to be structured. This is the process of discovery that Brooks was getting at ... it's only once you've spent some time working on a new project that you understand it well enough to make the right decisions. There's no shortcut to this and there's no shame in throwing away version 0.1 to start again from scratch ... particularly if you've allowed time in the project plan for it!