Skip to main content

What have I learned when releasing Qjub

About two weeks ago, I have finally released Qjub in private beta. It was a great feeling to finally kick it off the door. And a big relief as well. However, getting to that moment was not an easy task. This week I had a little time to reflect on that journey. And I would like to share my experience and the lessons I learned with you.

For those who do not have time or do not want to read the entire article:

  1. Steady small progress > occasional big chunks of work - it keeps momentum and eventually may give you more time.
  2. Set fixed deadlines and stick with them as much as you can.
  3. Cut unnecessary things and do not be afraid to release unpolished features or apps.
  4. Releasing is hard - you had to check and prepare so many little things which are often important, that it will take you a huge chunk of your time. Take it into account when planning the initial launch of your project.

Let’s start with a little background. When I start my current job I had to learn a lot of new stuff and I wanted to get better. So I start building Qjub. To learn in-depth all the new stuff I used in my work and to build something to help myself.

You see, I tend to collect a lot of resources across the web. Web development tips, books I want to read, cooking recipes, and design inspiration. But I had always had those things at different locations. Finding that one thing I was looking for was difficult. None of the products I tried worked for me, so I decided to build my own solution. Building Qjub was like to kill to birds with one stone.

Consistent work on stuff that matters

Permalink to “Consistent work on stuff that matters”

While Qjub was slowly taking shape, it was still mainly a learning project without any pressure to release it. Somewhere along the way, I decided to go all-in and make Qjub available to everyone as an app. With the eventual prospect of getting some income from it (and ideally building it full time).

At that time I had like a million features I wanted to be there, some more reasonable than the others. But still too much to ever get close to release. I start by splitting the development into several milestones and assigning then a reasonable amount of tasks. Of course, I had to prioritize and make some sort of minimum viable product (aka MVP) to be able to release.

I also mostly work on Qjub during free weekends. But because of children and other activities, those times were rare (sometimes I did not touch code for several months). Inspired by some podcasts and books I was reading I decide to make a change. I have started to work on Qjub each morning before I go to work for 1 hour every day. It may seem like very little time but it gave me an incredible boost in productivity and Qjub started to move forward like never before. I can confirm what many other awesome people say - working in small chunks regularly adds up, builds momentum, and eventually allow you to build much more.

I decide to work on Qjub each morning before I go to work for 1 hour. It may seem like very little time but it gave me an incredible boost in productivity and Qjub started to move forward like never before.

A few months later Qjub was looking good but I still couldn’t see the end of it. I sit down and think really hard about the Qjub. What do I want it to do? What is needed for release and what can wait? This has lead to two thinks. First I drastically cut down the scope of the project for initial release. Second I set a fixed release date.

Because of the fixed date, I had to keep asking what is important and what is not. I cut the scope a few more times during the remaining time to meet the deadline. This forced me to make some hard decisions and compromises. For example, I decided to postpone search functionality and board sharing. Or keep some stuff unpolished, intentionally limiting its scope and capabilities (eg. you can’t insert images to text notes at the moment). I can always make those things later if needed.

There is always some feature you can cut down or limit its scope to meet the deadline and focus on stuff that matters.

Let’s take a closer look at the search feature and my reasoning behind not implementing it at the beginning. My reasoning behind it was that no one will need search functionality at the beginning because there will most likely be very little content. So I can build a search later before anyone needs it.

This is the approach I try to use for everything in Qjub since then. Do I need this feature now? How much value does it give me? How much effort does it cost me? Building the Qjub myself, I have to think hard about my time and how to use it efficiently.

Finally, my release day approach, and I found out I’m still not ready for release. Yeah, I missed my fixed deadline, even when I tried my best and have huge support from my wife, who took care of our home and children herself so I could focus on Qjub. That was disappointing for me. But I pushed hard and finally make release two weeks later. Turns our releasing an app is more difficult than building it (at least for me). There are tons of small things to check that you can easily spend another week with just that.

So when you decide to release your next big thing, take into account that the release takes some time as well.

The release of the Qjub is just a start. I plan to work on it to better suit my needs and keep my information organized and easily reachable. I have already thought about my next steps and release the public roadmap. I also plan to write more about my journey on this blog.

So stay tuned and if you found Qjub interesting give it a shot. Go to Qjub homepage and request access to the private beta. I will appreciate any feedback and suggestions.

Tomas Pustelnik

Front-end developer with focus on semantic HTML, CSS, performance and accessibility. Fan of great and clever design, tooling addict and neverending learner. Building Qjub in my free time and writing on this blog.