9
10 Comments

Mistakes that I made working on a side project even when I had a dream team

Our wild idea of a side project started in 2015 when a friend and I got talking about a building a product. It probably wouldn’t be a huge company, but it was a good side project that could be done with a few friends. Running this side project would bring in a little extra cash, but that’s what got me excited. Our project would be generating revenue from day one, the only problem was getting to day one.
To start, we needed a name for our app. To keep it under wraps before it came out, we called it the Market App.

In short, our idea was to take incentive marketing campaigns from companies and run their ads on our platform. Users on our app would see products from other companies, which would be designed to be incentivized. The simple incentive-marketing concept would bring more users to try the ads.

As we came up with more of the design, we began working on Market App. I spent time building products and designing them, while my friend put his efforts towards the business and economics end of this start up. Our skillsets is what made us a dynamic team, but we still needed a few more specialists.

Fast forward 6 months, we had our user interface designed and we were ready to start working on the backend. Luckily, a mutual friend had the skills and was willing to come aboard and create it. Since this was a side project, we had all agreed to only put in our spare time, and that nobody would be paid. This eventually came back to haunt us.

After a few months working with our mutual friend, we all realized it wasn’t going to work. He was caught up in changing jobs and didn’t have the time to devote to the project, so we parted ways and began looking for a new developer. We found a one who was able to start right away, and even got a developer to work on our Android version.

A year flew by and all of us realized this undertaking was much bigger than any of us had anticipated. Nonetheless, were continued working on Market App. Unfortunately, all of us were just working part-time on this, making it difficult to finish things quickly. Something that would have taken a week if we were working it full time instead took two months, or longer.

Not only was it difficult to get things done in our spare time, it was even harder to do it separately. Work was always done better and faster when we met together as a group, but conflicting schedules still gets in the way of that. Everyone had their own commitments, I was working full-time as a freelancer, and one from the group quit his job to create his own start up, which took up all of his time.

Still, we were lucky to have the resources that we had available to us. Among the four of us, we had our backend man taking full responsibility for our system, our Android developer delivering a sleek app, my friend working towards our business development and marketing, and myself covering the product and the design.
While everyone had their responsibilities, having everyone working all at once on the app made it a little difficult to make decisions. A lot of time was consumed just communicating and deciding what should or shouldn’t be done.

Fast forward again and suddenly it’s August 2018. We’re still testing Market App, and hoping to launch it soon. Looking back and remembering how I was hoping to launch in late 2017 is laughable, but then, a lot of what we were doing had changed.

While the scope of what we’re doing had grown bigger and bigger, I still think we spent too much time building our app. Moral among us is at an all time low. No doubt some want to quit, but it seems absurd to quit now, since we’re so close! Having put in three years of work makes it seem worth it, but we have also been ‘close’ to launching for 10 months. Commitments continue to change, as do our daily lives. Luckily, there hasn’t been any money sunk into this project, but the time commitment has been far too large.

I learned so many things from building a project during my free time. I would change a few things if I was able to go back and do it again, but mostly I’ve learned:
• Doing things part-time is difficult to the point that it becomes painful
• It is not easy to put in hours when you already have a serious day job
• If you decide to work on something part-time, take out specific time to work on it. Go to a coffee shop to meet up and dedicate time to your project
• Things take 4x the time it would otherwise take
• Too many decision makers leads to stagnation. Give people responsibility and trust their judgment
• When you have no money to lose, it is not easy to realize the cost of time invested, which could’ve been used otherwise.
• Like any other project, you will always underestimate the scope and timelines.
• In working with more than 2 - 3 people, you must have someone responsible for communicating and holding the team together.

