Great project! I'm also maintaining a fully in-browser data visualisation/analytics tool [1] and I often found it hard to convince people that their data isn't sent anywhere. It's funny I also say the exact same thing that they can inspect the Network tab. As a potential alternative to open-sourcing the codebase, maybe a desktop version of the same tool (i.e. an Electron app) could help address the privacy concerns if it explicitly states that it won't make network calls, although it's a perception problem rather than a technical one.
Yeah, you're right on that it's perception problem rather than tech. It's interesting because it's much less intuitive to inspect the code/network requests for a desktop app which on it's face seems less transparent than something on the web, but the kicker is that there is no URL that you're accessing it from so it feels safer.
I'm thinking now actually if I did a PWA? I think it has the psychological benefit of feeling of an offline desktop app (which it can function as), but is lightweight and less maintenance than an Electron app, while still having the benefit of automatically updating when I make improvements without needing to manually make updates.
Where I'm struggling on the open-source question is that in the PDF use case most of them are not developers and don't know what open source is let alone host it lol. And most businesses can probably afford to pay a nominal fee to host it themselves and modify it if they wish, which many companies offer. It would be different if the product was something like a database or code package where it's always going to be a developer using it.
While open source might actually have more "freedom" for people to modify it for free initially, in a way it can be more honest for a developer with any commercial intentions to not open source something while offering paid ways to modify the source code, as we're seeing more and more that companies start out with a very open source product that they then revert once the community has helped develop it. Not that it needs to happen that way, but with commercial aspirations one needs to be careful as something becomes popular, it becomes too tempting to take back once open-source parts.
Forgive the wall of text here, I'm thinking out loud haha. Appreciate your comment!
I ended up making my app installable as a PWA based on this conversation myself. Changes were straightfoward to add on top of a Vite + React application: https://github.com/visprex/visprex/pull/62/files
Yes as dimava commented above a PWA would be a great alternative.
> in a way it can be more honest for a developer with any commercial intentions to not open source something while offering paid ways to modify the source code
I appreciate that you made your commercial intentions clear in the comments and I agree that you don't want to walk back your license as it definitely leads to backlash. I think developers (i.e. people on HN) tend to trust open-core models more where there's a clear separation between the core open-source components and a paid offering but I guess you don't have to overindex on those given the general audience of this tool.
I don't know what your ultimate monetization goal is, but in my opinion one realistic path is an one-time only payment of some reasonable amount with the full feature as opposed to subscription (I saw your Stripe link in the source).
This is a great idea. I was actually just suggesting PWA with opt-in updates in another comment I was just replying to, so it's affirming to hear someone else suggest it as well. Love the changelog piece.
Now the question is if people would be willing to pay. Perhaps it could be a nominal one-time payment to get the PWA and updates for up to a limited amount of time, or monthly amount to get updates indefinitely.
And maybe the URL accessed web version stays free with the core features, and PWA has benefits of both offline and some extra features.
Would you be willing to pay for something like this?
Another alternative proposition to test data (non)upload is to ask your user to load the app, shut their device connection off and then use the app. The more cautious one will close the tab before switching the connection on.
Very interesting read, I wish more startups did postmortems like this. It seems like the authors managed to build a set of tools that provided real value that ultimately did not make commercial sense, but would've been interesting to see if this learning:
> Scout was our most-used product. Its users weren’t our target market, but some were. We had vague ambitions to use it as an inbound marketing tool, but we never capitalised on it. This was a missed opportunity.
was applicable in a conservative industry like real estate and government as lots of open-core companies operate on this model (e.g. free open-source software and marked-up hosted solutions).
> That year, I lost about thirty pounds due not having enough money for food. It was in this context that the lab’s principal investigator told me that his funding for my position was running out. Desperate for work, I applied for a job as a web producer and decided to learn to code. My thinking was that it was a stepping stone towards any sort of scientific career, and it would be possible without more formal education or debt. In hindsight, this was the right move, but at the time, it felt like the only move.
This reminded me of the summer when I accidentally landed my first programming gig at my friend's startup as a part-time web developer during university. I was running out of money for food as my research assistant role was unpaid and I asked around for some odd jobs in the city. As a non-CS major, all I had was data analysis skills in Python but my friend thought I was was good enough to help him out with his SaaS startup, and I ended up learning a lot on software engineering principles on that job.
I will try to add more support for other data formats like xlsx and parquet in the future. Current CSV parsing is also a bit limited (i.e. cannot deal with timestamps) so I will try to update parsers first.
Thanks for commenting this, I would say speeding up the iteration between visualisation steps is the main benefit as you might not want to be thinking about matplotlib syntax when trying to get a sense of data distributions.
> had to rely on tools like Google Sheets or Colab + Pandas for quick cleaning and wrangling before exploring different visualizations.
Yes I had the same experience for analytics work some years ago. As others have pointed out, Visprex only works in a happy path where data is a clean CSV file so will definitely need to work on data cleaning. I have a DuckDB integration planned but not sure if this is easy enough for the target audience. Will try to add some predefinied functionalities, thanks for the feedback!
Yes I do have plans for data preprocessing using DuckDB WebAssembly (I have upcoming features secion in this blog: https://kengoa.github.io/software/2024/11/03/small-software....) but this will require SQL which some of the target audience might not be familiar with. I'm thinking of something like visual query builder from metabase.
> With the UI I want to be able to toggle between different strategies quickly - strip characters from a column to treat it as numeric, if less than 2% or 5% of values have a character, fill na with mean, interpret dates in different formats - drop if the date doesn't parse
Those are really good examples and I can make those predefined preproccesing techniques available as toggles in the dataset tab. Thanks for the feedback!
[1]: https://docs.visprex.com/