It’s been two days since we’ve publically launched Delver, but with all the excitement around it feels like it’s been a year.So, in my first post here I’d like to share my perspective of what it takes to launch a product and how important it is (hint: it’s *important*).In fact, there’s nothing more important in a software project than actually getting the first version out of the door. This may sound trivial, but it’s anything but.Interestingly enough - most software projects never actually make it to this stage. If you think there are too many new services announced every day on Tech Crunch – you’re right. But this is just the tip of the iceberg – there are ten times more projects that started but never delivered their first release to the public.

The motivations to get the service out of the door are huge. Some are obvious and some are not.

First reason to release early is that you need to validate your idea. One of the hardest things about developing a new product (“New” as in different and innovative. Not a new toothpaste, which is “just the same, but we need to keep the cash flowing in”) is not knowing whether it’s actually going to be useful to people. Before launching you’re just basically throwing stones at a small target on an imaginary wall in total darkness. You don’t know what you’re doing. The best products (think the PC, the iPod, sliced bread) make perfect sense to us now, but that’s just hindsight. People who developed these products had really strong belief in what they were doing, but that belief was anything but based on facts.

What features should you develop and which not? What should the UI behave like? It’s not just that you don’t know the answers, there’s no way to even argue about them.

You need to get real users to use the actual product. A lot.

The second thing is being ahead of the competition.

Once you have an idea for a service, realize that there are only two options: a) your idea sucks or b)there is already more than one group of people somewhere out there working on the same idea.

Hopefully your idea is of the second type. Now you’re in trouble. An excellent service will fail, just because one or two other services were delivered faster. Interestingly, the other services don’t have to be better and they don’t even have to be the same as yours. It’s enough that they appear similar. First impressions count a lot. It’s ten times more difficult to succeed with a new product in a field with existing competitors. The iPhone comes to mind, but that is, as my father says, “the exception to the rule, that proves the rule”.

This is especially true of internet services. Ideas in this field are moving around so fast that things change beyond recognition within a few months. Many times an internet startup company will start with one idea and will end up changing it drastically because the outside world changed before you delivered. Paypal started out building a service for small payments between Palm Pilot devices. A similar change happened to our product here at Delver – the service we just launched is not what we envisioned when starting the company just a year ago.

Last but not least are your own motivation and focus.

Having a release milestone is probably the best thing you can do to get your team aligned and focused on what’s important and on getting things done. Without everybody having a clear idea about the release target – you will suffer from feature creep, people will be pulling in different directions and not necessarily working on the most important things. Once everybody is aligned on the goal to release the service early – motivation will go up.

It’s the same as when you’re riding your bike up a really tough climb. When you see the summit – breathing becomes effortless.

And once you have the service out of the door and actual people are using it – your behavior changes. The programmers think more about committing a change in code. Bugs are fixed faster because you know that actual users feel the pain.

More than anything – you can listen to you real users instead to voices inside your head. What features they like? What is useful and what is useless?

But just like “riding a llama” or “sex without becoming attached” – it’s so much easier said than done.

There are many things you need to fight off to actually make it to the launch of your first version.

Feature creep: people who are developing new products are very good at coming up with ideas for stuff to put in the product. And if you’re lucky, you’ve probably hired the smartest and most creative types. They’re the worse. They’ll shout: “We must support all the search operators Google supports. And we simply must enable drag and drop for users to save interesting items they found in Delver.”

You need to take a long and hard look at your feature list. And then you need to throw out 80%. Seriously.

This poses a hard dilemma: in order to release the product you will need to make painful sacrifices, especially on the usability and stability front. You’ll need to be ready to deal with some of your users getting reduced service and sometimes no service. Someone will write in their blog that you’re half baked. Be ready for it. I believe strongly that you’re almost always better off releasing early than keep polishing the product. You’ll end up releasing the most robust and polished service but have no users. Because all your users now live in glass capsules filled with jello  on a spacecraft driven by robots. Or something.

One of the things we did in Delver to deal with potential overload on our servers in the first days after launch is count the number of active users and if that amount exceeds a predefined value – navigate them to a “we’re too busy” page. We’re going to have to deal with some disappointed users, but at least we can provide service to some users earlier.

On a related note – you need to actually have a very well defined feature list for your version one. Trivial? Many software projects don’t really have one.

Another issue is the “hidden tasks”. These are the tasks you’ll have to do in order to launch but you forget about them when you make your plans. You still end up doing them because they’re so obvious once you’re close to the release but by then they’ll take ten times more work.

Typical examples of this are:

• Production servers setup and configuration
• Deployment procedures and scripts
• Mail delivery mechanisms

Another challenge in a startup company is that you’re building the service *and* the company at the same time. And building a company takes a lot of energy. Think hiring people, buying equipment, handling legal issues. Just getting the right coffee machine can take multiple attempts, many man-weeks and some programmers with a grudge and a bad stomach. It’s the coffee.

So how did we fare with our first release?

First of all – we made it. We’re out and that’s a big thing.

It took us exactly one year from the creation of the company to the launch. I would say that nowadays, an optimal time for an internet service to launch is between 6 months and a year, with some exceptions depending on the scale and complexity of what you’re doing.

We had to deal with all the challenges I mentioned and now we have to work twice as hard. But it definitely feels great to have something to show for the effort.