Booby traps of creating a minimum viable product

I’m working on Hoopoe App in my spare. It’s a twitter client with a great support for queuing your tweets via Buffer. I’ve used TweetDeck for a long time but the annoying thing is that scheduling tweets using it is not so fun. And I’d really want to improve it for myself.

So I thought I could kill two birds with a stone - I’d love to learn how to program for Mac, and fix my tweeter issue.

I started working on this app, keeping in mind that it’s MVP, it want only one feature - to retweet using Buffer. It’s been going fine.

First I used my Mac accounts to get tweets, then I created a simple view for showing a stream for an account. Then I showed all streams for each account. Then I thought - hey it would be great to resize those streams to match the window.

So I spent couple of evenings trying to figure it out, it works, but it’s buggy still. And then it hit me.

Dude, what are you doing? You’re wasting your time on something that’s not crucial for you. Sure it would be nice to let the user resize the window and make everything smooth. But are you really going to use that?

No. So WTF are you wasting your precious time on this. This is something we developers fail to do. We think about MVP, we focus on delivering the fix for the real problem first. But sometimes we derange. 

We’ve saw so many good apps, so many things we treat as obvious, a standard to follow, that we lose time on doing them, even if they don’t bring the real value.

So what I’m going to do now is just hard code the size for the window (you won’t be able to resize it), hard code the size of the streams, and it will work fine.

Sure, it will not be great. But as a first version that’s good enough. I want to retweet things to Buffer, not to resize them.

Focus and cut to the chase.