Why does it take so long to launch a startup?

“Have you launched yet? No?! Why not? You guys have been working on this for quite a long time, what’s going on?”

We’ve had that phrase coming from everybody: family, friends, significant others, the bartender from our favorite bar, people who subscribed to your smoke test a few months back… E-very-body.

You can either engage and explain the ins and outs of what we’re doing, the why’s, the way we’re working and so on; or you can just say “we’re on it, we’re getting there, we’ll let you know”. Any guesses on which answer I usually give? Nonetheless is a frustrating moment.

What follows is not an explanation of every code-based product startup out there, but our experience so far. We just launched V2 and V3 is on its way, where we completely rethought our approach, but that’s another story. Here’s the story on how and why it took us almost 4 years to get here. I just wrote it and I can’t believe it, but here we are.

If I had to sum up the story until today, it would look something like this:

Chapter 1: I have an idea!
Chapter 2: Who is going to like this?
Chapter 3: We’re the kings of the world!
Chapter 4: The valley of death.
Chapter 5: The light at the end of the tunnel.
Chapter 6: We’re still here.

If you built something, you’ve probably experienced some of these chapters. I’m sure some were different, you might have more or less “chapters” but the overall arch might look like this. In our case, we’re — for the most part — the same core team of 3 people working and we’re not doing this full time. While building this the team had jobs, we wanted to have somewhat of a normal life instead of living off ramen and tap water — we went through that before, and we didn’t want to do it again.

Chapter 1: I have an idea! (6 weeks)

That magical moment. The moment you think you’ve come up with something brilliant that is going to change the shape of the earth. It hardly ever is, but for those minutes/hours or even days (just a couple of days, if more than that, please seek help) you’re submerged in that bliss of thinking you’re brilliant. Calm down, ideas are worth nothing without implementation. You can day-dream all you want, but you still have done nothing.

You buy the web domain, get the social media handlers so no-one gets to them before you do, and write 3 pages on how/why this should work. Fantastic. You haven’t slept for 2 days, spent $50 and you’re driving your spouse insane telling her everything about your idea.

You can check out the post on how the basic idea came about and why we’re doing this. The basic idea came up in a coffee shop a few years back and stayed in an “ideas” notebook for another couple of years, until one day in January 2015 when it all clicked and something like what I described in the previous paragraph happened.

Once the idea came up, I wrote everything that came to me. How the product would work, how the business would work, why people would use it and so on. With that, I called someone who would be honest with me and play the devil’s advocate: question everything and see what answers the product has. Not my answers — it wasn’t about me — it was about how the product responds.

Once it passed that test, it was time to go out to people who weren’t obliged to say it was a good idea. I put together a list of professional musicians and musicians I’ve met while touring with my band a few years back. I wrote a detailed email with very specific questions. The email had a very straightforward subject “Hi [NAME] — Music start-up — we’d love your input!”, and after explaining what this was all about — short video included -, we went with 3 specific questions:

1. What things do you think are cool about the platform and which ones do you think are not that cool?
2. How much would you pay for a High Quality, multi-track loop?
3. Would you upload loops so other users can use them and buy them?

Most people answered, which was awesome. And the answers were very positive. Great, this looks like fertile ground. Onto the next step.

Chapter 2: Who is going to like this? (3 months)

Let’s suppose that we have the product ready to go. Would people be interested? Would people sign up? There’s only way to find out. Let’s do a smoke test.

In a previous post on how Federico became OneMillionLoops’ technical co-founder I briefly explained on how we did the smoke test, and I will write a post solely dedicated to it. This smoke test had a dual intent: test if people would sign up for the product and get Federico to join the team.

Federico and I worked for a month to create a dummy site with no music, just html and a basic design, with the only purpose of creating a showcase video. This video had a voiceover (my voice), background music and the best explanation possible on how the product worked.

That video was used in the emails explained previously and an updated version of it — focusing on why we’re building this — was used in the smoke test.

The smoke test was a Facebook campaign aimed at the niche we believed was best served with: music teachers. The ads were segmented by each type of instrument: drum teachers, guitar teachers, bass teachers, piano teachers, sax teachers. 6 landing pages in total.

Each landing page had detailed explanation, a custom video for each instrument, a form to sign up — which redirected to a “we’re still developing” message”. Also, we created a full website (we had to create the illusion of a working product) and activated a Twitter, Facebook and Instagram account. Did we go a little bit overboard? Maybe, but we wanted to be sure.

This circus paid off. More than 120 people signed up. After the initial frustration of some (some people were a little pissed off that the product didn’t exist) we had people to reach out for feedback, and — most importantly — ask them why the signed up.

Almost 5 months went by until this point, but we gained a lot: we iterated the idea a few times, fantastic feedback and an initial set of users.

Let’s keep moving.

Chapter 3: We’re the kings of the world! (8 months)

We got this. We have the team, the idea, the early users and we (think) know how to get this done. We feel great and we think we have the tiger by the tail.

Small detail: the team now has to go from “testing mode” to “developing mode”. And that is a whole different ball game.

I went into a lot of detail in its dedicated post on what took Federico to join the team and the conditions we agreed. I had to learn to code. But also, our design partner had his terms as well: we all have to work together and make it happen. Can we code? Yes, but the question is: what do we have to code?

