When building a non-trivial application, is it best to focus on getting things working quickly, and taking shortcuts in the code like mixing model logic with your views, breaking encapsulation - typical code smells? Or, are you better off taking the time upfront to build more architecture, build it right, but running the risk that all this extra code might not be used since your design is quite fluid and you might have to throw it away if feedback causes you to go in a different direction?
For context, I'm building a desktop application. I'm the only developer, and I'm doing this part-time since I have a day job. Now, for work, I try to do things the right way, schedule permitting. But for this project, which I expect will morph as I get feedback from people, I'm not sure that's the right approach. I spent several hours this week putting in a textbook Model View Controller design in place to communicate changes in the model to the view. This is great in general, but I'm not sure if I need multiple views to display the data and I know that I could have had things displayed more quickly without the additional architecture. With maybe 10-15 hours a week to spend on the project, I feel it will take ages to get something built that I can demo if I follow good software practices. I know that my users won't care that I used MVC internally, they just want something that solve their problem. But I've also been in the situation where you've incurred so much technical debt from short cuts that the code is just incredibly difficult to maintain and add new features to. I'd love to hear how other people approach this kind of problem.