This is the first annual review of Snipline. The shell command bookmarker app.
Snipline started as a tool to scratch my own itch. I wanted an app that streamlined saving, searching and using shell commands. Not long after the initial build I released it to the public as a Software as a Service.
Notable Product Updates
Since its release last February, there have been over 20 updates (including bugfix releases) and 8 feature releases. Notable new features include:
- Better markdown documentation.
- Multi-select parameters for quickly choosing between predefined choices.
- Random password parameter.
- Pinning snippets.
- Dark mode.
- Importing/exporting snippets.
- Advanced search syntax.
There’s also been two sister-apps that I’ve added to the ecosystem: Snipline CLI and Snipbar for MacOS. SniplineCLI is a command-line interface which syncs with your Snipline account, and Snipbar for MacOS is a native Mac menu-bar app which is smaller and faster than its Desktop counterpart.
Snipline CLI in all its terminal glory
So overall, it’s been a busy year for Snipline. It’s given me the opportunity to work with many languages, frameworks, and libraries which I probably wouldn’t have otherwise. Snipline has been a playground for me to experiment and hone skills which I normally would not be able to in my day job.
Getting the Pricing Right
The majority of developers that I’ve come across do not wish to pay $18/year for Snipline. This is a failing on my part to not understand an audience in which I consider myself to be part of. I have asked myself if this was someone else’s product would I pay $18/year for it? I’d like to think I would, but I think perhaps my bias is leaking. More importantly, I can see why others would not.
Focusing on the Wrong Things
I have focused on product updates, new features, complimentary apps, and onboarding. I believe all of these are important, but most important of all is marketing.
So far, I have mostly used Twitter and Dev.to blog posts for spreading Snipline. These blog posts have mostly been tutorials that have come about from technical problems I’ve solved while working on the apps (e.g. using Ember JS with Electron). While many people have found them useful, I do not think they’ve helped attract developers to the product.
It’s possible that for most developers I chose the wrong stack. I created a cloud based web-app because I personally needed to sync between multiple computers, including various Operating Systems and Apple IDs. Snipline solves this problem for me perfectly, but for many developers syncing to the cloud isn’t necessary, and they’d much rather have either a one-time cost with no syncing or iCloud syncing.
What I’ve Done Well
Throughout last year, I’ve worked hard on making onboarding as smooth as possible. Including detailed documentation, adding onboarding steps to the registration, and just recently added new emails with tips to keep trial accounts engaged.
One IndieHacker user kindly created an in depth video of Snipline. The fact that someone would take the time to make a video showing off Snipline felt incredibly rewarding. Perhaps unintentionally, he also gave me some fantastic insight into how an end-user learns to use Snipline. He brings up one of the onboarding emails in the video which lists example use-cases which is great to see that they’re working, but also shows me that I should tweak these examples with ones that concentrate on learning Snipline rather than showing off overly complicated shell commands.
One of the things many users mention is how nice the UI is. I’d love to take all the credit for this but I had help from some very talented designers. I think many developers including myself are used to dealing with clunky, non-intuitive UI in apps that we use. But since Snipline is a paid product, I don’t think a bare-bones UI will cut it if I want it to stand out from free alternatives.
As mentioned above, Snipline has been receiving regular updates throughout the past 12 months. These are usually small and incremental. I believe small changes add up over time and allow for gradual transitions. Large updates risk rocking the boat - the last thing I want to do is alienate the current user base by breaking their workflow.
What’s next for Snipline?
New Pricing Plans
Pricing is a delicate point for Snipline. It’s clear that many of the people that have tried Snipline do not get the value they wish out of the app compared to cheaper alternatives. At the same time, I do not want to make Snipline free because continued development and support needs to be sustainable. I also do not wish to inject ads or tracking as an alternative.
With this in mind, I really like Source Hut’s “Pay what you can” structure. So, as of today, Snipline is adding 2 new plans: $9 Lite and $27 Pro.
I encourage users to subscribe to the plan that works with their financial situation and the value that they get out of Snipline. I still recommend then $18 plan, however, this is now only a suggestion as each plan gets the same benefits.
The next release of Snipline Desktop is right around the corner with a couple new features and bug fixes. These include:
- New “Snippet” page for viewing snippets and documentation.
- Better offline support.
- Fix for initial lag in the search bar.
- Fix searching for tags and aliases.
One of the key features I’d like to get added to Snipline is client-side encryption. This is not a small task for a few reasons: I have to consider how to transition currently stored snippets, how to make users aware of this feature - its benefits and risks. I also have to integrate this with Snipline CLI and Snipbar.
In addition to this I’d really like to get an iOS and iPadOS app released this year, as well as upgrade Ember JS/Electron for the Desktop app to the latest versions.
Publishing an API for developers to leverage has also been on my mind. The API has been stable for a while now, but this may change with client-side encryption so I intend to get that released first.
That’s all for now, thanks for reading!