When I started to implement the idea of an antibudget app I had a long list of things (my backlog) that I wanted to implement. I knew, if I would implement all of it as part of a first release, it would have never been published. Why?
It’s about myself: I would have lost the motivation developing a long period without any feedback. Yes, having a vision and a mission is important, but you also need something that is achievable in short term that let’s you see first results as soon as possible.
Most important it’s about my users: When you start a project like this, you know less about how your users like the app than at any later point in time. In my opinion, it would be even arrogant to waste time in planning and defining detailed specification for things that you don’t know yet. Apps developed in a classic approach waste a lot of resources:
- only 20% app functionality often used
- 30% app functionality infrequently
- 50% app functionality hardly ever uses
It’s clear that my users only deserve “the good functionality” and of course I don’t want to waste my time developing something that no one may never use.
With that mindset, I choose a minimum set of features that were just enough to make the app useable on a daily basis. I stayed focused to only implement this so called minimal viable product (MVP). I was able to get the MVP in daily use for my first two users extremely fast and got into the position I wanted: Early success to keep myself motived and continuation of development based on what the user wants.
The latest version of the Antibudget app is available here.
Antibudget 