## Startup: What Not to Do or Learning from Others’ Mistakes

In this article, I want to share the mistakes we made during the first year of our project and the lessons I learned from them. Instead of a chronological narrative, I chose a case-based format with conclusions at the end of each case, which I believe is the most effective approach in this context.

# Starting Point

By the time we devised the methodology for memorizing and retaining foreign words and decided to turn it into a mobile application, I, as the project manager, had the following resources:

• Roommate #1 — a programmer
• Roommate #2 — an IT marketer
• An idea (in broad terms)
• Approximately $15K

That’s it! Nothing more. The doors were closing; the next stop — Startup!

# Case 1

Our programmer (let’s call him John) was a competent and cheerful guy who had graduated with a degree in Computer Science and was freelancing as a web developer at the time. He eagerly agreed to try his hand as an iOS developer. The advantages for me were that John lived in the next room, I knew and trusted him, and his services were very affordable since he had no prior iOS experience.

After a week of reading the “iOS Developer Guide,” John began producing some results. This really inspired me: the rigor of Soviet higher education and the versatility of its graduates in action. Starting to program in mid-June, we planned to launch in September, just in time for the school season. My initial excitement about John quickly mastering a new programming language was replaced by restrained emotions after a month, and another month later — the launch date was postponed to “an indefinite time.” Deadlines were systematically pushed to October-November when John first disappeared for about three weeks, and then he was called to honorable service in the Israeli army for two years. The end. Curtain falls.

Conclusion 1: A startup is a very harmonious and delicate system, all its elements must be balanced. If someone is willing to do something very cheaply, it should not become the deciding factor in choosing a contractor. The idea is that you should never skimp on elements that play a key role in the success of the entire endeavor.

In production management theory, there’s a concept called the “Bottle Neck” — a narrow spot: no matter how well and efficiently individual elements of the system work, if there’s a process that slows everything down and causes issues, it becomes the bottleneck.

Conclusion 2: Avoid working with acquaintances. Yes, on one hand, you have great mutual understanding, but often we sacrifice professionalism and responsibility. In the first case, unrealistically projecting a friend’s personal qualities onto their professional abilities; in the second — as a result of a favorable psychological environment for negligence: a friend will always understand and forgive “if something happens.”

If you decide to work with a friend, make sure to formalize your agreements in writing! This increases mutual responsibility and helps maintain normal relationships in the future when questions arise about who is responsible for what and when something should have been done.

Losses: 6 months and approximately $10,000.

---

# Case 2

By the end of summer 2011, when John had finished reading the iOS development guide and our company almost instantly became a leading mobile app developer both in Israel and globally, I decided to make some extra money through external orders. Complex projects were planned to be outsourced to acquaintances, while simpler ones were to be implemented with John’s help.

I actively began attending various events, networking, understanding the market, etc. The most interesting thing was that we found one client: a music band application that included audio recordings, photos, news, and a events calendar. Such outsourcing is rare. Young companies need developers in an in-house format; larger and more established ones might outsource, but only to known and reliable firms.

We managed to create an application with a number of bugs as a bonus within 2-3 weeks. We earned $500 and, buoyed by success, cast our nets towards acquaintances in the show business. The idea appealed to a well-known pop artist; I made a beautiful presentation and went to Moscow for negotiations. As you might have guessed, it didn’t end well. Thank God!

Conclusion: A startup is a race against time. You need to create a working product and find a profitable business model before you run out of money. Don’t waste time and engage in side activities. You’ll lose much more than you gain. Time is money!

Losses: 1 month; $1,000.

---

# Case 3

On one hand, the universal nature of the memorization methodology I developed and, on the other hand, the global aspect of learning foreign languages, pushed me to include flashcards for learning six languages right from the start: Russian (my native language), English, German, French, Spanish, and Italian. Hebrew was postponed for better times due to its “commercial unfeasibility.”

Where we sourced the language base — I’ll skip. At that time, I needed the most ready-made option and found it. (I believe that in the launch phase, you can use any means, even if it violates intellectual property rights. It’s a battle not for life and death, and all means are fair game. However, you must plan to transition to legal practices after launch (or better yet — before!).)

The structure of this “source” allowed me to easily create cross-pairs (English-German, Italian-Spanish flashcards, etc.). It turned out to be something like a large matrix. That’s 30 possible directions for learning! Potentially 100 million users immediately! After cleaning the list, about 3,000 words remained, and we began designing and recording them. This was a significant competitive advantage for the app.

Images: We found an artist who turned out to be professional, reliable, and punctual beyond her years. However, a few days later, it became clear that abstract terms required descriptive instructions from a linguist — what and how to draw. So, we started creating instructions for 3,000 words.

Recording Audio: “What could be easier,” I thought. If you live in Israel, you can always find a native speaker of almost any language. We recorded at home with equipment like a karaoke-style microphone and a MacBook Pro. 3,000 words. We figured out how to semi-automate splitting recordings into separate files, and our audio editor, Igor, helped maximize the “quality” of the recordings we made. My advice: for good sound quality, hire professionals!

Before launching in November, I had another “genius” idea to learn words based on their frequency, leading to the creation of new lists. This time, 5,000 (!) words. Learning from previous experiences, we decided to create a custom system for convenient word translation and image rendering. This time, audio recording was outsourced to professionals.

