So you’ve made the decision to build your own software (on your own, or with the help of a partner like CCQ) and the world of possibilities stretches endlessly before you. You know that there are a million and one problems you’d like to solve and you want to get to them all, but right now you can’t. In a world of finite resources, you will by necessity need to pick where you should be focusing your effort, and that’s not always an easy call.

We first started working with Choice Vehicle Rentals (Choice) with a simple brief - replace their existing paper pre-hire forms with an automated system. A self-contained piece of development that immediately started adding value and getting customers into cars and out the door faster than ever. Spurred on by success, Choice realised how much more opportunity there was for their whole business in custom software development. Together we set out on our journey to develop a Vehicle Rental Management (VRM) system which tracks bookings, payments, inventory and daily workflows.

At first it was clear we needed to do a bit of everything. We needed a complete system that could meet all their most basic needs end-to-end; a full MVP. But with that initial release out the door and functioning well, we needed to start deciding what to prioritise, what should rise to the top of the backlog, and what could be put off for ‘day 2’.

At CCQ Tech, we pride ourselves on our ability to help our customers decide what is the most important thing to be building right now. Below, we run through a few archetypal examples of the sorts of things we made the decision to work on with Choice, and why we picked them up when we did.

The Flagship Feature

This is the thing that you really want to build. A change that brings about a difference to users in terms of productivity and capability. The software product sees a surge in approval rating and usage. It might be work, but everyone will feel the benefit.

When we first delivered our VRM software to Choice, we changed the way they work by introducing a robust workflow system to their daily jobs (cleaning cars, readying them for hire, checking in customers, etc.). This worked great to help them keep on top of their priorities and get cars out the door and away, but wasn’t quite a complete solution. When the team were down the bottom of the yard working on a car, they couldn’t rely on the office wi-fi, and suddenly they had no way to interact with the platform. It was fundamentally failing to match the way that they worked.

This was a problem that needed fixing - our software wasn’t delivering as much value as it could, and was introducing friction into our users’ work. As such, we set to work developing the necessary functionality to enable offline working. It was a big job, but we enhanced our job management system to allow users to sync their upcoming tasks while they had a stable connection, and then complete them offline, before ultimately reconnecting to the internet and pushing up their changes. It considers all the sorts of jobs they might be doing, and all their component parts, to make sure it syncs the most important items first and keeps things running smoothly.

This is a piece of work that needed doing, and that delivered huge value to our users when it went live. It enabled our software to match the ways that they work, and maximised the value gains we could deliver. It took us some time and effort to put it together, but that paid off very quickly once we got it out the door, and not only improved our users' experiences with the platform, but their view of it overall; they could see that we were focused on delivering the functionality that mattered to them.

The Boring but Necessary

Sometimes, however, the thing that needs doing isn’t quite so glamorous. As software developers working in the era of AI, we always want to be moving quickly, getting an MVP out the door and moving onto the next big thing, but that often means compromises. There’s nothing wrong with making the conscious decision to do things the easy way the first time around (and in fact, if you’re not making that decision, you’re probably missing out on a lot of opportunities), but eventually that technical debt is going to catch up to you, and you’ll need to pay the piper.

When we first built the system within VRM to calculate charges and track payments, we didn’t yet have a complete picture of what we’d need it to do, but we also acknowledged that having at least some version of it in place was necessary for us to release anything at all. To that end, we built as little as we could get away with. We kept things lean and simple to prioritise getting the software into the hands of our users so we could see what else we needed to work on.

As the system has grown, however, and as we look to expand to more rental companies with more end customers, that original system is starting to reach its limits. We’re looking to build more robust, more powerful systems, but we need a more powerful baseline to be able to do that. And so, we’re rebuilding and extending that system. This is a big, fiddly job. It’s going to take us some time, it’s going to be a pain to test, and at the end of the day, it’s really not that glamorous. But by putting in the time now and building it right, we open up so many avenues for future developments, to maximise the value we deliver to our users, give them great new features, and ensure that we can keep extending into the future.

Sometimes the thing you need to build is the thing you’ve been putting off, and that’s okay. It was the right decision to take the efficient route the first time and get something out to our users that we could iterate on. But by making sure we keep track of where we know there’s more work to be done, we can also make the right decision now to go back, tighten things up, and make sure that we’re not causing ourselves even more pain later. CCQ will cover this topic many times more over the coming months and years. It's worth reading about how SONOS wiped $500M off their valuation after a disastrous launch of a new update.

Ultimately, if you’re not accruing any technical debt, you’re probably not making a lot of progress, but it’s essential you know where that debt is, keep it within reasonable bounds, and fix it when it crosses the tipping point.

The Quick Win

Sometimes, however, the thing you should build is the thing that nobody had even asked for…

Our users were struggling with attaching photos on the platform, and this is something they have to do a lot. Whenever a customer checks in, they need to get pictures of their driving licence and make sure it’s attached to the booking, but this isn’t easy to do on a desktop computer. Therefore, they asked us, quite reasonably, if we could possibly build an integration with their office scanners to help remove the friction.

We could do that, of course, but my immediate thought was “I’ve set up a home printer before, and that sucks. Now you want me to integrate a SaaS platform with unknown hardware and make sure that it works for future users?”. This would be a huge job. It would be fragile and finicky, and while the value it would provide is clear, could it ever really be worth the cost?

The question we asked then is “what is the real problem we’re trying to solve, and how should we solve it?”. The difficulty lay in uploading pictures, but this was constrained solely to the office workers scanning documents; the folks in the yard were uploading hundreds of pictures a day of cars to the vehicle records without any complaints - what was so different?

The difference, as it turns out, was that in the yard their work was being done on phones with built-in cameras, while our office workers were on PCs. Uploading an image from a smartphone is dead easy, so was there a way we could share that experience with our office workers? 

It didn’t take long for us to realise that, of course, there was. We could just have them open that booking on their phone, snap a photo of the driving licence and upload it straightaway. All we needed to do was make it easy to navigate to the same page they were already on on their PC from their phone, and with a QR code, that’s pretty easy. 

Within about an hour, the feature had been developed. We gave our users a button they could click, which would open a dialog with a QR code to navigate to the same page they were already on. Then they could just scan that from their phone, take a picture, and job’s a good’un. What could easily have been weeks of work was avoided and we were able to deliver almost exactly the same benefits to our users. That one hour of our time saved the office multiple minutes on every booking and those add up quickly.

It’s not always the first or most obvious solution that is the best way to solve a problem. If you always take the time to step back a bit and abstract your requirements, sometimes there’s something hiding just out of sight that can do what you need. And if you can knock it out in an afternoon and deliver an absolute game-changer for your users, then that is always going to be worth it.

Summary

We get it, you want it all, and you want it now. There’s value to be had all over the place just waiting to be realised, but it all takes time, and figuring out exactly where the sweet spot of cost vs benefit is can be tricky. You need to consider how much you’re really benefiting your users, how easy something is going to be, how maintainable it will be in the future, and even the opportunity cost of not developing all the other things you could be developing instead.

At CCQ Tech, we pride ourselves on our careful and considered approach. We’re always asking the right questions to make sure that the thing that we’re working on is the right thing for now, and for the long term, and by doing so, we help make sure our customers get the best possible returns on their investments. If you’d like to have a chat with us to see how we think we could best help you, then why not reach out? We’d love to talk!