TLDR: I have been working on a side-project for 3 years now and we still haven’t launched yet. We are a team of 4 comprising Business Developer, Product Designer, Backend, and Android developer.

  1. 7

    Quite a lot of red flags in your text

    While the scope of what we’re doing had grown bigger and bigger

    This is something that you get wrong the first time you start to do something: you're not that good in cutting down features. Best startups know how to efficiently cut off all non-essential. That's why we talk so much about MVPs now. Although there's a lot that you think needs to be done, try to think the absolute minimum product and then cut a few features more. You can read the book "Lean Startup" for more inspiration.

    it seems absurd to quit now, since we’re so close!

    That's called the sunk cost fallacy. The more you spend resources (not just money, but your time too), the harder it is to abandon it. Try to acknowledge this and look at your progress realistically. The business is not worth a burn-out.

    we have also been ‘close’ to launching for 10 month

    The "last 10%" can take up a significant amount of time to complete. That's why people aim to launch when they have about 80% done.

    Another thing to keep in mind is that when you're trying to rush to a finish line, developers can make some shortcuts on code to release earlier. It would be good to have a realistic look at your codebase and see how much technical debt you already have, before you even have launched.

    Edit: Not trying to discourage you, I just urge you to be realistic. I bet you have all learned a lot in the three years, so even if you quit now, you get to keep all that knowledge and to be smarter on your next side projects!

    1. 3

      Stole the words right out of my mouth!

      I'd also add that nowhere in this post or the comments am I reading specifically about validating the idea with users. I assume as a product designer you're doing this, but if not it's essential and can often stop the feature creep or (even the whole project) before it gets out of hand.

      For what's its worth, I've been there too, albeit for 14 months not 3 years (then I pulled the plug), but the struggle of working on side projects alongside the daily grind is oh so real, as is getting sucked in by the sunk cost fallacy!

      1. 1

        Right. In our v1, we were simply copying existing apps that have millions of downloads and they were working well. So the thought was to copy the existing products, and build from there.

        I'm happy you spent 14 months and not years like me.

        If you want to share, how did you go about pulling the plug? Were other people involved in the project continued working on it? Did you take your equity/share when you left?

        1. 2

          There were 2 others involved and ultimately I just had to spell it out for them that we were never meeting our deadlines and that it had been so long that the market for our product had even changed.

          Actually that was slightly out of our hands - it was helpdesk software, a sector that had stagnated for years, but in the time we were working almost all the big players rolled out huge updates that had the same features we recognised they were missing. So it was like our competitive advantage was now non-existant and weren't at a stable build and clearly weren't going to get their in another 6-12 months. I appreciate there's room for many players in any given SaaS niche, but it just didn't look promising anymore (and I'm a optimistic guy).

          It's frankly too long to go into detail but we tried many ways to improve our productivity and team dynamic, I tend to view it like this: you might work 45-50 years in your life, so if you've sunk 3 into a project that's 6% ...the clock is ticking. If you're someone who sees yourself retiring at 50 then you've got considerably less time to get it right. Some people will say that's a bad measure, but there's a reason for the 'fail fast' mantra, if you're smart you know when to cut your losses and try something else. Many successful founders put a huge part of there success down to luck and timing - if you know you are skilled but your idea isn't reaching fruition then you need to increase the odds in your favour by playing the game more often and faster.

          1. 1

            I like how you put it - I have sunk in 6% into this. All of these comments making me take a hard look at what went through. One of the reasons for me to blurt it all out on a platform like IndieHackers is to reflect upon my decisions and do a retrospect. Sometimes you need to say it out loud to hear it back.

    2. 2

      Thanks Jehna.

      This is something that you get wrong the first time you start to do something: you're not that good in cutting down features.
      I completely agree with your point. Well, I have read Lean Startups and I have been a lot into doing minimal viable and launch quickly. As Reid Hoffman said, "If you are not ashamed of the product you launched, then you launched too late.". Even after having knowledge about all this, it was a shortcoming on my part to not scope the project out realistically and not cut down on the features.

      That's called the sunk cost fallacy.
      Thanks for the reminder. I think this is what I needed. It is like you have spent your time in building a wrong product, but you just keep building it because you have already invested.

      I appreciate you being direct here. Thanks again. :)

  2. 2

    Getting any software project out to market is a huge thing. These days we all work so much smarter than we did in the old days. Thats partly because of the tech stacks available to us and mainly because of the knowhow thats been shared in books like The Lean Startup. Having been burned once is a huge asset, when you do it subsequently. So whatever happens Tanmay you've earned a phd of sorts.

    Just about the "working for free" thing. This is a huge red flag for me. Any project I have been on where its, "from each according to their abilities, and we will figure out the money later" ends badly. Usually I have lost months of weekends and late nights coding. While someone else who couldn't code but is great with a whiteboard and marker lost a lot less.

    These days I would probably start out with "we all put in 5K and pay ourselves for our time" (IOUs if need be).

    1. 1

      That is definitely a better way of approaching it. I think this is where we got it extremely wrong. Since nobody was taking any salaries, we didn't appreciate the amount of time we were putting in and what is the cost of that time. It could've been used otherwise.

      Even if we pay ourselves a minimal amount, it will help us keep a check on how much time has been spent.

      Thanks for the tip, Justin. 👍

  3. 1

    I feel your pain. I've just launched after a few years of development and now have the chamtto bring to friends on board to help speed things up. After reading this I need to take into account how it might slow things down!

    1. 2

      One thing I would again like to point out is have clear division of responsibilities and you gotta trust their judgements. If you question someone's judgement and come back to it again and again, then you are just utilizing two people's time. You would have been better off making that decision all by yourself.

      Another thing is have someone take the responsibility of managing the project and communication. I have seen things go hay-wire when we lacked a PM.