That fall, 7 months after we started all this, and with all the feedback, we began to think about how the product would actually look like, behave and interact with users. Nicolas and I had dozens of meetings, discussions, arguments and drinks. Drawings came and went. By early December we had a design we could all get behind. Great. Now what?

I was still learning how to code. Luckily for me, Nico has his coding chops together, especially in front-end design. So I had 2 partners I could go for advice. With the mockup ready, we were ready to get into coding. Ready. Set. Here we go!

Chapter 4: The valley of death. (18 months)

The term death valley generally refers to the high probability that a startup firm will die off before a steady stream of revenues is established. But we haven’t found a lot of material on what happens with the team while developing the product. A key disclaimer here is that we actively decided not to raise capital and not to hire developers to help us. Many might think it was a mistake and as a result it set us back several months. Our take on it was (and is) that in order to avoid the real “valley of death” in the future, we ought to keep our overhead super low. As described in Investopedia “After a firm receives its first round of financing, it can experience a number of initial costs. Offices are usually procured, staff is hired and operating costs are incurred; meanwhile, the firm is not earning significant income”. We had none of that. We rather be slow than dead. You might disagree, of course, and we’d love your feedback in the comments.

How do we make multiple audio files to properly play simultaneously and synchronized?

How would the algorithm work?

How do we implement it?

How do we make an integration so seamless that all this works in a musical environment?

How do we make it as user friendly as possible?

It turns out we were up to some titanic tasks. Federico designed and coded the back-end using tools he designed, Nico and I had to learn them in order to have a proper integration between back-end and front-end. These were months and months of development. We decided that we were going web-responsive instead of developing in native iOS or Android — you might disagree, but that’s a discussion for another day. I’ll write about it. We encountered dozens of issues we were not aware when we started (ie. iOS Mobile won’t let you play files on first click … just a quick example on the gazillion of issues we found and solved). But little by little, all issues were being resolved. Some issues took a day, some took a week and others took entire workarounds and a lot of thinking outside the box. But we did it. Just us. The list of things was looking smaller month after month. Maybe there’s an end to this. Maybe we can have a working product for our users.

Chapter 5: The light at the end of the tunnel. (8 months)

We were finally seeing the light at the end of the tunnel. The basic product worked and we started testing it by ourselves in the rehearsal studio, showing it to friends and taking notes of the changes. It was plagued with bugs, it crashed more times than it should, but it worked. The algorithm worked. The browsers could hold the load of high quality audio. We didn’t have to compromise quality. Things were looking better.

Development was flowing, sometimes it was hard, but we were moving forward. So, is that all we need? Of course not. If you want to build a music-based application, you need… music. We had an initial set of loops recorded by myself on drums and Nicolas on bass, but we needed more. A lot more. Friends helped with guitar loops. But we need more. So we reached out to the people who subscribed to the smoke test and explained where we were and if they wanted their loops featured. A lot of them replied and it was great. We got dozens of bass, electric guitar, drums and acoustic guitar loops. We still had to make sure that these were good-sounding loops and up-to-standard with what we’re trying to build. So a lot of editing and mixing went into them. Weeks and weeks of emails back and forth with musicians, editing and mixing. We re-tested the algorithm over and over again. It held. We’ll be OK after all…

By early 2018 we could see it, we could taste it. We have 90% of the code, of the music… finally!

Chapter 6: We’re still here (14 months and ongoing)

We coded an admin interface, an email-based invite system and populated our social media with content. We were getting ready to launch a rocket. By March, we were almost ready. I bought a ticket to The Netherlands (where Federico lives). By April everything was set. The day before flying to Amsterdam I sent the first batch of “Welcome to OneMillionLoops, here’s the link to the log in” emails. Spent the entire flight working, reading and planning. St Paul, MN to Amsterdam is an 8 hour flight. Not a minute of shut-eye. Landed, greeted Federico, got to his place, fresh pot of coffee and kept going. Sent over 200 emails before my brain shut down. We launched V1. Sweet dreams (are made of this).

If you haven’t noticed the red flags above, let me break them down for you:

• Did I mention anything about thorough QA? No, I didn’t.
• Did I mention anything about UX testing? No, I didn’t.
• Did I write anything similar to launch with a few users and move incrementally, so you can fix unknown bugs? No, I didn’t.

2 days later we were fixing bugs at 3AM and getting emails (some of them with videos) of some frustrated or confused users. Learnin’ the hard way.

But we got so much good, honest feedback. We learned. We immediately started to think about the next steps, about what needed to change, how to better serve our users. And so the concept of V2 was born. And now V3 is coming up.

We came in short for V1, but we fixed everything that didn’t work the first time (QA, UX, launch incrementally, don’t fly to Amsterdam). We are still here. And we will be here until we deliver the best product possible to our users.

—

Author’s note: As this story unfolded, life went on, which tends to be forgotten when we factor in time of a project. Life takes time. Federico and I married (not to each other, though*), Nicolas married, relatives passed, friends married and had babies, etc. And we were lucky enough to be there for our friends, family and life in general. Life takes time.

*It was discussed one time, many years ago, fresh out of college. The bank didn’t allow us to open a joint account for a business we were trying to do, and we didn’t have the money to form an LLC. The bank clerk jokingly mentioned “you guys could get married”, and we — for a few hours — considered the idea. I got cold feet. I didn’t know how to explain my girlfriend — now wife — that I married Federico instead of her. Ho well, at least he stayed…

Originally published at http://www.onemillionloops.com.