Imperative! Just as you, a developer, will want to be involved with the client's project early on, so will the potential attacker. Additionally, it's a convenient vehicle to communicate to your future clients your competence and recognition that security matters. Ideally, you'd want to throw at your back-end as many protection mechanisms as there will be in use in production. Not just to ensure the transport layer security (HTTPS), but also keep verbose access logs, run a Web Application Firewall (or similar technology), keep as tight control over who is having access to what, and more. I'll get to the other parts later, but let's first discuss the need for a SSL/TLS certificate.
There are two major points to having your web server HTTPS enabled:
First one is to ensure trust of the end user he's indeed connecting to the right web server and is not being a victim of social engineering attacks by an attacker staging a spoofed (or phishing) location where he's running a partial or a complete copy of your demo website for the purpose of collecting user credentials, or other sensitive user data. Phishing location needs not be complete, but merely limit it's functionality to, for example, presenting a fake user sign-in page, recording entered data, and repeating HTTP POST sign-in request to the real web server, so the victim doesn't suspect a thing.
The second one is that it enables transport layer security by means of encrypting transmitted and received HTTPS request and response data, effectively preventing a Man-in-the-middle (or MiTM) attacks by means of snooping on data packets and their contents, exchanged between the client and the server. Attacker, finding himself in the position to be able to listen on this communication (say, your demo client is connecting through a public access point, or other untrusted connection), record exchanged confidential information and thus collect user credentials. Attacker is also capable of changing contents of exchanged data packets, but let that be irrelevant here, since it's not really required to stir enough trouble without it as well.
There are of course other, less critical benefits to using HTTPS, such as the client not repeating request GET data (URLs) to another web server in referer HTTP header field, but let's, for the sake of brevity, limit ourselves to the first two benefits regarding use of HTTPS and dangers of running even a demo setup without it;
So the would-be attacker could gain demo client credentials. You'd now naturally ask, what's the big deal? Well, this greatly depends on the way you create these demo clients (whether you're sending them random user credentials they can use to sign-in, or let your demo users choose their own passwords), and what access is such demo user granted upon signing-in. Regardless, the attacker could learn a great deal about the inner workings of your web application (means of accessing confidential information, data structure, website structure, CMS location, and even means of editing user data), follow your progress in thwarting against potential threats, inspect for vulnerabilities you might have unwittingly left open, and use that to his advantage later on, on any production servers you might obtain contract for. And heavens forbid, if you let your demo users use their own passwords, some of these might even repeat on production servers, or users might use them to access other accounts. Needless to say, this could potentially spell disaster both for you, as well as your potential clients.
To thwart against such threats, you would want your demo server to be as secure as your production server. This will also present an opportunity for your demo clients to test your solution's suitability, communicate required changes to it, and generally improve your odds you will be selected as the solution provider / developer. This is especially true, where security related certification is required before deployment, for example in the financial or healthcare sectors. I'm going to repeat some of the obvious recommendations, and add a few more as I go:
Make sure you're creating demo accounts on your own, assigning them random and utterly meaningless passwords, and you don't let your demo users choose their own. Clearly visually notify the user, he's using a demo web application, to avoid them entering production passwords by mistake. Keep a tight control over who receives which sign-in credentials, and only ever send demo passwords via secured channels, preferably in person. You could print out a few dozen business cards with these demo credentials at their back, give them to your potential clients in person, and write down who received which demo account. Require password change upon user's first signing-in, and display clearly written security warnings, such as their newly chosen password shouldn't be same as they use for any other services.
Track user activity by enabling verbose logging, throw in a well configured WAF for good measure, and regularly check their logs for suspicious user activity (network scanners, fuzzers, brute-force attempts, illegal sign-in credentials used,...). Promptly block any offending IPs, or disable a demo user account and send out new credentials, if needed. Protect access logs and other statistical data from unauthorized access both remotely as well as locally. Don't log any personal information or user credentials, and use encryption and/or password hashing wherever applicable.
Make sure you use this fact that you're properly protecting access to your demo server also to your advantage with the potential customer. Build on their trust that you know what you're doing, that while this demo access might be less convenient, it's there for good reasons, and to protect both of your investments. Train your sales personnel accordingly.
In short, don't provide for a would-be attacker a test platform and a convenient overview of your built-in protection mechanisms. If you can't afford a SSL certificate for each demo server you set up (even if you can get them for free, it will involve work to set servers up), then host them on the same location and distinguish between demo clients based on their credentials. Don't use a self-signed certificate, not to give your potential customers wrong impressions that you're disregarding usability and end user convenience, and to also avoid other threat vectors. Use the fact that you're serious about protecting your clients to your advantage during sales. Constantly test your web application and server security, and follow latest developments in the IT security arena.
