If it turns out that your app is not suited for their purposes, but they didn't really have a way to realise that up-front, a refund is generally the way to go.

If it turns out that your app is not suited for their purposes, but they didn't really have a way to realise that up-front, a refund is generally the way to go. You might also have to do some extra work to accomodate them transitioning out of your service. Let's say you have a simple reminder list site. All the work you did (assertions, constraints on database tables, memory limits on the PHP process, whatever) assumed that users would have at most 200 todo items. One user has hit 800, now the website asserts out whenever he asks it to do anything, and you know that your infrastructure couldn't cope with a dramatically higher number of todos. There are long term questions to ask about the product here. But in the short term, what I would do, roughly in order of priority, is: * Do some quick queries to see if any other users will hit the same problem soon. * Temporarily tweak the app wherever possible so it works with up to 900 items. * Communicate all of this to the user. Sorry, we didn't anticipate this, if you really need that many todo items, we're not the app for you. Offer them a refund. Point out that things will work for now, but they are near the newly raised limit. * Help the user transition - "if you want to leave us, tell us when you've stopped adding new items, and we'll email all of your existing items in an Excel spreadsheet" * Fix your app so users can't create more than a few hundred items.