We’ve worked with Otto for many years and we continue to maintain, support, and add new features to both their web and IOS app.
Many entrepreneurs underestimate the amount of support and maintenance that web and mobile apps need. One of the most costly items needing maintenance is integrating with third party data providers. This is why you should always involve your developers in third-party decisions.
Otto did consult with us about Finicity and we’ve been very happy with their service but because it services the financial industry they’re constantly updating to the latest technology. As Finicity upgrades their api, our integration needs to be upgraded as well. To minimize the affects of third parties on our codebase, we build in a forward-thinking way to make it easier for future developers to make these updates.
We also added several new features to allow users to share their budgeting data with their financial coaches. These new features allow Otto to focus their marketing efforts on financial coaches rather than the end user. Delivering code solutions that drive business goals is what sets us apart from other providers that just do what they’re asked and don’t proactively try to understand how the code connects to the strategy.
Given that this app deals with financial data and integrates with banks all over the world, we have to stay consistently focused on security. Luckily, our client is proactive about weeding out fraud and abuse. Maybe even too proactive (if that is even possible). They asked us to make some changes that would be good to have, but that made us hesitant because there were other more important security features that we’d have to table. We pushed the team to take a step back and create a priority list of security features that would be more affordable and also more effective. This resulted in some easy changes that continue to help us catch and eliminate fraud attempts.
Lastly, we continue to fix small bugs found in the system. It is impossible to list all the ways bugs get into a system: sometimes bugs were introduced by the original logic specifications, sometimes when new features are specified without fully taking into account the entire system, sometimes they’re because the original code incorrectly passed the quality assurance tests, sometimes because of miscommunication, and sometimes just because of human error. But, regardless of how they’re introduced, we’re able to get them resolved quickly and effectively. Luckily, most bugs are small and affect very few, if any, users.
