2019-01-05~21 min

An Indie Hacker's Story - Two Years of Developing a No-Fluff Dream Journal

In the past 2 years, I have learned a lot about how to optimize working on side-projects. This article is about that period in my life, what happened, what I learned from it, and how it lead up to today, the launch of DreamFort.

Learnings

Here's everything I learned, every epiphany I had during the last 2 years.

  • Lesson #1: Decide if you want to build a product or learn a new technology / build with the technologies you're comfortable in
  • Lesson #2: Evaluate if a platform fits your needs before developing for it
  • Lesson #3: Meaningful progress can be made in as little as a few minutes
  • Lesson #4: Focus on one thing, and be clear about what you want before implementing it
  • Lesson #5: Don't do design and development at the same time
  • Lesson #6: Don't shy away from tasks out of your comfort zone. Worst case scenario, you learn something. Best case scenario, it works.
  • Lesson #7: If you want a cofounder, find one who fits to you and the project
  • Lesson #8: Focus on delivering useful features for the user, the time to reap the benefits of perfect code will never come
  • Lesson #9: Do design in steps, first layout (in grayscale), then add colors.
  • Lesson #10: Take deliberate breaks from side-project development
  • Lesson #11: It's easier to change the environment than to increase your willpower.
  • Lesson #12: Avoid guilt by dedicating a specific amount of time to side-projects
  • Lesson #13: Write the copy before designing the website

Below, you find the complete story, what prompted each of these learnings and a bit more detail around them.

The Beginnings

It was March 2017. To learn lucid dreaming, I've been keeping a dream journal. Every day, immediately after waking up, I wrote down every little detail I could remember about my dream(s). Only after a few weeks, I was routinely able to remember 2 - 3 dreams per night.
It takes quite a long time to write them down. I often spent half an hour writing. Each morning.

That was too long, so I searched for a solution. I looked at every iPhone and web app I could find, but many of them had a focus I'm not interested in, the social aspect. All I wanted was a basic dream journal. No social media involved. Dreams are highly personal, I don't wanna broadcast them all over the internet.

I wanted something different, and knew I could build that vision.
A new side-project was born.

The First Version

Web apps work on every device, and therefore have the capability to reach most people.
So I started developing DreamFort for the web. And with developer blood running through my veins, combined it with learning a new framework, VueJs.

Everything above turned out to be a mistake.

Doing Way too much at the same Time

My estimate was that a first version will need about 1 month working on the evenings and weekends, next to my full-time job.

Shortly before that, I started learning piano and Krav Maga. I also wanted to write blogposts, do weight lifting, read books and articles that come up in my Twitter feed (~50 a week). My free time was always torn between those things.

I wanted to do everything at the same time. Exercising, reading, developing, but also relaxing and meeting friends.
Because of that, there was never a clear expectation what I want/should be doing, which led to way too much relaxing and too little productive time.
The result of that was me feeling guilty for doing one thing, because I didn't do the other.

I lacked focus.

I did everything I wanted to do, but not as long as I wished. Therefore, progress on DreamFort was extremely slow.
Even then I knew it had to be possible to do better, just didn't know how.

What I also did a lot during this period was trying to make the code perfect. Using the newest technologies, improving the architecture, and applying new things I learned about VueJs.
I had 2 goals with DreamFort, learning VueJs and developing a product. This splits focus, and leads to overengineering.

Lesson #1: Decide if you want to build a product or learn a new technology / build with the technologies you're comfortable in

The Web Version

After a few months the web version was finished, in the sense that it had all features and I poured all my design knowledge into it.

Old Web App Desktop

It looked horrible. So horrible, not even I wanted to use it. And it started out as a project for myself!
But what about the mobile version, maybe that looks better?

Old Web App Mobile

Not really.

The mobile version has an additional problem. The browser frame appears when you scroll up. It destroys the whole app. If it was always visible, it would be ok. But if it changes when scrolling, and the content is too big to fit on the whole screen, the experience suffers.

This is surely a secret plan of Apple to get more native apps! Just kidding. But it worked in my case.

