Thanks for your comments and suggestions. Your observations actually confirm that it is not the best idea to do everything yourself. In fact, I pivoted three times during the last several years:
1. Windows (WPF) application targeting approximately the same users as Excel, PowerBI, Tableau, Qlikview but providing self-service data wrangling functionatliy (rather than visual analytics). Problem: after finishing 90% of work I understood that I have to do the next 90% - UI development ate all my time.
2. Java framework for complex analytical data transformations targeted as the same users and tasks as, for example, Apache Spark, but providing higher performance at run time and development time (in-memory column-oriented approach). Problem: again, difficulty to attract attention which is necessary to get critical mass of users. Probably the market of classical big data technologies is too tough nowdays.
3. StreamCommandr. Same as previous but focused on in-stream analytics (instead of batch analytics) and IoT. This market seems to be empty (very rare event) and I want to provde the technology as a cloud service (PaaS), say, in IBM Bluemix, GE Predix or AWS. The users of the in-stream analytics service are supposed to be solution/application developers who want to analyze their data (e.g., from devices) in real time. So I am working on this third hypothesis by taking into account my previous mistakes and collected experience. In particular, I am going to maximally simplify everthing even if I sacrify significant pieces of functionality. Time is more important than quality.
1. Windows (WPF) application targeting approximately the same users as Excel, PowerBI, Tableau, Qlikview but providing self-service data wrangling functionatliy (rather than visual analytics). Problem: after finishing 90% of work I understood that I have to do the next 90% - UI development ate all my time.
2. Java framework for complex analytical data transformations targeted as the same users and tasks as, for example, Apache Spark, but providing higher performance at run time and development time (in-memory column-oriented approach). Problem: again, difficulty to attract attention which is necessary to get critical mass of users. Probably the market of classical big data technologies is too tough nowdays.
3. StreamCommandr. Same as previous but focused on in-stream analytics (instead of batch analytics) and IoT. This market seems to be empty (very rare event) and I want to provde the technology as a cloud service (PaaS), say, in IBM Bluemix, GE Predix or AWS. The users of the in-stream analytics service are supposed to be solution/application developers who want to analyze their data (e.g., from devices) in real time. So I am working on this third hypothesis by taking into account my previous mistakes and collected experience. In particular, I am going to maximally simplify everthing even if I sacrify significant pieces of functionality. Time is more important than quality.