I’ve been a full-time founder for almost a year but have been into startup culture for most of my professional career as a software engineer (~4 years).

At myqoob.com we have built an MVP in 5 months with a small team of developers and designers, made a lot of mistakes, and learned a ton.

We knew about things we shouldn’t do, but knowing and doing are so polar. Knowing the path is wrong doesn’t mean our emotions won’t lead us there. You should understand the path is wrong — knowing is not enough.

Sure, I still have a lot to learn, but I have understood a bunch of crucial lessons along the way and I am more than happy to share them with you.

1. Your case is not so special

Sometimes it feels like your situation is super unique and your plan that includes the well-known mistakes is justified.

Zero times we were right following notorious first-time founders’ mistakes.

• We started building the product without idea validation. We didn’t even understand the problem we are trying to fix. That mistake cost us tens of thousands of dollars wasted on the product no one wanted but us and investors. Yes, we’ve got the first investments at the ideation stage, and that’s another story full of lessons.
• We were adding new features over and over until we’ve raised a monster swiss army knife instead of solving the problem our customers face. We were blinded by our feature-rich big competitors.

2. Test your goddamn code

I know it feels like you should ship as fast as possible — no time to write some tests. It sounds like a good idea unless you change the codebase frequently. Do you change the code frequently at the startups? Like, do you pivot your ideas from time to time? I think you do. I think you make dramatic changes regularly. At least we do.

Tests allow you to refactor the code with confidence and take out one reason for not sleeping well. I’m sure you stress out about lots of things already. Do you want to worry about your code failing over basic cases?

3. Be picky with partners

The best-case scenario is you and your co-founders are long-term partners, since your company is so successful you can’t work on anything else.

I would say, you are marrying your partners and you will spend a significant amount of time working with them at the most stressful pace you have ever had. Would you marry a person without dating them for a while?

• Trust is vital. If you don’t trust your partners, they don’t trust you either.
• Focusing on the same goal is vital. It’s harder to reach a consensus when partners have different perspectives on the endgame.
• It’s great if you find them smart and capable of making quality decisions.
• It’s great if your vibes are matching.

Business relationships are still relationships between human beings. Even the healthiest relationships have ups and downs.

4. Don’t start if the risks are catastrophic

If startup failure ruins your life — don’t do it. Startups tend to fail. Even if we think we are special enough or maybe we think we know things that others never did. Most startups die chasing the product-market fit.

If you risk your whole life and career, you will choose only the safest ways. People are emotional creatures and fear is a strong feeling. Fear makes it harder to risk. Fear makes us blind. Fear is a bad feeling we want to avoid. So, how do we avoid fear? We seek safety. We seek good news and complete knowledge because it’s so good to know everything.

It’s way harder to build a startup that never risks. Investors don’t put money into startups because it’s safe.

5. Start as small as possible

Working on a small project is such a pleasure. You can change almost anything you want and fix nothing after.

• You don’t need those microservices — one codebase is so easy to work with.
• You don’t need that ElasticSearch cluster — Postgres is good enough for a full-text search. (i.e. whatever good enough generalist tool instead of a specialist beast)

I don’t mean to prioritize easy solutions, but to objectively identify your requirements. For most early-stage startups complex solutions are overkill.

6. Hiring is hard

Convincing people to join our startup is a skill I never had a chance to practice. Competing with large companies is unfair, yet it is a fact we had to accept.

Deciding if the candidate is a good match for a team is another story. Should we hire that genius guy who seems to have some asshole vibes? After a couple of interviews, my gut feeling said it might not be comfortable to work with him.

I had to reject a candidate when we were desperately looking for help, because of that feeling in my gut. Was it right or wrong we’ll never know, but after managing people a bit, I started trusting my gut feelings.

7. Don’t expect people to change

Managing people taught me a lesson that people barely change. If you knew a person as a lazy one a year ago, they’re probably still lazy and will perform just as they always did. Don’t assume it was the wrong environment or time for them. They are a person who behaves like that and you cannot force them to change.

8. Clouds are not that complex

Just start simple. One service at a time. You will get the whole picture after a couple of iterations.

I have started with just a bare minimum of EC2 instances on AWS and learned new stuff by doing small enhancements. After a couple of months, I was acquainted with a dozen of services I never heard of.

Mastering the managed services and auto-scalable solutions eliminates too many problems to be ignored.

9. Write everything down

Startups require a lot of decisions daily. Most of them are important. Log them all, especially the architecture decisions. Explain why you did this that way. Explain the context.

At a startup, you are going to learn a lot almost every day, and you are going to be way more experienced every two weeks. Prove your future experienced self you weren’t that stupid two weeks ago. It’s very easy to forget what was the shadow reason for choosing A, instead of B, C, and D.

10. Don’t make it perfect

You have to make everything good enough to work and nothing more. You’ll have to do things that don’t scale, that aren’t perfect. And tolerate those imperfections. They work now. And they will continue working in the visible future. Keep it in mind, and switch to the next important task.

We always had refactors and optimizations in the backlog, but some of them became deprecated before we even noticed them.

There is a higher chance this new super optimized piece of code will be wiped out next week, rather than staying there forever.

11. Yet, do it right.

Yes, this point might seem to contradict the last one, but don’t get me wrong. You don’t have to make perfect decisions, that solve 100% of edge cases. Most of the time 90% is enough. But doing even 90% doesn’t mean you have to do it wrong so that you would refactor it in a couple of days. Write durable code that is open to extensions, not to be trashed out.

If you don’t have time to do it right, when will you have time to do it again? © John Wooden

At the end of the day, absolute responsibility for something meaningful means lots of trials, failures, and tough lessons. Being a startup founder is a gift that challenged me to find the most thrilling ways to make mistakes, fix them and achieve results.

I wish I had fewer expensive mistakes, but again, would I understand those lessons without paying for them?

I hope you enjoyed the article and found some of the lessons useful. If so, feel free to follow me on Twitter, I promise to start posting there in the upcoming future 🙂