We are ... responsible for testing a bunch of new ideas.
Then you need to focus on the Minimum Viable Product. Fundamentally, I agree with B: getting early feedback and iterating is going to give you a stronger resulting product, from the users' perspective. That doesn't mean shoddy engineering, but it does mean leaning heavily on YAGNI, and certainly means that spending a lot of time on up-front design is a bad idea. A is likely to find this frustrating at first, but hopefully as they see the product grow to fit the users they will see the value.
Look at it this way: A is worried you'll have to re-work things. But whichever path you follow you will end up rebuilding stuff, because it was unpopular with the users or a new requirement incompatible with the previous approach came up. If you've spent weeks designing the perfect solution to the old problem this is hugely frustrating; if you've only spent days on it, not so much. The Pragmatic Programmer talks about tracer bullets, getting live feedback on how close you are to the target (particularly valuable with a moving target, or one where you aren't yet sure where it is).
Also think about what happens to anything that becomes successful. If you're the skunkworks, and something proves useful, does it get taken out of your hands and given to someone else? Are you actually providing value to the broader organisation by creating a polished product, or would everyone be better off if your team demonstrated the core value of the product and let the team that takes it on build on it or reengineer as they see fit? They may be happier with a bunch of useful customer information, a working prototype and some end to end tests around the core features that they can reuse when rebuilding it their way.
So what can you do about it? Firstly, be clear on what the team's goals are, how success of the team and their products will be measured. If you've got a lot of new ideas to try out with a small team and short timescales, you cannot make everything perfectly (if you can even figure out what "perfectly" is, but that's a whole other answer), so be clear about whether they should prioritise building fewer to a higher standard or more to a lower one. Help them make the technical decisions you can't by providing them a framework in which to measure and compare the outcomes.
Secondly encourage the two of them to collaborate closely, or even pair program. I've found pairing with other engineers with different tendencies to be a good way to find a positive balance between our strengths and weaknesses; B can encourage A to see the value in early feedback and discourage their tendencies to gold plate, while A can use their inclination to thinking about the bigger picture to head off any "dead end" decisions that will work against the team's ability to keep developing the app as new requirements come in.