But I'm not going to argue against it right now. It's too deeply ingrained as startup wisdom to fight it. So instead, I'll offer this compromise: if you're going to sell first and build later, at least build some basic things up front that you are guaranteed to need and that most startups don't build until long after they should.
1. You already know what your programming language strengths and weaknesses are. You can make decisions for your first product iteration already. Are you going to start with a web app? You probably already know what language you want to use. Choose your frameworks, and choose frameworks that address the OWASP top 10 at least. If you are storing data, you have a responsibility--even as a sole founder--to take security seriously. You can think about that and make decisions while you are selling, so do it. You can also make a decision to not store data or store as little as possible and choose frameworks and plugins that help you do that.
2. Along the same lines, if software is involved you have to have a way to deploy it. Set up your DevOps pipeline. If you listened to the first point, you've got somewhere to start. Take your app framework and your plugins and set up a pipeline for deploying/rolling back/backing up/restoring the very basic "hello world" version of the app + plugins. Use a service if you aren't already into DevOps personally--most of these things have a free tier. If you are looking for a native app of some kind, navigate the platform's app store at least once so you know what you're in for. Or if it's cross-platform how you will get the latest version to your users. None of these decisions matter right now in terms of what decisions you make, just that you do make them and learn how to use things.
If you are going to commit to selling first and then building, you are already shortchanging the amount of time you have to deliver after the product is sold. If you haven't made any of these decisions, the time between when you make your first sale and when you deliver it is going to be absolute shit. Give yourself the ability to use that time 100% focused on building the product confidently because you already know how you're going to build it and how you're going to deliver it.
You can have the best infrastructure, best pipelines, devops, security, frameworks, styleguides, libraries, etc. etc. Sadly none of that means you're building something anybody wants.
You can spend years building something undoubtedly technically amazing. Yet if you didn't make sure there was a market first you face the very real prospect that people will go "That's nice, why do I care?"
Your advice is great for a personal project that you don't intend to directly make money with. Still would be excellent on a resumé however.
I think if you are thinking about programming language strength and weaknesses when building a product you need to rethink your approach.
Building a great product has very little to do with technology choice, especially at the beginning. Building a great product is about solving a real pain for your target customer and solving it in a novel and delightful way.