Demos are a very useful thing. It's perfectly reasonable to produce a lightweight demo version of a product idea before committing to developing it fully. After all, you don't want to expend unnecessary development effort on a product that may never catch on with your customer base. You want to get it in front of them and show them what it can do, or rather, what it will be able to do.
Demo builds tend to use a lot of smoke and mirrors, often mocking data rather than connecting to a real database or production API, and usually only implementing the key features that the business wants to showcase to potential customers.
This is fine, but there is a danger lurking around the corner. What happens when the demo is highly successful and generates a lot of interest? Well, then development can begin in earnest. And hey, why bother spending all that time developing the product from scratch when we have a perfectly good demo build with a lot of the groundwork already done?
Let's just take the demo and build on it to create the final product.
Don't do this.
To illustrate why you shouldn't do this, I will tell a story from a past project. I'm being deliberately ambiguous to protect the identity of both the company and the product. This is based on an experience I had with a previous employer in the distant past, not my current one.
The company I was working at had a widely used platform with a suite of supporting mobile applications. This platform dealt with VERY sensitive information.
The company had recently produced a demo of a new mobile app. This app would connect to the existing platform, retrieve said sensitive data, and offer some unique functionality.
There was an established pattern across all applications using this platform, some records were marked as explicitly access restricted, even more so than other records. Access to the records was still possible as long as you were logged in, but you had to provide a reason for access for auditing purposes.
When the demo of this new app was built, that auditing feature wasn't included, which is fair enough. It wasn't a feature unique to the new app that was worth showcasing.
But here's the problem. That demo build ended up as the actual product. And it took quite a while for someone to realise that this security loophole existed, as long as you were using that particular app, you could freely access restricted records with ZERO auditing.
To be fair, this issue highlights a security flaw in the platform itself, given that this was only possible because the audit trail was optional, which is questionable in and of itself. But that's not the point. It was an established pattern that all the other apps used, and it was overlooked in favour of getting the app to market more quickly.
This ended up not being a serious issue in this case. The app in question never really made it past beta because there wasn't really as much interest as the sales people would have us believe. But let this serve as a cautionary tale. Don't try to evolve your demo builds into live products or services. It was almost a security incident for that team, and it could end up being something worse for you.
These demos should be considered "throwaway". That means you throw them away when you're done. You almost certainly didn't apply the same quality assurance to it as you would to an actual product, so don't try to pretend they are production ready.
You might just end up as a newspaper headline.