The question, as is, will be difficult to answer, because maintainability comes in many shades.
I distinguish 3 levels of maintainability:
- readable code
- avoiding repetition
- architecture/refactoring
The first level is very basic, and does not cost development time. It just means that whenever you write new code (or read older code), you make it as readable as possible, perhaps adding/tuning some comments as you go.
The second level is less basic, but not too overwhelming either. It simply means that whenever you add a piece of code, you should check if there is not already something that does what you are about to do. If there is, merge the common stuff (great, you didn't have to write!). This will avoid code repetition, which means that when fixing you won't have to propagate the fix in the n'th copies.
The third level is definitely costlier. Architectural changes and refactoring on a large scale quickly eat up a few days of work.
With this list in mind, it's a bit more manageable to discuss.
- if you are in a hurry, just apply 1. and 2. and don't overconcern yourself with the architecture (unless you don't have one of course, in which case just create the simplest one that'll solve the problem)
- when you have a few spare days, or when you are not under pressure, consider refactoring if possible
In order to enable the second, I tend to maintain a TODO list of what I'd like to change but that I don't have the time to do right now. Then when I have some time on my hands, or when the opportunity arise to work on a piece of code that appear on this list and I can squeeze a few days of maintainenance, I just proceed.