I think you should leverage your skillsets in providing a functioning prototype and should select a device that already provides all the elements where your skillsets aren't at their peak. Make sure the device and supporting elements provides all of the necessary components/modules you need so that you can focus on developing your goal/solution.
Once you achieve it and are satisfied with the results and have gotten all of the necessary usage comments accounted for and feel completely at ease with the final results, then it's time to do a retrospective and nail down exactly what you need in the final product, taking into account what you've learned about power and voltage requirements, battery life, safety, etc.
Chances are, whatever it is will be a fair bit different from your prototype device. But you will be in a much better position then to work out what you need to source (or perform somehow with specialized skills you acquire or hire.)
Don't over-think where you will be at the end of the project. Focus on just getting there as quickly and as well as you can. Then look back and see the path you followed and examine what you've learned by walking it. You'll know very well what you want, then.
Sometimes, the path will result in a lot of work product that you can't afford to completely throw away what a truly narrow focus on the final product tells you that it actually needs.
For example, you might really need something so much smaller, with so many fewer functions, and so much better at managing power that if you actually sourced a unit properly sized and arranged correctly, that you'd have to use completely different development tools and be left with almost nothing of the original work except for all the much better knowledge you now have about it. It happens. In that case, you just have to make a choice and decide if you will cripple your product and protect your prior work or if you will put out a really competitive product and throw away some serious work. (The saving grace here is that at least you know exactly what you need to replicate, again.)
Don't over-think, right now. (Unless there's something you haven't mentioned, yet.) Just focus on achieving the goals. The look back and see what you need to change and hope for the best on that, but be open for serious re-work if that is appropriate.
If you haven't figured it out yet, I think you should now realize that I can't answer the question, "is there a better/easier solution?" Only you have the necessary information to even attempt an answer to that. All I can do is offer some thoughts to consider along the way.
As you become more skilled and have some experience behind you, you will be much better at anticipating and identifying project unknowns and pushing their solutions to the very front of the project cycle. This will greatly benefit the cycle by providing a GO/NO GO decision very early, where it costs a lot less to make, and it will also provide a lot more information to use if and when the decision is then made to push forward (the GO decision.) You use that time quickly and wisely to produce all of the needed information for a GO/NO GO decision as well as laying out the steps forward, when asked.
Here, it doesn't matter so much then about your initial selection of a development system. In fact, you might select a development system with full knowledge that it will not ever be used in the final product. It's instead chosen to get through those unknowns expediently and appropriately and you don't even waste a moment worrying about whether or not it will be chosen, if the GO decision is then made.
But it may also be that in some particular project "anticipating and identifying project unknowns and pushing their solutions to the very front of the project cycle" means actually identifying a rather narrow range of options for the microcontroller and related hardware because those project unknowns develop out of these project boundaries determining the limited range. For example, there might be an extremely low power requirement with extremely fast "sleep to full-operation" required and this, a priori, limits your processor choices to exactly one: the MSP430. In that case, the unknowns might be more about whether or not the rest of the goals can even be achieved with such a device, at all. In that case, you DO CARE about what you use early in the project cycle to ferret out and resolve unknowns directly related to that guess about the processor being your only choice. You may need to push back, after this early investigation, one some given boundary once you determine that the MSP430 cannot achieve some other required goal.
So it's not always the case that the prototype base doesn't matter. Sometimes it does. But it takes experience to know if it does.