Lesson #2: Evaluate if a platform fits your needs before developing for it

I had no experience with iOS development, but I should not have discounted it just because of that.

A Break in Between

In June 2017 I quit my job. The plan then was to stay unemployed for a few months, enjoy the time, and work on my side-projects.

This didn't exactly work out. In terms of side-projects, I could've made a lot more progress.

There was always something that gave me an excuse not to work on them. Meeting friends here, an event there, doing something with my family.

One cause was that back then, I had the opinion that it takes time to do something meaningful on a project. So if there weren't at least a few hours blocked, I wasn't going to do anything.

Now I know better. With proper organization it's possible to implement something valuable in a few minutes. And not just on small tasks. There can also be meaningful progress on bigger tasks in a few minutes. They don't have to be done in one go!

Lesson #3: Meaningful progress can be made in as little as a few minutes

Different Projects

In the beginning of my unemployment time, an idea for another side-project floated around in my head. One which I thought would be done in a few days, ismydependencysafe. The thinking was to quickly develop it, put it out on the internet, and continue with DreamFort.
It turned out differently.

I developed a first version and then it got interesting, technically. So I kept working on it.

From September on I did another project, but this time one that has actual real-life use. I've developed an application for my dad's company, and it needed a web version.
In the 2 months left (I was planning to get a job in November), it was finished. Somehow, with this application, I was a lot more focused, less inclined to work on cool but unnecessary features or make the codebase perfect, and much more focused on getting it done.

The million dollar question is why. Why was I so much more focused with this application than with all my side-projects?
It's more than just the fact that it had users. It has exactly one, my father.

I believe it was that way because it was perfectly clear what it should do.
With side-projects, this was never the case. Design, development, feature planning, and research were all entangled. Everything was done simultaneously. There was never a clear finish line.

Lesson #4: Focus on one thing, and be clear about what you want before implementing it

New Job and Cofounder

In November, I started working part-time, 3 days a week, at Bitmovin. The idea was to learn from other engineers and be on payroll while still having enough time to work on side-projects.

Shortly after an acquaintance approached me about founding something together. I showed him DreamFort, the web version I had already, as one of my existing projects, and he latched onto it. His vision was to make DreamFort huge. Everyone who wants to track their dreams should use it. Not being opposed to that, we started working together.

For it to be successful, the design had to be improved. We decided to make a native version to overcome the limitations of the web. The decision between iOS or Android was an easy one, as both of us had iPhones, we decided on iOS only at first.

With that decision I bought a design tool, set everything up, and then we met a few times to work on the design. Having 2 minds on the problem was great.

There was also another benefit. He's not a developer, which means I had to focus on the design aspects. There was no point in talking in developer speak.
This was a tipping point for me. During that period I learned the power of actually splitting the tasks. Focusing on design first, and doing development after.

Lesson #5: Don't do design and development at the same time

After some time the design was finished. We had 2 selling points in mind when doing that.

  1. Keep it simple and focused

    • All other dream journals we found were focused on sharing dreams. But we figured that most people will only want to record them, but never share them.
  2. A 2-step process for entering dreams

    • It can easily happen that writing down a dream takes 15 min or more. During that time, other dreams people had during that night can start to fade away.
    • The first of the 2 steps is adding metadata and keywords. With that, it'll be possible to remember dreams far longer, and add the complete story later (which is step 2).

After that we made the website, and tried to get users signed up for the mailing list. Unfortunately neither of us knew how to do marketing, let alone get people to sign up for the newsletter. We were uncomfortable doing that. We half-heartedly tried a few things, but the outcome was 0.

Lesson #6: Don't shy away from tasks out of your comfort zone. Worst case scenario, you learn something. Best case scenario, it works.

At some point we thought that a newsletter signup only works for products that are either completely new, where there is a need and no competition, or when there are solutions already, but they don't work properly. Both wasn't the case with DreamFort.

In our minds, this left us with implementing it and trying to get users afterwards. Which is what I did in the end. But we actually wanted to test if it can be successful, just didn't know how.

