3 Critical Items Everyone Forgets When Building New Software

It’s been well-established at this point: software, when executed properly from end-to-end, can have transformative impact on businesses.

From introducing entire new revenue streams (like we did for the Kunitz Shoes eCommerce platform), to saving hundreds of thousands of dollars a year, to digitizing and automating entire workflows like our work for Alberta’s voter registration process, there is no denying the enormous potential outcomes of applied technology. That’s why you can’t escape articles about digital transformation and why Silicon Valley tech startups attract some of the biggest seed rounds in the VC game.

And of course, the impact of a web app or mobile app is reliant on the execution of the product. Its success depends on a variety of critical steps on the journey: early alignment of invested parties; choosing the proper features for inclusion; figuring out the prospective business outcomes from KPIs; and ensuring proper application security post-launch, just to name a few.

And executing on software is hard work that can take months – even years.

With that in mind, it makes sense that so much of our collective attention and effort goes to these stages of software. Most of the potential clients that come to us with a new development project have a good grasp on these core pieces of the application development cycle – rough requirements lists, ideal launch dates, a general vision for the end product in their mind. We’ve found prospective clients are hyper-focused, before and after signing on with us, specifically on the design and build. You know, the execution side of their project.

But the problem is, they’re forgetting 3 critical keys to success. Without planning for these 3 items, those big potential outcomes you’re hoping for – like the ones I mentioned above – will be that much harder to reach.

3 Frequently Forgotten Keys to Successful Software

Yes, the execution of the software is paramount, but it’s not all that matters. The 3 pieces of the puzzle that are as influential to the product’s success as its execution are:

1. Gaining user adoption
2. Understanding and managing ongoing costs, and
3. Expecting and handling edge cases, bugs and tweaks.

If you want your digital product to be successful, regardless of what it is, you need to understand these areas.

Let’s break them down.

1. User Adoption

TL;DR: What is your plan for getting users for your software?

I like to use a house party as an analogy for user adoption. Let’s say we’ve spent months planning this house party. We even built a whole new house for it, specifically designed for good times. Countless weeks have gone into planning, design & build, project management, valuable interior design flourishes and touches – the place is perfect.

Beautifully executed, as it were.

We select a party date and work diligently towards it. When that day comes, though, all we do is send out a couple of tweets and an email invite to a handful of friends. Barely anyone shows up. Those that do don’t stick around very long – we quickly realize we didn’t have a plan to encourage them to stay.

Our house party ends up being expensive, ill-attended, and flames out quickly.

Unfortunately, this is often how new software gets rolled out. We spend all our time on the build, and neglect the whole “getting people to show up and stick around” part.

The long and short of it is this: you can’t launch your new app with a few tweets and expect huge growth or adoption. But frequently, those in the driver’s seat of the software just expect that to happen.

There needs to be a strategy, and effort, put into gaining traction. Often, that effort (and cost) ends up being as much or more than the whole build itself, and can be less predictable than the development cycle.

User Adoption Applies to Internal Software Rollouts, Too

This point seems obvious for new end consumer software, but applies equally to custom software for internal use as well. If you’re launching new estimation software across your 5,000 person organization, how will you ensure internal teams know about it, try it, and make it a consistent part of their work day? For example, I know a large waste management company spent upwards of $500,000 on an internal campaign to get their employees to be aware of, and use, new software they rolled out.

So, what is your strategy for gaining and keeping users? Internal campaign? PPC? Multi-pronged marketing campaign?

How will you pay for it? Have you factored any campaigns, ad spend, or overall acquisition cost into your first 12-18 months post-launch?

Lastly, who is going to be the point person for this? Who is going to own it?

In our experience, the answers to these questions range pretty widely. We’ve partnered, along with our clients, with marketing agencies who specialize in new product campaigns to form a trifecta of expertise; we’ve had clients who have internal teams dedicated to the task of user adoption; and we’ve had bootstrappers DIY it.

Your answer is dependent on your organization, and we can help you figure out what’s feasible – but the one unassailable truth is that a strategy for user adoption can’t be ignored.

2. Understanding and Managing Ongoing Software Costs

TL;DR: Your software is like a house – it has recurring costs, from maintenance to repairs to updates.

Often, clients come to us with a budget for the build of their software – and that’s it. If they do have the knowledge that recurring costs are a reality of software, that knowledge is usually paired with questions around what those costs are going to be. This is the second critical key to success: understanding and managing your ongoing software costs.

Recurring costs come in all sorts of shapes and sizes. Generally speaking, they can be grouped into the following categories:

1. Infrastructure costs (servers, databases, additional file storage, CDNs, domains, etc.)
2. 3rd party service costs (APIs, application security-related services, monitoring and notification systems, payment gateways, etc.)
3. Maintenance costs (e.g. version upgrades, security patches, bug fixes, required or recommended OS-related updates)
4. UX and feature improvements (new features, improvements to existing workflows, UI updates, etc.)

All of these costs can be widely variable, from client to client and application to application.

Infrastructure costs grow as your user adoption grows, and are also partially dependent on how resource-intensive your application is.

