3 ms·

First, why did it break? Figure this out. Is it something you can prevent from happening again, or is this most likely to be a recurring thing? Whatever your

by ryanto 16y ago

First, why did it break? Figure this out. Is it something you can prevent from happening again, or is this most likely to be a recurring thing? Whatever your app is there is probably a hosting platform out there for it. One that provides a very stable environment for your application to run in, specific to your language/framework. These cost a little more money, but if it means your app not crashing once a month chances are it's well worth it. Some web hosts will guarantee certain apps to work on their servers. These hosts often have 24/7 tech support to deal with these issues. And... most of the time Google can provide you with answers a lot quicker than StackOverflow.

marcamillion 16y ago
I mean, even outside of the hosting platform. More, along the lines of say a user uses your app for a use case that you never intended/imagined and it breaks. Something that you didn't even anticipate...how do you solve that issue? I guess Googling, but it just feels kinda wrong to be taking people's money on a monthly basis and not knowing how to solve all the issues they might have with the app.
- kmort 16y ago
  I don't quite understand what you mean by "other service". It's the job of your developers or support/sustaining team to identify issues and resolve them. Debugging can certainly include asking for advice on forums, but I'd like to think that whoever deployed the component that has failed also has some idea about how to debug it (or at least where to look for help). > I guess Googling, but it just feels kinda wrong to be taking people's money on a monthly basis and not knowing how to solve all the issues they might have with the app. Adequately test your boundaries. A user may use your app for something you did not intend, but they should not technically be able to use it past boundaries you have tested, limited and clearly stated support for.
- ryanto 16y ago
  Make it clear to the user you do not support that case and then add it if there is enough interest? I am not really sure I follow, it sounds like you are having a UX/support breakdown rather than a hosting/code failure.
  - marcamillion 16y ago
    I am just having pre-launch trepidations. I am a relatively new developer, doing this by myself - so just the fact that I will be accepting money from people (while being a relatively new developer) seems a bit scary. So just trying to cover my bases.
- andrewf 16y ago
  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.
  - marcamillion 16y ago
    This is a wonderful breakdown. Makes total sense. Thanks.

by ryanto 16y ago

marcamillion 16y ago

I mean, even outside of the hosting platform. More, along the lines of say a user uses your app for a use case that you never intended/imagined and it breaks. Something that you didn't even anticipate...how do you solve that issue? I guess Googling, but it just feels kinda wrong to be taking people's money on a monthly basis and not knowing how to solve all the issues they might have with the app.

kmort 16y ago
I don't quite understand what you mean by "other service". It's the job of your developers or support/sustaining team to identify issues and resolve them. Debugging can certainly include asking for advice on forums, but I'd like to think that whoever deployed the component that has failed also has some idea about how to debug it (or at least where to look for help). > I guess Googling, but it just feels kinda wrong to be taking people's money on a monthly basis and not knowing how to solve all the issues they might have with the app. Adequately test your boundaries. A user may use your app for something you did not intend, but they should not technically be able to use it past boundaries you have tested, limited and clearly stated support for.
ryanto 16y ago
Make it clear to the user you do not support that case and then add it if there is enough interest? I am not really sure I follow, it sounds like you are having a UX/support breakdown rather than a hosting/code failure.
- marcamillion 16y ago
  I am just having pre-launch trepidations. I am a relatively new developer, doing this by myself - so just the fact that I will be accepting money from people (while being a relatively new developer) seems a bit scary. So just trying to cover my bases.
andrewf 16y ago
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.
- marcamillion 16y ago
  This is a wonderful breakdown. Makes total sense. Thanks.