Autogrowth, shrink and database performance
Yes, picking an autogrowth size that makes sure you minimize or eliminate the number of growth events during your business cycle is ideal. I would venture to say that if 300 MB per month is that predictable, you should also - in addition to setting more reasonable autogrowth settings - to grow the file right now by 4 or 8 GB to allow for one or two years of growth without having to worry about interruptive growth events (even with instant file initialization, data file growths still cause transactions to wait while they complete). If you know you're going to grow by about 300 MB per month, why put off all those growth events? What are you going to do with the space in the meantime? Lease it out month-to-month?
You are probably fine shrinking that specific database to 200 MB. Be sure to do this with DBCC SHRINKFILE or ALTER DATABASE MODIFY FILE, not DBCC SHRINKDATABASE.
The Express limitation is on the data file only. You can have a 9.99 GB data file and a 600 GB log file, and SQL Server won't complain. Well, it will in other ways, but not due to exceeding any arbitrary file size limitation. That said, you should either make sure to be in simple recovery or back up your log at a reasonable rate. Log files should never be growing uncontrolled - and if you're worried about the log file on an Express instance, something isn't right. Please see the following posts for plenty of discussion:


SHRINKFILE best practices and experience
Sql Server - Best Practices for Growing Database Files
Why Does the Transaction Log Keep Growing or Run Out of Space?