3rd-party service costs are dependent on the complexity of your software, and choices made by the development team. For instance, sometimes it makes more sense to integrate a platform like Postmark for email service delivery – even with its (nominal) recurring costs – than it is to build out an email delivery tool within the software itself.

Maintenance costs are “optional” – but only if you want your software to be quickly out of date and at risk for a data breach. Basically, critical issues should be addressed immediately and routine maintenance can be scheduled in monthly – that’s what we’ve found works best, anyways. Lastly, the more complex the system, the higher the maintenance costs.

UX and feature improvement costs are, again, “optional.” But in terms of adopting and retaining users, and competing with the ever-increasing standards users have come to expect from their experiences, I’d recommend including at least a small UX and feature improvement budget. It’s the difference between spending a few bucks here and there updating a room in your house every handful of years versus all of a sudden waking up to realize you’re living in a house with shag carpets and wood panels – a house that you now need to renovate from the ground up.

So, What Should I Budget for Ongoing Software Costs?

The short answer: a good rule of thumb is to budget around 20% of the total project cost as annual recurring costs. So, if your new driver inspection software platform cost $250,000, as an example, you’d want to budget around $50,000 per year to cover the 4 categories of ongoing costs I mentioned above.

The longer answer is the typical consultant’s answer: it depends. If you have an internal team that takes over the project, then that obviously changes things. If you de-prioritize UX and feature improvements (not recommended, but you can), that lowers the cost. And, if you spend some time engineering the infrastructure for scalability (and revisit it), you can keep those costs in check too.

Typically, we provide a range of costs with a few options during Discovery so our clients know what to expect early on. Then, closer to launch, we work collaboratively to come to an agreement on an all-inclusive retainer that includes a budget for all of the above 4 categories (with varying scope, dependent on the client and the project).

This way, the client has it laid out as simply as possible – a one-stop shop for build and support post-launch – one team to call with questions, issues, bugs, and one budget that we are tasked with managing properly. I’d encourage you to look for a similar agreement with your development team.

3. Expecting and Handling Software Bugs, Edge Cases, and Tweaks

TL;DR: Your software will have bugs and areas for improvement. It will always be so. How they are caught, classified, and managed is what matters.

To put it transparently, software owners should expect the following for the entire duration of their software’s lifespan:

1. There will be bugs.
2. There will be weird things that weren’t caught in testing.
3. There will constantly be areas for improvement.
4. Users will do things you never imagined with the software – use cases it wasn’t designed to handle.

These expectations add up to the last critical item that often gets forgotten: expecting and handling edge cases, bugs, and tweaks. Edge cases and bugs are an inevitability of software – after all, when we account for new devices, OS updates, browser updates, and framework updates, there can literally be hundreds upon hundreds of changing variables every year. The outcome of these changing variables is, inevitably, bugs.

The critical part is that, as a software or product owner, you know that these things are part and parcel – they do not surprise you or catch you off-guard, as they are an expected outcome – and that the method for handling these elements is understood up front with your dev team. And lastly, per the previous point about recurring costs, budget needs to be allocated to addressing edge cases and bugs.

How Should We Handle Bugs, Edge Cases, and Tweaks?

Over the years, we’ve built a toolbox of processes and tools that work well in this regard – a similar collection will likely work for you as well.

On the issue logging side, we outline a straightforward method with our clients using our task management software of choice, Asana. We run our clients through the process, our SLA outlines expectations for response times, and we manage and report on the budget to pace it properly. When issues or requests come in, they are handled appropriately and released based on the nature of the request (e.g. critical bugs are handled ASAP, feature releases are bundled into a version release, etc).

While the nuts and bolts of logging and tackling issues is relatively straightforward, it’s important – and a little trickier – to be proactive about discovering bugs, edge cases, and tweaks. We’ve found a combination of the following works well:

1. Routine user observation (semi-annual, annual, etc.)
2. Proper proactive monitoring and notification (application performance monitoring, infrastructure monitoring, error tracking, and browser monitoring – we currently use Atatus for this), and
3. Behaviour analytics and user feedback tools (Hotjar is good)

Used together, the above three items make for a good foundation when it comes to proactive discovery. Couple these steps with the issue logging process I outlined above, and we’ve built out a solid process that helps our clients easily monitor, manage, and improve their software over time.

Users Expect Brilliant Software – and Brilliant Software is a Continuous Challenge

Think about what you expect from the software you use. I bet it’s high. The bar of expectations when it comes to the applications we use is continually raised over time, as more and more exceptional software is released, and our lives become more and more intertwined with technology.

Plainly speaking, users expect brilliant software. It is critical to understand, then, that in order to meet their expectations we can’t just deliver great software at v1.0 and expect success. We need:

• A strategy to get our application in our users hands
• A budget for maintaining and improving the software over time, and
• To expect bugs, edge cases, and tweaks, and have a rock-solid process for handling them.

Understanding and having strategies for these three elements is critical to the actual success of your software overall – so take the time to account for them in your software project strategic planning. And when you combine these pieces with exceptional software execution, you’ve covered the bases you need to and are on the right path.