Don't get attached to your code. Prototypes are prototypes. The first version of Synthizer's HRTF implementation was written entirely in Python with Numpy and a hacky audio library called Pyo that crashes the process if you even breathe on it wrong. I don't even have the code for it anymore. You can write versions of software with the intent that you will delete them in 2 months because they're not the real thing yet. This isn't always applicable, but if you don't know how to do the thing and if the thing is small, then doing the thing incredibly badly but as fast as you can to learn what you need to know is often more productive than trying to do it right the first time.
Don't overpromise even to yourself. Know what is going to b in the app. Plan for exactly those features and no more. If you get exactly those features then trying to add one more thing is going to need a rewrite, it's a success as long as the features it was supposed to have are there and working. It takes a great deal more experience than you probably have to manage to do that while leaving it open-ended enough to keep going, so don't try. It's fine for projects to be finished.
Deadlines won't help. Deadlines just mean you do the same amount of thinking but you're running late so now you're working 14 hour days. I guess if your problem is entirely discipline it can help with that but being under time pressure isn't going to make "I don't know what to do o no o no my code is fucked and I have to rewrite" go away.
Twitter: @ajhicks1992