It would be great if every time we build a new feature, we got it right the first time. However, that is not how it works.
As developers, we are consistently working against the clock. Occasionally, we can find ourselves thrown in the hurry of sprint--building custom components with complex requirements.
And, at times, we can look back in review and ask, "how did the iteration go down this path?"
It is 100% fair to say there are always small improvements to make to the initial implementation. And, it is also completely acceptable to stop and question:
"Should we scrap, refactor or rewrite?"
Sunk costs should not drive a decision to stay the course. If a reflective review of the work points to better approaches, then leverage the knowledge--and potentially, even portions of the code--to get it right.
We can see in this "before & after" example of the HTML, that the structure really got off to a bad start. Choosing not to leverage HTML's List structures left a scenario where many ad-hoc classes were required to try to replicate to a hierarchy.
50% reduction in lines of code plus a much easier to read structure
This, in turn, led to a CSS rat's nest and tons of JS click events to produce a result that could not even meet our standards.