Conclusion: I can’t imagine how much time we spent creating content… and how many grandmas could have been helped instead.

Essentially, we became prisoners of our hypothesis that the app would definitely become a hit, believing that everyone desperately needs our images and audio examples. The task of any startup is simple: to validate your hypotheses as quickly and cheaply as possible. This doesn’t require making 75,000 (!!) word translations, recording them, and drawing images for all. Depending on the number of words and available languages, the project can be relatively quickly scaled. Moreover, statistics showed that 90% of sales come from one pair!!! Therefore, it’s crucial to focus correctly!

The LEAN STARTUP concept suggests testing all hypotheses with mini-experiments that provide reliable market data for analysis. Even if you’re wrong, losses will be significantly lower. With equal costs (time and/or financial), you can test many hypotheses at once, thereby significantly increasing your chances of success. This approach is called the “Build-Measure-Learn Feedback Loop.” The faster your team cycles through this loop, the higher the chances of survival. Nothing is more valuable than real user feedback!

Losses: $15,000; many person-months of work from linguists, the artist, voice actors, and programmers. I can’t fully call this a loss, but the investments were absolutely irrational.

---

# Case 4

Our ambitions required us, at the very least, to capture the entire world. To achieve this, we believed we needed to account for all possible user behaviors and life circumstances within the app. Thus, the idea of creating multiple parallel learning sessions appeared early on — in case a user decided to learn several languages simultaneously… In general, with each new discovery of hidden user needs (which, I’m sure, they would never think of on their own), the list of required functions and features exponentially grew, the technical specifications changed, and the code was rewritten.

Combinatorics Results:

• Sessions (for learning multiple languages simultaneously)
• Intensity of lessons (to adjust lesson frequency)
• Memorization capacity (setting the number of words per lesson)
• Depth of learning (how deeply to remember a word)
• Vocabulary themes (ability to learn words by specific topics)
• Frequency list (learning order from simple to complex words)
• Algorithm for selecting words for lessons
• Various flashcard settings (font size, disabling images, audio, associations, etc.)
• Built-in dictionary

We deeply believed we were creating the Rolls Royce, and therefore couldn’t ignore the details and minutiae! I suppose that’s why our miracle vehicle never rolled off the assembly line.

Conclusion: The main source of trouble isn’t the project’s conceptual changes itself. The problem lies in the project’s foundational assumptions. How did the project even start?! I needed to learn a new language and there was no suitable tool. I began solving my problem based on the assumption that it (the problem) was global and that my solution was universal. Then, I started adding features and expanding functionality to enhance this “universality.” Just in case, to make sure nobody anywhere would “bite” or “scrub.” Essentially, this process is endless.

If you have a problem (pain) but no reasons to believe that a) other people also have it; b) your solution suits them, then both hypotheses need thorough testing with a representative sample. Furthermore, it’s crucial to understand what will be a “value proposition” for the user and what functionality constitutes a Minimum Viable Product (MVP) — a product with the minimal set of features that is useful enough for the user to use your service.

Here, it’s very important to listen to what users are saying, not to try to convince them that they need exactly what you’ve created. This is a very challenging, important, and creative task. You need to find your future users within the general mass of formally potential users — those for whom and whose needs the app will actually be created. It’s very good if you end up with a small, clear, and understandable group: for example, single grandmas, aged 60-70, living together beyond the Arctic Circle and doing 100-meter sprints in 10 seconds. The narrower the group, the easier it will be to offer a solution that perfectly fits.

For a clear example, take my case: The problem of learning a foreign language seems to affect almost everyone in a civilized country. But in reality, we have three large, diverse categories — children, student-schoolers, adults — and my app resembles the average hospital temperature: on one side, 36.6°C; on the other, there are no healthy ones. Each category has its own distinct problems and features. A student-schooler studies from a textbook; needs to pass credits, exams; a child is generally uninterested without a gaming element; adults need a more practical knowledge application.

In short: as soon as you start moving from the end user and their needs to the functionality, there’s no need for universal and endless generalization of the app (or web service) to fit the needs of an imagined user, and you’ll have the opportunity to focus on critical functions that form the value core of the app. Don’t spread yourself too thin!

Losses: Several months of development that didn’t allow us to launch the project on the first try.

---

# Epilogue

The described horrors should have made you ask whether the resulting traumas are compatible with life. Indeed, we made many stupid mistakes (and will make more), but the main thing is to learn from them and not repeat them. Moreover, making mistakes is even necessary. Errors are an integral part of empirical knowledge. After all, no one is born with innate knowledge of how to create successful startups!

Understanding your mistakes and adjusting your project’s course was aided by three books. You can read them concurrently: the deeper you delve into their essence, the more you can apply the situations to yourself, leading to concrete ideas and action plans. It’s hard to say how useful they will be to someone without relevant experience. In any case, I strongly recommend the following to all startup founders (old and new):

1. The Four Steps to the Epiphany
2. The Lean Startup
3. Business Model Generation

---

If you’re interested in launching your own startup and seeking investment opportunities near you, consider reaching out to venture capital firms or angel investors. Platforms like Co-Founder Ai can help you connect with private equity companies and venture capital firms to fuel your startup journey.