This article is for people who start a lot of pet projects but never finish them. It is for people who have tons of ideas but have no time to implement them. It is for people who join every hackathon but never win them.

As a startup founder, I learned the skill that is never taught in courses or colleges - a skill of building Minimal Viable Products (MVPs) without sht. What is sht you may ask? The Sh*t is the grey noise, a distraction on your way to releasing the complete product. Features that sound to be required but contribute nothing to a product.

In this article, we will get our hands dirty to identify all the SH*T developers like putting into their MVPs.

SH*T #1. Unit tests

Do you think it is fun spending 10 hours writing features and then 20 hours writing unit tests? If your answer is yes, you are definitely a great person to work at google, but you have to accept the destiny of a loser who will never win that hackathon or become a startup founder.

I don't say that tests are SHT in a long term, but it is definitely the biggest peace of SHT for an MVP.

Put 💩 in the comments if you agree, and 🚫💩 if you disagree, let's see how many govno coders are there on the Hash node.

SH*T #2. Custom design

If you still writing HTML / CZS or mobile layouts by yourself it is time to get your big lazy ass out of the gaming chair with 3 monitors and read about tailwindcss.com, ant.design, or even (god save my soul) getbootstrap.com.

I don't say that great design is not important, infact it may be much more important than any other feature, especially if you are building a consumer-facing product. But it doesn't mean you have to implement a pixel-perfect design from the dream you had 6 months ago. Just get f*cking ready to use components that look relevant and great.

Put 🖼️ in the comments if you agree, and 🚫🖼️ if you disagree, let's see how many Michelangelos are there on the Hash node.

SH*T #3. Account page

Oh no, what if the user will forget a password? Oh no, what if the user will want to change the email? Oh no, what if the user will want to reset the password? Oh no, what if the user will want to log out?

Oh no, oh no, oh no... what if the app you are building is SH*T and no one will ever open it after the registration? Isn't it the main question that shouldn't allow you to sleep at night?

If the user wants to open your crapy website again and change the password it is a good problem to have dude. Moreover isn't it great that the user can not log out? If you think your app is great, why do think users will want to log out lol?

Put 👮🏽‍♀️ in the comments if you agree, and 🚫👮🏽‍♀️ if you disagree, let's see how many lazy asses are there on the Hash node.

SH*T #4. Configurations

If you are so obsessed with a black theme, why not make it the only theme? Trust me I have never seen people being impressed by the ability to switch themes and 99% of your users will not even use it.

Besides the theme, there are a lot of product-specific configurations that you can have in mind. And you obviously wanna make the product usable for everyone and as user-friendly as possible. But the truth is most people don't give a f*ck about configuration and they will definitely start using your product because you support a white theme or alternative sorting algorithm.

Your MVP should have 0 configurations, it should be built based on your gut feeling and should serve the biggest niche. Then, if you hopefully get the first 10 customers, you can think about adding some configs, but god please, not in the MVP.

Put ⚙️ in the comments if you agree, and 🚫⚙️ if you disagree, let's see how many UX annihilators are there on the Hash node.

SH*T #5. Native app

This SHT is one of the trendiest SHTs I have ever heard of. Of course, there are products that must be implemented as native once but in 99% !!! the mobile version would be enough.

Do you want users to be able to get it on their phones? Write a simple React Native wrapper with a single WebView that renders your website. Do you want native notifications? Write a simple communication bridge between WebView and ReactNative.

The app will not work offline and it may be not as fast as the native one, but saving 80% of dev time is worth it! In the end, no one will use it, so why spend more time lol.

Put 📱 in the comments if you agree, and 🚫📱 if you disagree, let's see how many web lovers are there on the Hash node.