During that period, Lukas also worked with another company. A company where his skillset was properly used, and he doesn't have to learn it from scratch, which would've been the case with marketing for DreamFort.
Shortly after, Lukas decided to not continue with DreamFort so he can fully focus on the other company.

It didn't come as a surprise to me, the signs were all there, and I was never mad at him. The decision was the best he could do in this situation.
The other company is more mature, innovative and serious. They have incredible technology. And Lukas was just finishing his studies and eager to use his existing skillset to drive a company forward.
DreamFort could've been only part-time, and he'd have to learn a new skill to add value to the project. It was a bad fit from the beginning.

Lesson #7: If you want a cofounder, find one who fits to you and the project

So I was back alone, but I had one thing I didn't have before. A design.
With that I started doing what I know, developing the app.

During that time, my focus improved, but I still didn't get as much done as I should have in 2 days per week. It often happened that I met with friends, and told myself that I'll shift the work to the weekend. Sometimes it worked, sometimes I just lied to myself.

App Development

As I never developed a mobile app before, I didn't know the best practices, which frameworks and libraries to use, or which coding patterns make the most sense. So I spent some time preparing, reading articles mostly, but didn't read a whole book about it. I wanted to make progress after all.

I just started, learning while doing. And it worked out nicely. Even though I probably made some decisions a seasoned iOS developer would strongly reject, I made steady progress. My fear (and I guess that of many developers) that having imperfect code will slow development to crippling speeds never manifested.

Lesson #8: Focus on delivering useful features for the user, the time to reap the benefits of perfect code will never come

Finished App, Hesitant to Publish

In May 2018 the first version was done.

At this point I wasn't sure if I should actually publish it. Mostly because of the costs for the developer account combined with the uncertainty of success.
In the end I thought "fuck it, I spent so much time building it, I have to see where it goes".

I created a developer account and submitted the app. The first 2 tries were rejected.
But then, finally, the 3rd one was approved! 🎉

Another Project, another Distraction

Now that the app was finished, it was time to get users. Again, completely out of my comfort zone. The first and easiest thing to do was to post it on Reddit. I'm a perfectionist, so I wanted to find the best time doing that. Which led me to another side-project, RedditUsageStatistics.

It queries the subreddits every 1/2h to find out how many posts were submitted since the last query and how many people are online right now. Based on the simple division of eyeballs / posts, it calculates how much attention a new post would get, on average.

The project was incredibly fun to work on, and I learned another design lesson with it.

Lesson #9: Do design in steps, first layout (in grayscale), then add colors.

For me, as a non-designer, this makes designing a lot easier, since some difficult decisions are deferred until later.

With that, the design of RedditUsageStatistics was the first design I made entirely on my own I actually liked. This really was a happy (and proud) moment.

Now that I knew when the supposedly ideal time to post was, I posted it on Reddit. (Post)
It was quite well received, which really lifted up my spirits. I got my first users.
If you're one of them, thanks for using DreamFort from the very beginning! Your support was incredibly important :)

Going Full-Time

At the end of June I made the decision to become full-time at Bitmovin. They gave me the opportunity to become lead developer. I wasn't going to let a chance like that pass.
For that I decided to move to Vienna, so that my commute would take less time. We agreed to start my full-time employment after I moved, in October.

In July I started searching for a flat, which was stressful enough. I didn't expect it to be that much work.
Additionally, during that period, we had a critical project at Bitmovin I was the main developer on. So to be able to focus on that, and not be worried about my side-projects, I halted all development on them.

This turned out to be a great decision. That time was stressful, but when I went home, the stress was gone.

Lesson #10: Take deliberate breaks from side-project development

"deliberate" is the important word here. They must be guilt-free.
This break liberated me and gave me a much-needed time out.

Change in Side-Project Organization

During the time out I remembered that a friend is always just working on his side-projects, he doesn't need to plan when he does what. He just works when there's time.

