I've spent tens of hours over the past few days creating a modular front-end architecture, and so have spent a lot of time thinking about application design. What I'm developing is part of a larger project with several other people, which means there's a few extra things I'm taking into account while I put my system together. First, modularity! Any project a team of people is working on must be pushed from the ground-up as separate pieces -- otherwise you're asking for merge hell and developer conflicts. Interestingly enough, the code you're writing has very little to do with this; rather, you need to coordinate with the team for clearly defined interfaces between aspects of the project. By taking a longer time creating a robust scaffold for your application, you allow some space for developers to iterate over different designs for the components. In fact, this allows you to develop independent of the other pieces! Mock up the interface and you can test and iterate over any crazy ideas you might have; should you push a bad decision into the project, the other teams can work with the partial/broken module while you refactor or rewrite the flawed section.
Along those lines, and second: Don't rush to have fast iterations over the entire project. If you've properly divided the tasks and the other teams know how to connect to your module, take a few days to get your module setup well. You can experiment and scrap code quickly against mocks of the other components. The goal here is to see what works best to build from, if you have 3 weeks to complete the project, you'll want to spend the majority of your time expanding or polishing features. Taking a week to iterate over different structures for your module means the next developer to take over or pick up a feature in your corner of the application will be able to quickly make substantial contributions. You don't want to throw code together to get the project to "MVP" in 2 days and spend every 3rd day for the rest of the project explaining how the module works or debugging those initial design decisions.
Third, spend some time documenting how your module works and how people should use it -- hell, do this first. If you can't explain with words how a developer should hop in and start adding to your module, you aren't ready to submit it to a group. Remember the first step is about giving your application good legs to stand on. If you spend the first third of the project time putting a solid foundation down, you can spend the remaining hours working upward and outward. The bonus in following this pattern is that even if you pivot wildly, or discover 2 days before shipping that some component is completely wrong for your intended platform, you can then let someone hack together a working solution without affecting the rest of the project. In fact, the other teams can continue development as normal while that module gets a frantic rewrite!
None of this precludes agile methodologies or fast iteration, it's the logical extension of them. Don't be afraid to spend some time designing the application, 2 extra days getting started can easily turn the release week from rushed and miserable to relaxed and fun.