RULE 1: don't get hung up on doing it the right way:Its massively more important to be able to see the game live (with a terrible codebase that needs to be rewritten) than it is that you don't have to re-write. This is because usually, the design changes enough that re-writing was inevitable anyway.
RULE 2: do not design the game based on what you can do technically.Design the game, and demand things be tried out. Hack them in regardless of how "not quite how it should be done" it is. It's important to try out ideas before you invest too much time in them, and it's important to not avoid things because you see "doing it right" as being too difficult.
Following these rules, you quickly move from being someone who finishes well defined projects on time and on budget, to being a developer that can flesh out design ideas and mark them as "explored". That's the core difference of business and games. In games, the design document cannot be up front, and we use code to prove the design wrong, before moving on to the next iteration. We also never finish on time. (unless you are either a god of game development, or aren't actually doing something all that innovative)