App Development Series: Maintenance and Support

“It’s not over till the fat lady sings. Except she’s mute!”

Even after your app is done, it’s never truly finished. As a result, neither is your relationship with your developer. Sooner or later, you’ll find something in your app that you want changed.

Your app will, invariably, still have bugs in it by the time you and your developer agree that it’s done. Not every single problem with your app needs to get fixed, and some never will be. Some bugs are small and ultimately inconsequential. And some are big and ugly (e.g. ones related to security) that must be fixed. By not doing so, you risk destroying your reputation as a trustworthy app seller.

It’s generally a good idea to make a list of bugs your app and attach priorities/severities to them. Your app developer may have a tool or process to help facilitate this, such as Jira, Trello, etc. Every bug has a cost associated with fixing it. If you know how important the problem is, and what it would cost to fix, then you’ll know whether or not it’s worth doing. Just to make it interesting, fixing one bug may cause another one. Making a change may cost you money and/or destabilize the product.

Between you and your developer, who pays to get these issues resolved? Generally, if you signed a fixed price bid with your developer, then the onus is on the developer to fix it for some period of time afterward – time usually specified in the contract. This is because you are paying for finished work in a fixed price bid.

In an hourly or hybrid bid, you weren’t paying for a finished product, you were paying them on an hourly basis. If it takes them longer to finish what you want – in this case, squash the bugs – then it’s on you to pay them for the additional time they work. If you feel like they’re charging you too much, it might be time to find a new developer.

Crucially, you need have an agreement as to how quickly certain things will get resolved. This includes clarifying whether your developer will work weekends, holidays, etc. The response time is directly tied to the issue’s severity, or the importance of the new feature.

Relationships between customers and app developers are a tricky thing. If you had a very unhappy relationship with your developer, then it’s probably time to end your contract and move on.

Conversely, if your relationship with your developer was working great, then why mess it up? As you probably know you know, finding a good app developer is a job in itself. They’ve proven themselves and you’ll know they’re in it for the long haul.

Next time: Intellectual Property

Leave a Reply

Your email address will not be published. Required fields are marked *