As much as I looked forward to starting my startup challenge, it had a difficult beginning.

Burnout was one of the reasons. It's one of those annoyances that persist on you for months. I was so eager to get working, but just couldn't. I was able to work about 1 out of 3 days during this period. It should ideally have been at least 5 out of 7.

But that was only one of several issues.

Other reasons for it not going smoothly were aspects of the project itself.

I have finally launched my first startup MainQuest, and it was about time. But I have decided to not market it too broadly just yet. Reasons follow below.

What is MainQuest?

MainQuest is a habit tracker and task manager that is directly tied to an actual fantasy role-playing game.

You earn gold by performing tasks, and maintaining habits. And you can buy adventure gear for this gold to advance in the game.

It's built with IHP and Elm (more details in last section of this article).

It officially launched in a free BETA version January 2nd 2020.

Beyond scope

MainQuest started as an ambitious side-project not intended for the 12 startups challenge. I started it in December 2020, and I wanted to make the productivity app tailored to my ideals.

It was to become a productivity app that makes a bridge between your life and an actual game.

I am very happy with the progress I have made with it, but it's not quite yet at the point I wanted it to be. There are several reasons for this.

A good productivity app itself is easy enough to make within a month. A game itself is often not, even a simple one. Combining these concepts compounds on the complexity.

Some unexpectedly hard aspects of making an RPG game was:

• Deciding on a good levelup system
• Deciding how much experience defeating an enemy gives
• Deciding pricing and stats on items so it aligns well with your personal progress
• Making some simple lore for the game, monsters etc
• Adjusting difficulty throughout the game

To sum it up: The scope was too wide, and I had come too far to narrow it down, or so I told myself.

Not yet good enough

I know that you should ship early and at "just barely good enough".

The trouble with this type of project is that "good enough" is not as easy as for example comparing when using a ticket vendor app. If people can buy tickets through the app somehow, it's good enough for launch. This is not as simple to achieve with MainQuest because a main part of the product is a subjective experience.

In addition to the complexity, it was the user experience itself of the app. If the user experience of an app like this isn't good, users won't come back later to check if it improved.

As I have come to the point where I had to launch the project, I am sadly still at the point where I don't think the app is quite good enough yet. I don't think customers will stick if they don't get to discuss with me directly. I simply haven't learned enough.

There is one thing I want to have in place before I launch it globally on Reddit and big message boards: A good module for collecting user feedback and interacting with the user.

Either I will make one myself, or use an existing solution, I see now that I can't do without this.

Developed in a vacuum

The last paragraph leads me on to a very important point. It's a point already I knew when I started out this challenge, but now I can really feel the pain: Don't develop in a vacuum.

What I should have done about a week after launching the mainquest.app domain is actually launching it publicly with a landing page and start collecting user feedback, maybe even before developing any functionality. Right now, I don't know what people would actually love about this app or not care about.

And that's how I intend to think going forward. Actual user feedback from people that are interested in this product is the gold I am digging for.

Then we can help each other make the product of our dreams, and by that my dream job.

Summary of why I won't market broadly yet

I have become good at building, but at this point I have been lacking the skill and will to measure and learn.

So in summary, these are the reasons I will wait a couple of weeks before I make a big global splash on MainQuest:

• I won't get back users I lose by a bad user experience, and I think I will lose a lot of users if I market it too broadly now. They will try and never come back to it
• If the user can easily report a bad or good experience to me, I could possibly retain them and get good feedback, so I need a system for interacting, or else it will fail

I think experienced entrepreneurs might advice me to market aggressively anyway, but I feel that's it's not that big of a loss to wait a week or two.

Feedback mechanisms will be an interesting future topic.

Social media enthusiasm dwindled away

Another lesson I learned is: Don't announce your challenge too early on social media. The announcement generated nice attention and I got several nice PMs, but as life came in the way and the challenge became postponed by several months, I think many lost faith and interest.

I think I should have waited until I felt ready and refreshed, to avoid the pressure and use the momentum of the cool announcement.

This of course depends of who you are. I have only 500+ followers, so mileage may vary.

12 startups in 12 month - avoid these mistakes

Some take-aways so far in my startup journey:

• Don't start a year-long super challenge with a burnout. Fix the burnout first
• Don't start the challenge with an ambitious project. It will stress you out
• One of your most important problems to solve early is how to interact with users
• Announce the challenge when you are ready, not long before

Some technical details

For those who know me, it probably doesn't come as a surprise that the stack is built with as much statically typed functional programming as possible.

The codebase has gotten pretty big:

• 10 094 lines of Haskell as the app is built with the IHP framework
• 4 960 lines of Elm
• 1 634 lines of ReScript (for a React Native app companion that isn't listed yet)

I will try to comment more on the stack and functional in the future, but I can already say that there are very good reasons for me to be happy with it.

Having a sound type system makes me much less afraid of going into the code and doing improvements. That's good because you never do it right the first time anyway.

Having IHP, the network around it and not least the IHP creator Marc on my side for help and support is invaluable. There are certainly benefits to being an early adopter to a very promising framework.

With sound type systems, I don't worry about tearing up the fabric of the universe and then stitch it back together to improve the internal API. For me, that feels like a superpower.

I hope to see more functional programmers be a part of this startup and bootstrapping community. This is where we should be at, building future FP jobs and proving what we claim about functional programming is true 😀