"Sales" is a long term process, but the first meeting usually starts with understanding the customer's problem. If you build something before that (and demo it at the beginning of the meeting), you can bias the process with your assumptions. Instead, if you try to get inside the mind of your customer, you can get closer to the correct solution.
For a lot of those first sales meetings, you don't necessarily need technology to demo. Instead of showing/telling your customer, you're starting by listening. Then, you can build a small demo of something interesting before the next meeting (often, this is more to keep the conversation going and explore new ideas than to immediately solve the customer's entire problem).
I agree with the other comments mentioning an initial (days/weeks long) MVP build cycle. However, over the past few years, I've found it helpful to adopt this mindset: "my idea for the best possible product is at least slightly wrong, and the more code I write the harder it is to fix". There's a psychological concept of functional fixedness, where you view an object only as its traditional use. I think a similar concept exists in technology. Particularly as a founders-only company, the technology you build has some inertia, and impacts your mental models of the problem you are trying to solve. The more code you write, the higher the "cost" of changing (both in your mental models, and the technology itself).
All this really means is you're right about the build a little/sell/build more cycle - but what you build is less important than what the customer says. The first build is often just a means to start an interesting conversation about the customer's true problem, and you might need less technology for that than you initially assume.