Is it better to have finished or perfect software?

Understanding when it’s time to make software operative

Startups which design software – or companies that have it created – may be tempted by the idea of launching “perfect” software that has all sorts of functions, but they have to be careful not to invest too many resources before having tested the validity of their idea on the users.

Designing software is an investment that can keep a team busy for months. To avoid investing your resources badly you have to define the scope of your project in great detail.

To explain the concept of scope, let’s make a practical example: we are developing a mobile app to monitor and manage the daily expenses of a user.
The basic service in question must allow the user to input their expense items divided by day and certain other categories (shopping, gas, gym, phone recharge etc.). Furthermore, the app could integrate other additional features: monthly trend graphs, personalised categories, income imput, balance etc.
Defining the scope means deciding how many and which of these features will be integrated in the 1.0 version of the software, i.e. the first official usable version.

As you may have already understood, defining the scope without getting carried away with the desire to integrate additional functions is not so easy.

Setting a limit for version 1.0

Being convinced that the software should already be perfect in the initial version can be a problem: our first attempt at designing a web app taught us an important lesson in this sense.

It was 2013 and Federico – our current CEO – had brought us together in a startup full of enthusiasm, but with a lot of experience still to be gained; our project was called Checkyourlife.
For economic support, Dreamonkey Srl was founded three years later and one year after that Checkyourlife would falter to leave room for our current company situation.
Once that period of professional growth was over, among others, we learned an important lesson: putting off the release of a project to allow for the umpteenth “essential feature” leads nowhere.

The obsession for the perfect app

When someone undertakes this type of project they quite rightly compare their ideas with what already exists on the market.
This comparison leads to the conclusion that you need to launch a service that is just as multifaceted, often ignoring, or underestimating, how much time and effort it took for those competitors to get to where they are step by step.

The approach is not wrong per se, we have to be fully aware of who we are going up against and what our real possibilities are. However, we run the risk of getting lost in an infinite cycle of design and development fueled by the obsession of making the app perfect. The mantra of the team becomes: «How can we compete with other top level services with so few functions?»

The result of this cycle is to suck up the resources of the team – or the company – before seeing if the app really meets the actual user needs.

When everything goes well it’s great. you’ve hit the jackpot, but what if there is no light at the end of the tunnel? What if after all the investments in time and money you discover that the starting idea is not really what the market wants?

The 1.0 version of the software should include the real unique selling point, i.e. what the competition is missing – or we can do better than them – to capture the attention of the possible users and meet their unsatisfied needs. In any case, you must be able to test the scope quickly.

Trading perfection for the field test

Knowing how to define an essential yet suitable scope and finding the courage to dive in is a real challenge, but it is essential to make that effort.

Sacrificing perfection allows you to respect the release deadline and use the time saved to actually test the effectiveness of the app. Knowing the response of the users based on a limited number of features allows you to make a note of the important improvements to be made for your target, so you don’t have to start from scratch with a service that is too complicated and articulate.

A project can start out as imperfect and then evolve into something more complete, if the basic idea is actually promising. If we want to see results we should not postpone the moment in which our service is put to the test. There will be time to improve.
You just have to be careful not to neglect the quality of what is designed: imperfectness with regard to quantity of features doesn’t mean poor performance or design.

Better to have finished software

The concept of perfect software is great for the marketing office slogans, but in reality it’s a utopia: perfect for whom? And under what aspects? At Dreamonkey we say that every software project is the result of a compromise.
Make sure that your app has a well-defined scope, good performance and an intuitive and professional interface.
With these premises a good idea supported by the right business model can grow and become something great.

If you are thinking of having software created – and you want a guarantee that it will be finished and operative – we are the ones for you. Contact us.