Published in


Updating a legacy app — why it’ll cost more than you expect

Google have announced that from August they will only accept app submissions to the Play Store in their preferred Android App Bundle (AAB) format. There are some brilliant reasons for Google moving away from APKs and towards the new Android App Bundles. However, this news has got the app world buzzing because it’s new. And different. And no-one likes change!

What it does highlight is that Google (and Apple) will sometimes change the requirements they have for apps to appear on their store. Or make changes to functions like their billing API. Or to encourage developers to support new OS updates. Why? Well because these changes will ultimately benefit and protect the end customer.

The downside for anyone who has built an app, is that these changes often require new development. Which isn’t much of a problem for massive consumer companies with huge development teams. Or even midlist apps and games who’ll have their own in house development team or an app agency supporting their apps.

Where this change really bites is for the small niche apps, particularly those B2B apps that have been built and maintained over long periods of time, with little to no need for features to be added or major upgrades to be made. These tiny apps help drive forward a much larger ecosystem, and when a change is made, it can often have a dramatic impact on these B2B products.

Because the developer who built it has often left the business. Or the agency that built it have merged into another company and completely forgotten about you. Or the management team simply can’t remember who built the app all those years ago.

That’s when our phone starts ringing. With people asking for help.

We’ve built a bit of a reputation for being able to swoop in and save apps from the scrap heap or turn around doomed app projects. And because we keep our ears to the ground, we usually know about the changes coming down the track and are prepared to leap into action and make the necessary changes. Well… most of the time anyway.

Unfortunately, updating a legacy app is not always as straightforward as you might expect. Which means that sometimes the process gets pricey.

Updating a legacy app is like repair or rebuild a car

This is the type of analogy I use from time to time. When a client asks us how much it will cost to update their app, I’ll compare it to rebuilding a car. It could be a quick, cheap win. Or it could be costly, requiring a chunky piece of investment. Sometimes it’ll actually be cheaper to just buy a new car. Here’s why…

It depends on the car

Photo by Peri Stojnic on Unsplash

If you want to rebuild a 1990 Ford Fiesta then you’re in luck. Cheap parts are out there — you can scavenge around on ebay, or if the worst comes to the worst, you could buy a couple of second hand cars and strip them right back for parts. Alternatively there will be non-spec parts that will probably do. They won’t cost you an arm and a leg to overhaul, and won’t take too long to do. In app terms that’s usually a pretty simple job. Nothing spectacular. It’s a simple app, with well written, relatively up-to-date code. Ideally you can put us in touch with the original developers, or at the very least have access to all their original documentation. You have your signing key. You’re not looking to redesign the UI or add features. It’ll still cost you time and money but we can do it.

Photo by Stephan Louis on Unsplash

If you want to rebuild a 2015 VW Golf then you’ll be similarly blessed with easily accessible parts, spares or at the very least handy second hand cars to strip. But this is where the cost/value proposition starts to rear its head. This is a car that you can pick up easily on the second hand market. Why do you need to rebuild this particular car. Unless it has real sentimental value like… I dunno… your first born son is named VeeDub Golf Jones then you’re better off going out and buying a second hand replacement. Or even a brand new Golf.

We often see this in app development circles. And it is usually when a developer, or development agency has left the client high and dry. Sometimes the development team were rubbish or a disastrous mixture of off-shored development hubs that built a god-awful product. These are pricey jobs. Sometimes it is fixable. But your new app agency will need to unpick a load of old code and it takes time. And we all know what time equals. In about 70% of these cases it’s pretty much cheaper to bin your old app and start again.

Photo by Eric & Niklas on Unsplash

If you want to rebuild a Ferrari 250 TR then things really start to get complicated. When one of these bad boys goes for a cool £16 million you know that any rebuild job is going to be costly. These are the ultimate collectors item. And they are older and rarer than any of the other vehicles we’ve been looking at. That means everything from the badges to the steering wheel, dashboard to the brake pedal is collectible. AKA expensive. It’s also tougher to find construction manuals and you’re going to be machining your own parts. It is possible. But it isn’t practically possible.

