Headlesstic - a headless CMS on top of Elasticsearch - #1 what do you think?

For a recent e-commerce project, I imported products and categories into Elasticsearch, to utilize the fantastic search capabilities that Elasticsearch provides. For those that don't know: Elasticsearch is kind of a NoSQL database, but it has grown into much more than that. The elastic stack offers storage, analysis and search for all your data. As someone described it in a promo-video: running Elasticsearch is a bit like running your own Google.

For the mentioned project, I ended up making a headless CMS on top of Elasticsearch that consists of two "layers". A backend layer that was built in Go and a frontend layer that was built with Vue.js. The backend layer serves as a layer between the frontend and Elastic, and is used to authorize requests, keep track of collection meta-data and deal with media like images and videos. The frontend can be used to define collections. For now this is done in JSON format, but a WYSIWYG editor to visually create collections is planned. After collections are defined, items can be added, sorted, filtered and translated, with the Vue.js frontend.

Your opinion will decide the future of this project

Since I made a good start with the project, I feel like sharing it or even turning it into (open source) SaaS. Before I dive in, optimize the code, add some features and publish the project, I'd like to ask your opinion. Would you find a tool like this helpful at all? What should a headless CMS on top of Elasticsearch be capable of, for you to use it? Do you think this could have a future as SaaS, even if the project will be open source?

Features

• An independent layer on top of Elasticsearch. You can still use the native Elasticsearch API and tools like Kibana and Beats.

• Define collections and what fields their items should consist of. E.g. a product that consists of a name, sku, price and image.
  

• Provide an api for public, semi-public and admin collections, while keeping the native elasticsearch query format.

• Items can have relations to items from another collection. E.g. a product can contain one or multiple categories/tags and vice-versa.

• Define which items should be public/active and which fields should be public. E.g. a product can be public, but the supplier field can be private.

• Support for Cloudinary built in. Keep track of images' meta data, while hosting them wherever you want.

• Support for FusionAuth built in. Authorize with a JWT token from an identity provider.

• Planned: automatically resolve relations for public, semi-public and admin api

• Planned: WYSIWYG editor for collections

Thank you

for replying. Your opinion is greatly appreciated!