The core team (if there's no significant web service back end, which it sounds like there wouldn't be) is typically:
- A developer (with understanding of design)
- A designer (with understanding of development)
In iPhone, it's often the designer who anchors the team. Whether that's an anomaly or a sign of a long-term shift is an interesting question - but for now let's steer clear of that rabbit hole!
Technology-wise, you have some choices on how to go.
The apparent default choice is to build a true native app from the ground up. The development environment is famously unloved, but plenty of people out there have developed the skills and are hammering out apps.
For me, the real default choice is to leverage HTML 5's ability to deliver app-like experiences that access services from the phone. Typically, this means that the native app is a simple loader using a Safari instance - and you can prototype and refine as rapidly as you do for regular websites.
This works well in a surprisingly large number of cases, and delivers some great benefits. Covering multiple platforms is far easier, and routine updates don't require app store re-submission as the app itself doesn't have to change.
Another approach to multi-platform development that leverages web technologies but creates native apps is to use Appcelerator's Titanium. This allows you to target both iPhone and Android, and either avoid native coding altogether or confine it to modules accessed from your app.
And finally, it's worth mentioning MonoTouch, which lets C#/.NET developers create iOS apps - which gives you access to a vast skill base. This is a great solution if you have those skills in-house. You'll probably still go out-of-house to execute the project, but you will have the option to bring the maintenance and ongoing development into your team.
Those are technical choices. Meanwhile, I'd recommend you use a wireframing tool such as Balsamiq to turn your plan into something visual. If nothing else, this will help you through some of the thinking about what's important to you. Even if this changes beyond recognition (and experienced app developers will often lead you through thinking that turns your ideas upside down!), you have a common reference point. Too many app projects produce disappointing outcomes because the specification is either way too loose (so the new team is guessing at the ultimate success criteria) or way too prescriptive (so you get what you ask for but not what you need).
Good luck with the project. If all these choices seem like too much, start out with the default (HTML 5) and change when and only when you have to.