How to Ensure Long-Term Success for Your Custom Application - Inverse-Square
17023
post-template-default,single,single-post,postid-17023,single-format-standard,ajax_updown_fade,page_not_loaded,,qode-content-sidebar-responsive,qode-child-theme-ver-1.0.0,qode-theme-ver-12.0.1,qode-theme-bridge,wpb-js-composer js-comp-ver-5.5.5,vc_responsive

How to Ensure Long-Term Success for Your Custom Application

custom application

How to Ensure Long-Term Success for Your Custom Application

In the process of building a custom application, most people think about the design and build phase. In these phases, your team is filled with expectations for how it will perform, impact their workload, customer satisfaction and business objectives. How do you ensure a smooth transition and long-term success? After all, the end of the application build is only the beginning of its use.

It’s rare that an application or process needs no support once it becomes essential to the business. As business and customer needs evolve, it’s important to have a plan for software support and enhancements to meet those needs. If you want to understand the entire lifecycle of a custom application before diving in, you need to read this piece before you get to the design phase. Or, at the very least, read it at the beginning of the build phase so you know what to expect when your application is built.

In this post, we’ll cover common blind spots that can trigger issues for your new application, and support considerations to make your investment a profitable one for years to come.

Beware of the Grey Zone

As custom software developers, we can’t stress enough the importance of clear requirements, a well-thought-out plan and contract from the get-go — not just to ensure a smooth build, but also to ensure a stress- and error-free launch after your custom app is installed.

When that doesn’t happen, applications can feel incomplete, even after built and installed, falling into a “grey zone” where different people interpret requirements differently. Unfortunately, grey zones tend to stay in the dark during the build process, only coming to light when requirements are turned into the actual product.

Vague or subjective feedback on final application aesthetics can also feed into the grey zone, adding friction and discontent:

“It’s not blue enough.”

“Why aren’t the buttons more round?”

“I thought the columns on the report would be wider.”

“I don’t like that font.”

Or, we might discover previously undiscussed workflow issues:

“Every time X happens I have to run this report and mail it to Susan. Can we make the app do so automatically?”

“I thought the app would magically do this [manual task not mentioned until now] for me.”

Generally, these client requests are reasonable, but outside the initial scope of the engagement. The more clarity you provide during the requirements gathering stage, the less risk we have of miscommunication and misaligned expectations. To that end, a functioning wireframe is imperative to demonstrate how the completed application will look and behave, long before we get there.

Your software development firm should make every effort to prevent grey zones and unpleasant surprises, and you should be aware of the potential pains that follow a lack of clarity.

Warranty: What’s included in my contract?

Warranty refers to support for anything not functioning as it should. For instance, the requirement spec says the application should do X, but that’s not happening. When performance is already established, warranty ensures that performance is maintained for a defined period*.

Note that warranty may not cover bugs, however. Although rare, bugs may trigger unexpected scenarios. An aspect of the application may work fine, for example, until someone tries to order a negative quantity of an item, or schedule an event to last 72 hours when the system was programmed to cap events at 4 hours.

These bugs are harder to cover under warranty, and are generally caused by grey zone requirements. If you encounter a bug, talk with your custom software developer to determine if it falls under warranty or enhancements.

*Please note that most shops, including ours, do not have a warranty that lasts the lifetime of the application. Work with your custom software firm to determine how long the warranty will be.

Custom Application Warranty and Support

What kind of support will I need?

Support refers to assistance with an immediate need related to your custom application.

Support requests concerning data are the most common: Often a user has done something they wished they hadn’t, like delete a bunch of records, or there’s a need for a one-off report. It’s easier to gather your custom software developers for a few hours to manipulate the database than it is to attempt to manually compile numbers for days on end.

Other needs that typically fall under support include:

  • Keeping up with new technology, such as the way your app integrates with other systems.
  • Staying compliant with new security measures.
  • Scalability, particularly as the number of users or records multiply dramatically.
  • Database changes.

 

Think of software support as your car maintenance: It’s mostly painless and pretty affordable when done regularly. Left unchecked, it could leave you stranded on the side of the road, your family vacation ruined, a high-dollar price tag and many wasted hours, to boot.

Maintenance should be part of early discussions with your development firm, so you understand what’s important for long-term performance, and what to budget for.

Why would a brand new application need enhancements?

This is an understandable and frequent question. To be clear, enhancements typically refer to new functionality.

Often, certain application features are discussed during the design phase, but left to be implemented in later versions of the application due to budgetary constraints. It’s important to have an enhancement plan outlining features, rough time frames and estimates so everyone knows what’s ahead.

In addition to wish list features, we should acknowledge that business needs, customer expectations, and online dynamics all change quickly. If you’ve managed operations via Excel sheets, for example, imagine how often you’d make changes to the structure of your Excel tracking: Bimonthly? Quarterly? Biannually? That’s because your business processes (or your understanding of those processes) never stop evolving.

 

Likewise, anticipate changes for your custom software. After all, your software should be a competitive advantage, not a hindrance to daily operations. The best way to ensure that is to create an enhancements plan that allows you to be proactive as well as react quickly to new business needs.

Enhancement examples include:

  • A new column or data in a report.
  • A new step in the workflow.
  • Automating a manual task.
  • Adding a new capability or function.

What’s the cost?

 Like estimating the cost of a house, support and enhancement costs hinge largely on the nature of your requests.

Support requests tend to be issues that no one anticipates, and are handled as needed. Any time a support request becomes a regular request, it can evolve into a potential enhancement.

Enhancement costs are largely controlled by your business. You set the pace for how aggressively you want to improve processes and the supporting infrastructure. We’ve had clients apply as little as 20% of the build cost to an annual enhancement plan, while others exceed the original build cost in additions and iterations. The pace and budget are yours to set.

However you choose to proceed, Inverse-Square can assist as your development partner. Don’t hesitate to ask for guidance or clarification — it’s our pleasure to help and save you from poor choices that could cost you double in the long run.



Want to develop your custom software with Team Awesome? Request a consultation with us today.