Every buyer who runs your script for more than a month has changed something in it. A colour, a label, a whole template. When you ship an update they will overwrite their own work and then tell you your update broke their site.
Separate what they edit from what you ship
The single highest-value change you can make: put anything a buyer is likely to touch into files you never overwrite. A config file, a custom stylesheet, a theme or template directory. Then your update replaces core and leaves theirs alone.
Ship a config sample, not a config
Include config.sample.php and have the installer copy it if a real config does not exist. That way an update can always ship the sample without ever clobbering the live one. New keys get documented in the sample and in the changelog.
Migrate the database, do not recreate it
Ship numbered migration steps that run once and record that they ran. An update that drops and recreates a table has destroyed live data, and there is no apology big enough for that. Every schema change should be additive where it possibly can be.
Fail loudly on the wrong version
Check the environment on install and on update, and stop with a clear message rather than running half way and leaving them broken:
- Minimum language version
- Required extensions
- Whether the upgrade path from their current version is supported
Tell them how to update
An UPDATING file, three sentences long, naming which directories to replace and which to leave. Most buyers will follow it if it exists, and guess if it does not.
