Bespoke Brilliance
Lessons on building high-quality custom apps that drive customer success and value
Building a program or web app to solve a problem or provide a service is an incredibly popular thing to do - it allows a business to run more smoothly, using something that’s custom tailored for them to be smooth, simple, and unified. But the path there can be fraught with pitfalls. This post will go over some of those pitfalls and talk about what to focus on to delight the customer. This post is mainly focused on process - there will be a more technical engineer/developer focused post at a later date.
First, it helps to understand that a lot of times this is a customer’s first time having an application built FOR THEM instead of using an off-the-shelf solution. They may be a little unsure, and more than a little wary. After all, depending on the size and number of features in the app, the app might be expensive to build. If their need is severe enough it can even be a make it or break it moment for their business. This means that the customer is putting a lot of trust in the app developers, and the development team needs to be worthy of that trust. This leads us to our first maxims:
Strive to understand the customer’s business as well as they do
Drive both you and your customer to have a continually deeper understanding of the problems you are trying to solve
The rationale for the first point is pretty obvious - the better the development team understands how the customer does business, the better your discovery and requirements process will go. There will be less surprises later in the project, and less edge cases that come out of the woodwork as the project develops. At the beginning of the project, the client knows their business but not how to translate that into a working application. The development team knows how to build a working application, but doesn’t know what it needs to do. At KVA, our goal is to close that gap. If we “get” our customer’s business and processes, then we can better inform them on possible technical solutions, and eventually build those solutions. Likewise, if a customer can understand just a little bit of how applications work, then they might be able to see potential problems with proposed designs before they arise, when they are easier to fix.
That dovetails neatly into the second point, which is that you need to drive a deeper understanding of the specific problems you are solving. In our first maxim we became generalists in our client’s business, here we become specialists in their problems. It’s not enough to know that, for example, a trucking company needs a unified way to track incoming loads. You need to know how they get their loads now. Maybe 80% of them come in via a standardized electronic format, but 15% are faxed in and are customer specific in format, and of course there’s that one customer that just calls the clients office and tells your office people what they want over the phone. Maybe some loads are shipped in the client’s trailers and some are shipped in their customer’s trailers, and those need to be handled differently. I could go on, but hopefully the point is obvious. It also leads us to our next maxims:
Deliver and iterate on small vertical slices of functionality
Keep the customer involved in your iterations
One big advantage of custom app development, especially web apps, is that deployment of new code is fast and easy. At KVA, we focus on getting things in our customer’s hands as soon as we can. It doesn’t have to be in production, using test data is fine, but we want to get our new work in our client’s hands as soon as we have a fully working component, so that they can touch it and feel it and tell us what they like, don’t like, have questions about, and so on. Even the best designs that you and the client agreed on sometimes don’t survive contact with reality. Maybe a process feels intuitive when they are actually using it, or maybe there’s a piece of data missing that they have to go back a page to find and it’s really awkward. The sooner you can find our which one, the easier it is to go back and make any needed changes. And hey, if there aren’t any needed changes, it always feels nice to nail it on the first go around.
One final note on iterating with the customer is that it’s really important that 1) the people at the customer providing feedback are the people who are going to end up using the app, and 2) that we as the development team are respectful of and appreciative of those users time. The people who are going to be using the app are busy, and asking them to run through a test process on the app puts even more on their plate. It’s exceptionally valuable, but it means that we hold our development team to a high standard of initial quality, so that the customer’s time going through the app testing is spent on reporting valuable feedback, not just encountering a bunch of broken things that got missed.
There is one final piece we haven’t covered - taking your app from development to production. If app building process has followed the principles above, you’ve hopefully eventually gotten to an application that you and your client mutually agree is “ready to go”. But you are not done yet. A last maxim:
We finish the job
There’s always something. Hopefully only small somethings, but there will be something that is broken, a bit off, or just not quite what the client wanted. This can be for many reasons. Sometimes it’s a misunderstanding, sometimes it’s because despite you and the client both liking a specific piece during testing it just doesn’t feel as smooth or obvious as they want when they’re using it every day. At KVA, we always set aside time post-launch for “hypercare”, a time where we are focused on delivering rapid fixes for any small tweaks or changes or defects that may occur. Often, we end up barely using this time. That’s always the dream. But it’s better to have it, because if the customer isn’t satisfied, the job’s not done.
