It always comes as a surprise when you see someone use the software you wrote. The intuitive handcrafted UI leaves them confused. The main feature doesn't work. A specific order of clicking on buttons crashes the application.
But this isn't a cause to give up. It's only the first step. The next step is to improve it. Not adding new features, but improving the ones you have.
When we only have a blank canvas, it's easy to make assumptions on how things will work. You think the architecture you came up with is unbreakable. The application framework is versatile. The code will be reusable. But, once you have another person test it, you will start seeing the flaws. And you will also realize that you are stuck with some flaws. Changing the architecture might mean drastically rewriting the application.
The solution is not necessarily to put everything on pause until you can rewrite it. Instead, it's to learn to work with the broken system.
At every job I had, the breadwinner application was broken in fundamental ways. But it didn't stop developers from working on it everyday, and get paid. The question is not whether the application can be rebuilt better, but it is how we can use it in its current state.
WordPress powers more than a 3rd of the web, it is at version 5 now. At version 3, the developers had 1,217 bug fixes. They knew that they had made ground breaking architectural changes. They created something 1217 times better. But then there was version 4 where 250 bugs were fixed before adding any features. No matter what the code says, there are still bugs to fix.
The only perfect application is the one you haven't written yet. The moment you type, you introduce a bug. You just have to make peace with building broken software.