I started asking myself why I can't work like that. The main reason I found was my organization of todos for the project. They were at the same place as the general notes, in OneNote. I realized is that OneNote doesn't work for todos, since they don't vanish once they're done.

There were 2 points that I didn't like about my notes/todos organization:

  1. The notes organization for projects quickly becomes messy
  2. The daily/weekly/monthly todos made me feel guilty when I couldn't achieve them (which was usually the case)

I solved both by moving the todos to GitLab as issues, and simultaneously gained a good overview of what I could do next, separately for each project. That allowed me to improve how I work on side-projects.

  • Just work when there's time and not have planned todos
  • Focus on one project at a time

Just working when there is time means I could finally treat side-projects as what they are. Side-projects.

For me this means working on them a specific time, on the most important issues, and then continue with my life. I don't need (or want) to put in 40h a week on them.

The freedom I got from that change is unbelievable. I'm no longer held hostage by my side-projects. And let me tell you, it feels great!

The Perfect Schedule

After fixing the organization of todos for side-projects, I had to make enough time for them.

Around this time I remembered that sometimes, when still working at my previous job, I did some development before going to work, and I always got a lot done. When I realized that, I knew I found the missing piece.

Working on side-projects before going to my day job.

I never properly thought of that before. The employer deserves full concentration on the job, and I thought that working beforehand would decrease that, since you get tired quicker. But this is actually not the case, since you're anyway awake much longer than you work.

The actual change was quite small. Instead of having a lot of unallocated time in the evening, I moved 2h to the morning and dedicated it to working on personal projects.

My perfect schedule:
6am - 8am: working on side-projects
8am - ~7pm: working at Bitmovin
~7pm - 11pm: free time
11pm: going to sleep
Monday, Thursday, Friday: afternoon (~3-5pm): weight training

There I have to say that this is only possible because Bitmovin is an amazing employer. They don't mind me interrupting my workday with training sessions. They don't care how employees schedule their day, as long as the work gets done.
Not sure about other parts in the world, but this degree of flexibility is uncommon for Austria, and really makes Bitmovin stand out.

I now make dedicated time in the morning for working on my projects. I wake up 2h earlier, use those 2h, and then go to work. Thinking of it as fixed keeps me focused and avoids guilt for not doing more.
There is one exception. If I can't go to sleep early enough, because I'm out with friends for example, I'll wake up later and cut my side-project time. A full nights sleep is important to me.

Lesson #12: Avoid guilt by dedicating a specific amount of time to side-projects

So actually the one fixed thing is that I get to the office anywhere from 8am to 9am and am capable of doing a day of focused work.

Another advantage of that schedule is that, since I already did everything non-work related I want to do (side-projects and training), I can finish work-related tasks in the evening without worrying about the things I still need/want to so. So if there's something that needs to be done, I can finish it without getting anxious.

And best of all, I fully enjoy the evenings off. When I walk out of the office, the day is done. Nothing more to do. I can fully relax and enjoy my free time.

Sprint to Launch

DreamFort has been in the App Store since May. Because of that I always thought it's too late for a big launch. But during Christmas time I decided to do just that.

Spirit Leading up to the Launch

This is my first real product launch, and quite frankly, I'm a bit scared. I have no idea what to expect, and how I'll react to it. I know it will probably fail, since it started out as a project for myself, and I never properly validated if there's a need for a dream journal app. But knowing that you could fail, and actually failing are entirely different.

But... I made a decision: It will not fail because of lack of preparation.

So I'm improving every aspect of DreamFort. The website and the app. Not adding new features, but polishing the ones that exist and squashing bugs.

Website

With improved design skills, I first updated the website, dreamfort.app. And this time I did it right, writing the copy first, and only afterwards thinking about how it should look like.

