9 major mistakes made in the first year of our startup

To make it clear what we are talking about, I will say straight away that our service is the ContentMonster.ru copywriting exchange. At the moment, it is running more than 300 orders a day and constantly working more than 400 authors. We have been working on its creation for more than a year and a half, and during this time a number of “cones” have been filled, most of which could have been avoided. Most likely, if there were no mistakes made, then we would grow faster, there would be more users, and the psyche would be more stable. So, let's begin.

1. Run the update on Friday.
')
In order for the project to please its constant growth, you need to work on it tirelessly. Users are waiting for the new functionality, asking to make the necessary features for them, hinting that some more and they will be offended and go to the competitors. We constantly record the wishes of users in a separate list, do the most pressing tasks at the moment and upload updates to the working server.

Empirically, it was found that it is best to upload updates on Tuesday morning. On Tuesday, the system uses the largest number of people compared to other days of the week and the probability that the error will manifest itself is maximum. Wednesday and Thursday are slightly worse, but they are also suitable - there are almost as many users, but the probability of catching errors before the weekend is less. The worst pouring time is the second half of Friday. In this case, "not boring weekend" is almost guaranteed.

For ourselves, we have developed a strict rule: if you did not have time to fill in until lunch on Thursday, we postpone the launch until next week.

2. Time did not extend the domain.

Our system uses several different domains. On one of them is a system for checking the uniqueness of texts (all texts written by the authors are checked for uniqueness before being sent to the customer).

One evening, because of the non-renewed domain, the uniqueness check stopped, and the whole system stopped behind it — the texts simply were not sent to the customers. This error is worthy of a noob, but it took place and nothing can be done about this fact.

The conclusion is obvious: carefully monitor the status of payment domains, hosting and other online services, using special software in the form of calendars or planners. Extend domains as soon as possible, and not to postpone everything for the last moment.

3. Test the new features “live” on the production system.

Once, at the time of testing the exchange API system, a significant part of the working database was deleted. Everything ended well (the hourly backup helped), but the unpleasant aftertaste remained for a lifetime - a very unpleasant feeling when you press the button and a huge piece of the base is removed. This situation arose due to the fact that the untested functions were uploaded to the working server.
In addition, everything happened at 1 am, when our programmer, of course, was not in the workplace ... without a programmer, everything was restored, but it cost a lot of time and nerves.

A simple and very important rule has been imprinted all my life: test, test and test again before pouring! And to make important technical changes at a time when all team members in working mode.

4. Be careful with bulk operations.

At the beginning of the service, with the payment of fees to the authors, the payment was made twice. As a result, it was necessary in personal messages to ask the authors to return the money. Feels like - not very nice. All copywriters except one, the money returned.

As a result, the rule was born: always do a selective verification of data before clicking on the "Pay" button.

5. Bulk spam.

The real epic fail happened with an email newsletter about a month ago: the first 500 customers received 500 (five hundred) emails with system news each. As one would expect, we have not received so much mate in our address over the entire existence of the service. It turned out that the script worked in the debugging system, and without making a test mailing, we did not notice.

Conclusion: before any mailing, you must first make a test on 10 emails, including several of their mailboxes.

6. Many projects in work simultaneously.

Probably, each creator of his own service once had a “brilliant” thought about a new super-megaproject that “surely shoots,” and therefore “it must be urgently done before it appears.” And so we rush to register a domain, design a system and create a new creation. As a result, at best, tomorrow we wake up with the thought that yesterday we invented some nonsense and have the domain we don’t need, at worst, we spend n person days creating a system, scoring for the main project.

Now I will say a banal thing: it is impossible to develop several serious projects at once. Spraying of forces inevitably led to a decrease in the growth rate of all projects. Now we have several unnecessary domains and two large projects that we are trying to develop at the same time.

We try to deal with this impulsiveness and, at least, not to start new projects in the first few days after the emergence of the idea. We write down ideas for new services in a separate list - let them stand.

7. Development of complex functions and options that are not really needed.

Each of us has many illusions in our heads — delusions about reality. Some of these misconceptions relate to the product that we make. It is illusions that force us to develop and implement functions that are not ultimately claimed. This is very disappointing and leads to loss of time and missed opportunities. We repeatedly introduced functions that are not used or are used very poorly. For example, direct transfers in the system.

Therefore, it is necessary to poll users before creating a new functionality, whether they need innovation at all. The following model has proved itself very well - to do only what many people ask for at once and not to pay attention to single requests (especially if their implementation is associated with large labor costs). If you want to introduce something "revolutionary" - something that users do not suspect yet, it is advisable to consult with experts.

8. Delaying the release.

We could save a few months if we immediately launched the beta version of the free exchange option, without perfecting unnecessary functions.

Conclusion: to show the public (limited circle of people) a new development as soon as possible after the start of coding. Let it be still raw, but we will learn about the right vector of development at the very beginning.

9. Purchase of advertising without conversion price.

Some advertising was quite effective, but most of the money invested in it was wasted. Here are the errors in this area, which led to significant monetary losses:

- money was lost on contextual advertising, which did not allow conversion (at first we simply did not bother to set up a conversion accounting system).
- Purchase of blog posts with a focus on the number of feedburner subscribers (this rating can be screwed up).
- purchase of posts from bloggers who did not use our service (such posts were not interesting and advertising, posts of real users give a completely different effect)
- the attached topic on the Searchengines.ru forum gave very little traffic and also did not pay off.

As a result, a few months ago, we decided to temporarily refuse to buy purchased advertising and this did not affect the growth, which is mainly due to viral factors.

A lot of mistakes were made, there will be new ones, because the work on the project continues. It remains only to learn at least from their mistakes (and better learn the similar experience of other people) and not allow them to repeat in the future, as well as try to predict new ones. After all, only those who do nothing make no mistakes.

UPDATE: And what mistakes were made while working on your startup? I invite you to share your experience in the comments!