A custom business application can be a supremely valuable asset. But with so many rapidly improving SaaS solutions in the market, it can be hard to articulate the value to different stakeholder groups. Over the last 10 years, we’ve developed a range of custom applications for different industries and businesses and have also worked on integrating newer SaaS options into existing ecosystems. This has given us an appreciation of both how beneficial a custom application can be to a business, but also how initiatives can often go wrong.
Here I’ll discuss some of the biggest learnings and misconceptions I’ve encountered, and give some guidance to ensure you glean maximum success from your custom application development project. The learnings here are applicable across many industries, including web-based applications, mobile, and desktop across various operating systems.
Learning 1: A Lot of Value Lies Outside of the Application
When an application is done well there will naturally be improvements to operational efficiency and customer/employee experience. But organisations regularly gain a surprising amount of value outside of the packaged product as well.
One key example of this is process improvement. An application in a large business will almost certainly interact with multiple systems to support business processes – this means the solution design must consider where and how data is moving in and out of the applications and around the organisation. This analysis can take a fair amount of time (and cost) – but unless fully understood and questioned it can limit the opportunity for growth. Companies who take this chance to optimise their processes can early on design out the inefficiencies and problems that would otherwise go unnoticed. Being brave in this stage and questioning not only technology, but going beyond the simple scope of the application – this will be where some of the greatest value is realised.
Another example is strategic alignment and decision making based on the data a new application provides. Custom applications are often built to digitise manual processes or replace a spreadsheet that is not sustainable as a business grows. The byproduct of this is access to structured data that can be used to identify trends, patterns and unknown gaps or opportunities. I’ve seen many cases where new data positively influenced business decision making, strategy and sometimes even the culture of the business.
Learning 2: Build a Minimum Viable Product
In our experience clients find greater success with their applications (and lower overall costs) when they begin with a Minimum Viable Product (MVP). This is a method that begins with the most basic workable version of the application, allowing for change and mistakes before building up sophistication over time.
This differs from a more intuitive approach to simply arrive with a ‘shopping list’ of outputs and develop from there. Often these lists can blow out quickly, get more expensive or become irrelevant as the client discovers new opportunities and goals, making the project far bigger than planned. The ‘shopping list’ approach also limits the benefits of the application by trying to design end-to-end based on the current state, instead of an unknown future state and new possibilities and goals.
Any application project will come with a thousand wants, but the real challenge is in articulating those wants into a concept that’s plausible and tangible, and allowing it to grow from there. Aiming for an MVP to start with allows the business to morph the application around the latest business strategies and ultimately take advantage of the lessons learned in the process.
Learning 3: A Business Application Must Be Fit-For-Purpose
End users can sometimes be surprised at how business applications look and operate in comparison to the apps on their phone. The simple reason for this is that business applications must be fit-for-purpose – designed in a way that suits the most important business needs first. For example, an application that requires users to collect a lot of data quickly (like our emergency services Patient Care Solution) may have a UI with lots of fields and boxes for fast input. In such cases we use the latest UX standards in placement and navigation, similar to the commercial apps that most users will be familiar with. This ultimately helps with user adoption. Not always the most stylish option but definitely the most user friendly for the use case.
The technical literacy of the end users is also important here. If your end users have varying levels of exposure to business IT systems, simplicity is essential. We recently delivered an application for The Clontarf Foundation where the simplicity of the solution resulted in a huge uptake with minimal training and change management. This was successful because the users are not slaves to the application – it enables them to capture data quickly, while keeping the focus on their primary role. Organisationally having visibility of this data is driving new strategies and allowing Clontarf to further support their students.
Business applications also tend to involve heavier use, integrate with more systems, work with more data, and are generally far more complex than consumer phone apps. All of these factors (as well as budget) need to be considered in the overall application architecture and design which may impact the UI and user experience (UX) of the solution.
Learning 4: Consider your Whole Ecosystem, and Balance Standardisation with Customisation
Standardised, well integrated SaaS solutions are now a very viable option for many business needs. Of course every business is different so there will be use cases where the out-of-the-box solution won’t meet your needs. The challenge comes in how you decide what to take from the market (best of breed) and what you should consider building yourself.
From experience, a strategy that works well is to find which areas of your business that are truly unique and drive competitive advantage. This is where a custom application can substantially add value, while standardising the rest of your non-differentiating processes with out-of-the-box solutions. This ecosystem approach depends on really solid integration, but it allows your time and financial investment to go where it can drive the most value.
It’s also important to remember that a custom application doesn’t need to be everything to everyone. Indeed, size and complexity don’t necessarily increase with the value to the organisation (see our SES mobile solution, which is simple but enables broader processes and serves its custom purpose extremely well). Aligning application strategy to business needs ensures a high return on investment.
Learning 5: Don’t Skim Over the Non-Functionals
The non-functional features of an application such as security, performance, availability, scalability and accessibility are just as important to the success of an application as UI/UX design. However because these non-functional requirements (NFRs) don’t deliver immediate tangible value there is sometimes a temptation to skim over or de-prioritise these areas of the solution, especially where there are time and budget constraints.
In our experience issues that arise from non-functionals are expensive to fix retrospectively and can cause the most significant roadblocks to widespread adoption of the application. For example, poor architecture of data movement can impact application performance – you can have the best application in the world but if it takes too long to load users won’t use it. Taking the time to focus and align non-functional requirements to the business use case and objectives during the design phase will save a lot of issues in the long run.
Not sure what else to consider for your application? Download a Checklist for Non-Functional Requirements below:
