Deciding which facts are "relevant" to the customer is a pretty dicey proposition: why do you assume that the fact that no code has been written is irrelevant to the customer? Just because the sales guy wants it to be irrelevant doesn't mean that the customer shouldn't have the right to make their decisions based on the actual facts, rather than what's convenient for the seller.
No, if the facts are important to the prospect, the prospect asks about them. I didn't read anything in this post about them supplying false answers to direct questions.
You are not obligated to provide SEC disclosures along with your pitches. I do that, and it's a horrible habit and something I've been trying hard to break. It communicates nervousness and lack of confidence.
Again: you can't just make stuff up. If the prospect asks, "how much of this stuff actually works", you need to be clear --- "we're still in the design phase". But if the prospect doesn't ask, the prospect doesn't care, and you let it go.
Fair enough; you're not obligated to disclose everything up front if they don't ask. But that's a world different from making a deliberately misleading statement.
If someone says "We're actively developing this" I'm not going to just assume I'm being mislead and say, "Sure, but do you have code?" The statement implies an answer to the question, so I'll feel like I already have an answer to the question, and I'd be wrong.
So no, it's not a direct answer to a question, but it's meant to imply an answer to the question so people don't ask anything further. Deliberately attempting to mislead people is just as bad as outright lying in my book, and I can't see the way that statement is worded as anything less than an attempt to mislead the potential customer.
Calling them "screenshots" and using the word "development" both in the present tense when talking to potential customers is telling them implicitly that not only do you have the skills and competency to deliver this functional piece of software, but that you are already in the process of doing so. Unfortunately none of that is actually proven explicitly by what you're showing, as all of the functional coding implied doesn't actually exist.
Unfortunately for everyone involved, if all you've done is paid a designer to give you some visual and functional mockups, well, that means absolutely nothing about your ability to actually code and deliver the product.
Also the fact that they could write the code to support the designs isn't the issue. The issue is that they didn't, and didn't say so. It's giving the impression that they are operating at what seems to be an amazing speed supporting what presumably appears to be a fully fleshed out user experience, etc, when all that exists might be a design/pitch doc and some jpegs. Programmingprowess is implied. Frontend to backend functionality is implied. Progress is implied. When you leave things implied, then blame your customer for not catching the fact that you weren't explicit about details and therefore you weren't lying to them after all, you're doing it wrong.
It's like that episode of Arrested Development where they go to show clients a model home, only to have one of the walls fall down to reveal nothing inside but a bunch of air, and two people who thought they were hiding inside making out.
They may not be lying with this approach -- they do have screenshots, the same way the guys in that sitcom really did have four walls and a roof -- but they're also setting themselves up for a pretty killer "I don't think you've been entirely honest with me" conversation with a client if one of those walls happens to fall over a bit and reveal what's inside.
