Why we built Private Journal
Back in 2012 me and two other friends started a web dev co-op. Basically, we wanted to work on cool stuff and get paid for it. It started out fine enough, we got some clients, built mobile and web apps and got paid very little.
So we decided that in order to use this “company” as a profitable business we need to build our own products. We were excited. And like most stories that start this way we began designing our first product. After 6 months, we were still designing it. It got really bloated and we eventually put it on hold.
As web devs we follow the major trends in this space, and one trend in 2013/14 was the hackathon, and we decided to give it a go. We build an MVP in one day and launched it to our network. We got a lot of feedback and started to list the new features we need to add to the product. Somewhere along our product meetings this also started to morph into a bigger and bigger thing. And again our motivation dropped and the project was put on hold.
Fast-forward a year and we found out about Justin Jackson’s podcast Build&Launch where he argues that the best way to build something is to build it and build it quick in order to actually launch it. In the podcast, he tries to build and launch a product every 7 days. This really resonated with us and we decided that we would try to do the same.
Working with the constraint of a week of development is not easy. Especially when we can only work on this part-time (we now have a company —Bytencode — , but client work that pays the bills comes first). It proved to be what we needed to actually launch something. But I’m getting ahead of the story.
Now we had a timeframe and we need to figure out a product that could fit into it. We brainstormed and came up with a few ideas. We ended up choosing a SaaS app called Private Journal and we would monetize it using, as normal for a SaaS product, a subscription-based model of $ 10 / month.
The idea for Private Journal came from our own need for a secure and private way to register our thoughts. We’ve been learning a lot on the web from people like Tim Ferriss or Leo Babauta about the benefits of keeping a journal, but using a paper one would mean that it would be vulnerable to being read by someone, and using the existing digital tools would mean the same but on a different level.
These where the features we decided upon:
- all the contents on our database should be encrypted in a way that even we could not look at it if we wanted to.
- nothing should be stored on the browser, no cookies, no cache.
- we should detect inactivity in order to log off our users so that no inadvertent reading might happen.
The biggest challenge came from the encryption component. It’s not easy to encrypt something and decrypt it without knowing the secret. We did it by using a secret to encrypt the contents, but instead of storing the secret we encrypt it using the client’s password and store that. So at any given time our database has the content encrypted with a secret, and that secret encrypted with the user’s password, and we don’t store the password but a hash of it. So in order to decrypt the content the user must submit the password, and he does so during his login. This is still not the full story because we built this behind a stateless API, and for that reason we had to get a bit more creative with all this process, but this is the jist of it.
And so we started building it, and we made it. We took a week to build and launch a product. Regardless of how it turns out commercially we are super happy with the results. Keep in mind that we took 2+ years to build and launch something that was built in a week.
This was the first version of Private Journal.
We launched it to our network only via social networks like Facebook and Twitter. And in our first day we saw 100+ sessions from 5 different countries. For such a soft launch, it was great.
But what about what actually matters - user registration? In that we failed, only 4 users registered. And that number was the same for the rest of the week.
We believe the main reason for this such low adherence has two components. The first is that our network is not the target customer for our service, but most importantly we realized that our price point was too high. We tried to have our first product solve all our financial problems, and that was a bad play. But we learned, from that and from the other feedback we received and we improved the product (again only fixing what needed to be fixed not adding any new features), and created our version 1.1 of the product, and here it is.
We are now offering the product as a free service and are considering monetization strategies such as advertising or affiliate sales. But for now it’s just free and not even ads exist on it.
So this is our journey so far, we didn’t travel long, but we are still happy about getting out of the “searching for perfection” cycle and just building stuff.
And we will build more of these one-week projects.
Hope you enjoy our story.
