Well keeping it small and simple is definitely the way to go at this stage, and probably the reason why this looks like a complete, if limited, game. Rather than an open pandora's box that has been spilled all over the floor ^.^
One piece of advice I would give you is, try to get the most mileage out of your code. Basically, instead of writing a function to have an enemy shoot one bullet in one direction, write the function so that the enemy can shoot any number of bullets, of any type, in any direction. Having this type of philosophy from the start will usually not add a huge amount of time to your code writing process, while saving you a LOT of time and headaches later on when you want to add variety to the gameplay. Even if you think something can be hard-coded now, down the road you could change your mind and find yourself going back and refactoring things that could have been more open-ended from the start.
I try to catch myself doing the hard-code thing, because it is easy to slip into this habit in the initial stages of development, when you are basically prototyping and just want to slap things together and get it running as fast as possible. And sometimes it is helpful to just quickly scratch something out and see if it works... however, I have found that promptly changing those hard-coded behaviors into more generalized ones really improves on the "iteration" process later on, when you want to be focusing on creating actual content rather than rewriting functions.