This made copywriting easier and better. Instead of filling empty spaces on a predefined layout, I could let my mind run freely about the text I want to write. After the text was done, I

  1. did a broad layout
  2. implemented it in grayscale (following the learning #9)
  3. defined a new color scheme (with the advice from Refactoring UI)
  4. applied that scheme to the website

I think the improvement is staggering, how about you?

Old New
website old website new

Lesson #13: Write the copy before designing the website

App

After the website was done, I started improving the app. The goal was to give the user the best experience possible.

First and foremost, this meant reworking the profile view. I was never happy with it's design. A complete redesign was due. It took some time of looking at other designs, graphs, and finding inspiration, but in the end, the result was worth it.

Old New
profile view old profile view new vertical

Reworking the profile view wasn't the only thing that improved. Update 1.3.0 was the biggest one in the history of DreamFort, and includes

  • the reworked profile page
  • dream search by scrolling up in the all dreams view
  • improved date selection
  • animations to make the app feel snappier
  • tiny vibrations when interacting with it
  • more beautiful empty states
  • and a range of minor improvements

A Damper Shortly Before the Finish Line

After being almost done with the update, I saw 2 reviews in the app store saying the same thing. These 2 people lost their dreams because there was a bug in the app. Because I made a mistake.

App Store Reviews

This made me feel awful. They took the time to write down their dreams, into my app, and now lost them because of me.

On the other side, the reviews were quite positive.

Was amazing, keeps crashing now, update?

And both rated with 3 stars, even though they lost their dreams.
This was strangely motivating. So I did everything I could to find the error.

But I couldn't. For the life of me, I have no idea where it comes from. Tested everything I could, to no avail. It seems that those errors only happen on some devices, but I have only one, my iPhone 7, I'm not a company with hundreds of testing devices.

Still, I don't want to leave those users hanging.
Originally I planned to release version 1.3.0 the same day as the launch, with this blogpost. Because of those reviews, I decided against it. What if these errors are also in the new version?
So I released it immediately, to see if there are any crashes happening, and have the time to fix them before doing the launch.

And sure enough, there were crashes. Therefore, shortly after version 1.3.0, I released version 1.3.1.

While preparing for the launch, I found other bugs and stability issues and fixed them as much as I can.

The Launch

That's where we are today. Version 1.3.6 is released, DreamFort should be stable, the new website is public, and this blogpost is released.

DreamFort is also on Product Hunt.

Now it's out of my hands. I did my best to prepare, the rest is determined by you and the rest of the internet.

Check it out to see how it's doing. I'll certainly be doing that every 5 minutes 😄

Summary

DreamFort is my longest-running side-project, almost 2 years now. There were a lot of ups and downs, breaks in between and phases of intense development. I often asked myself if I should continue with it, or focus on something else.

Now I'm doing a proper launch, and this launch will decide if I'll continue with it or not. Mentally I'm prepared for a failure, it would still suck though.

Regardless of the outcome, I learned a lot, so I don't regret the journey. This article mostly focused on the psychological side of it, but I also vastly improved my design, copywriting and development skills.

If I had to choose one thing that I was missing, I'd say focus. I wanted everything now, so I worked on everything, always. Doesn't take a genius to figure out that this can't work. Took me long enough though. This is basically the story of how I found my focus, and most lessons support that one goal.

Here are all of them repeated:

  • Lesson #1: Decide if you want to build a product or learn a new technology / build with the technologies you're comfortable in
  • Lesson #2: Evaluate if a platform fits your needs before developing for it
  • Lesson #3: Meaningful progress can be made in as little as a few minutes
  • Lesson #4: Focus on one thing, and be clear about what you want before implementing it
  • Lesson #5: Don't do design and development at the same time
  • Lesson #6: Don't shy away from tasks out of your comfort zone. Worst case scenario, you learn something. Best case scenario, it works.
  • Lesson #7: If you want a cofounder, find one who fits to you and the project
  • Lesson #8: Focus on delivering useful features for the user, the time to reap the benefits of perfect code will never come
  • Lesson #9: Do design in steps, first layout (in grayscale), then add colors.
  • Lesson #10: Take deliberate breaks from side-project development
  • Lesson #11: It's easier to change the environment than to increase your willpower.
  • Lesson #12: Avoid guilt by dedicating a specific amount of time to side-projects
  • Lesson #13: Write the copy before designing the website