If you’re a certain type of engineer, there’s a temptation to over engineer your product when you first launch it. This is often a big mistake as the most important part of building a product or app in the beginning is launching it and getting feedback. Perfect engineering will slow you down and in most cases won’t make a difference on the outcome of your product for some time to come.

I’ve fallen into this trap many times. I’m a sucker for engineering design patterns, the kinds of things you need when your product has 10’s of thousands of users to sustain a serious user base. When building new apps, my first instinct is to apply perfect engineering principles to the code base—properly abstract code, write test cases, run a ridiculous QA cycle, subclass, write protocols, design a perfect networking layer, etc, etc.

What ends up happening is you spend a lot of time coding, when what you should be doing is spending time getting feedback on the product so you can iterate and improve on it.

Instead, focus on building a high-quality app experience that demonstrates the functionality you believe is critical to a successful user experience. More than likely, the first version of your app won’t be the knock-out viral product you hope to be. That comes after weeks and months of iteration. Backend models, UI, design, user flows, and onboarding will all change. So write crappy code and get it launched sooner. Slowly improve over time as your user base demands it.