Defining this as an app is difficult because, just like the vehicle, they are rare. It’d be like being asked to rebuild Facebook, Whatsapp, Instagram and whatever other brands sit in that massive silo all at once. Without any of the original code. Or documentation. With only a calculator to work on. And a pony. It’s pretty much impossible. When we see this, it is usually with Enterprise level products with a diverse feature set that has grown and bloated up over years. Often the client doesn’t even have decent insights into what their most important features are, so they can’t prioritise the work, or need everything launched in one big bang. My business accountant would love us to take it on. My developers would hate me for the next 18 months or until they got so fed up they’d walk.

It depends on the problem

Photo by Tachina Lee on Unsplash

With car rebuilds or repairs, sometimes the bulk of the vehicle is sound… and all that is needed is a bit of TLC and a few small repairs.

Fixing a broken headlamp is a quick job. Repairing an exhaust or a suspension coil is going to take time and money… sure. Replacing the entire engine or a gearbox… hmm that’s really gonna cost you.

The same goes for apps.

If the app is really old and decrepit it will need some serious refactoring to make it secure. It’ll need work to handle new OS requirements or to scale up the load it can carry. Then you’re looking at fitting a new exhaust and changing the tyres. It’s going to be pricey, but it will keep your car running.

If the app is a bloated, out of date mess with an archaic UI that needs to be overhauled, with out of date permissions and huge security flaws then you’re getting back to that tricky point where replacing the entire engine block (and the time that will take) begs the question — “Should we just start all over again?”

It depends on the driver

Photo by Amir Hosseini on Unsplash

I’ve touched on this a few times, both in this post and in some of my older musings. Sometimes the cost of overhauling a car will depend on the driver.

Have you treated the car well? Kept it in decent nick? Maintained it regularly? Got maintenance records? Managed to stay in touch with the team that previous maintained the vehicle? Or have you simply come to us to get a quote to knock down the price your usual garage have quoted? Defaulted on a payment for goods or services? Pissed off your previous mechanic?

These things can all have an impact on price.

We get very nervous taking on jobs where we suspect the client has had a major falling out with their previous developers. Sometimes this is the fault of the developers. We’ve heard stories of app development agencies absolutely rinsing the price of updating an app because they have their client over a barrel. No maintenance costs or day rates were ever signed off on in the initial contract so the rogue agency is going to try to milk the client dry.

We try our best to help out in those situations and keep costs down but it can be tricky sometimes. However, where we think that the client was the problem we start to build our defences. Developers do talk to each other you know. And we do our homework. If it turns out you were a nightmare client or even worse a client that pays late (or never), expect us to hike up our fees. And demand payment upfront.

So whether your app is an old, clapped out jalopy or a fresh out the box roadster with a dozen miles on the clock, it will cost money to fix it or update it. How much depends on the app, the client and the amount of work needed. Just like fixing up a car.

Thom Gibbons is CEO of Apptaura. He might have had a little fender bender last week, which is why he is obsessed with the cost of repairing cars right about now. If you’ve got an app that you’d like updated, why not grab a 30 minute chat with him and he might be able to help you out.




Everything connected with Tech & Code. Follow to join our 900K+ monthly readers

Recommended from Medium

Bandit(OTW): Level 19->20

It’s Back! A Trend To Build Monolith

Metaprogramming With Ruby: Send and Public Send Methods

Woman typing on laptop

Debugging Angular framework running inside Docker container using VS Code

Date Command In Linux

Building a scalable webhook delivery system using Kafka, SQS & S3

READ/DOWNLOAD$% Computer Architecture: From Microprocessors to Supercomputers (The Oxford Series in…

Software Development Process — Steps, Methodologies

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Thom Gibbons

Thom Gibbons

Thom is CEO of the app development agency that wants to change our world with great code. Uniquely crazy, odd sock wearing. Aims to inspire.

More from Medium

Native vs Cross-Platform Development

Goroutine, They are simpler than you think!(Part 1)

How to avoid IP rights traps in software development?

Some needed 20/20 hindsight on the chaotic disclosure of Log4Shell