Knowledge base web app -- need a demo mode

Question

I was contracted to build an on-line knowledge base that searches and cross-references many thousands of replacement parts for a niche industry. My client furnishes this app to his customers on a subscription basis.

It uses MySQL and PHP and it works great. I want to deploy it in "demo mode" to sell my skills. I want the user to see the functions, but I have to guard the data for my client.

My first idea was to obfuscate the results. That's at cross-purposes with showing how well it searches. I'm considering a limit on how many searches you can perform, but that's awkward too as someone could visit every day and get more answers than we would prefer.

Other posts I've found are about letting people interact with an app, but without the challenge of protecting a big knowledge base.

Can you suggest an approach? (Note, I put the tag obfuscation, but not sure it applies because java code obfuscation seems to be unrelated.)

UPDATE 1: About obfuscation ... I've kind of wanted (or assumed, or fantasized about) on-the-fly obfuscation. Which is kind of hard in itself, I think. One answer so far implies a one-time scramble, which is probably how I need to approach this if I do it.

UPDATE 2: Thanks for the two warnings on legitimate use. This is all on the up-and-up! I'm as ethical as the day as long, and almost as ignorant.

UPDATE 3: I have two responses, both excellent quality. Chris L. got me to "think outside the box" and provided what seems to be the best solution.

FINAL: ... and there's not that much to show anyway!

Answer 1

Screen shots ( or something similar) are your best bet. They are quick, easy to browse, and no one has to really think about what they are doing as they are looking at them.

Make sure you have approval from your client.

Answer 2

Legally speaking, be very careful: taking a copy of a system of this sort (especially its data) and using it for your own purposes can get you into a lot of hot water depending on the contracts you signed and (under US law) whether or not the system was considered a work-for-hire.

That said, my personal preference for a system like this would be data obfuscation. Change the names and numbers associated with the different parts for which it searches in order to create a system which demonstrates equivalent functionality but for a different, wholly fictional industry. (Turn things into widgets, gadgets, whatzits and so forth.)

If a potential client shows sufficient interest, see if you can arrange for a limited-time demo account with your original client to demonstrate the system at full functionality.

Answer 3

Assuming you own the application itself, the issue is that data. "I am not a lawyer", but I would not use a clients data no matter how I obfuscated it. Generate data set from scratch.

Many years ago I was with a company and we took a client's data set, cleaned it up changed the names to protect the innocent, etc etc etc, and used it for screen shots. You would have thought its own mother couldn't have recognized it. Wrong. Some time later, the client whose data it was said to us "That's our data." Nobody got sued, and there were not even any hard feelings, but the fact is, no matter what you do to it it is still not YOUR data.

"I'm as ethical as the day as long, and almost as ignorant." Your good intentions may count for nothing if you screw up.

Good luck.

Answer 4

If I were in your shoes, I would simply create some sample data to populate the database and every other eventual content used.

Then, I would choose one or more of the following options to present the product to the client:

• Screen Shots
• Screen Casts
• Real Demo

Screen casts are usually more effective than screen shots (the wow effect on the client), but they are a bit more tricky to create. Still, softwares such as Screenflow (Mac) make their creation easy and quick.

I would personally avoid data obfuscation. In the past, it turned out to be very difficult sometimes to explain the customer the data were obfuscated for the demo purposes only (even if this was explicitly stated). The reaction I got from the client was still of great perplexity.