Costs to develop an app – part 3: Five pitfalls to avoid

The implementation of secondary features into the product before it is ready for release. Often this arises from the (understandable) need to make the product more appealing or useful (premature scaling). What to do? A shared commitment to a quick release with some basic features could be useful here. This idea isn't new – it is taken from the methodology of Lean Startups: publish an early prototype, and the experience will provide you with excellent information on whether a more advanced feature is needed and what exactly it should look like. After all, you can easily observe and plan "in the wild" and gain insights into how to proceed with an app.

Each line of source code added to a project increases the number of dependencies within the source code. And the larger and more complex a piece of software gets, the more error-prone it becomes as well. The mechanisms to avoid this (design patterns, best practices, testing, etc.) are both evident and effective - and yet they increase the workload even in the most experienced team. Therefore, even after the release of the first prototype, it is even more important to carefully select a good feature set. One which creates the best conditions for a smooth implementation.

A subsequent change to a specification at a time when it has already been (partially) implemented – for example, when an order summary needs to be revised again due to a veto from the legal department. This is why decision-makers should sign off all the most important product features before they land in the backlog and go to implementation. In reality, this is not always feasible. Even more reason why a tight feedback loop with key stakeholders is important. Candor and close communication help to correct faulty specifications quickly.

A solution which somehow works but isn't executed very well. It offen makes its appearance in projects with added time pressure. Such technical debt is often taken on with the promise that it will be replaced by the "right" solution in due course. In reality, these refactoring phases are more exception than rule. So provisional solutions tend to create dissatisfaction. From experience, we can say that the decision against technical dept, and for a solid, scalable implementation always pays off in the long run.

User interface design niches sometimes hide unforeseen shallows. They become apparent when, for example, a test user asks "what happens when I click there?", "where can I set this?" or "what does the empty shopping cart look like?". If these questions leave a bad feeling or even cause uncertainty in the closer team, caution is advised. So what to do? In the long run, it is not a good idea to just continue coding. Hidden shallows are harbingers of expensive refactorings. The skeleton and foundation of a user interface should always be user experience. Productive teams see unresolved UX issues as an opportunity to fill the gaps in the user stories. The best way to do this is to get developers, designers and the most important decision-makers on the drawing board again.