Fret not. Their opinion is worth crap. They are not the ones who write the checks. In the end, your app will more closely match the client’s application because they’ve already “seen it working” and given feedback, and by then you get to focus on making the dynamic data stuff work.

Just one more thing to suggest. If your app has dynamic data services you need to tie into, do NOT demo those. Suits do NOT give a shit if the data is real or not; they perceive it as real, dynamic, and cool as nuts. That solidifies their expectation of the working application, and assumes the rest is just details they shouldn’t care to know.

Furthermore, fake data always works, real data doesn’t. If you want to ensure a meeting goes without a hitch, use fake, local (non-internet connection requiring). You’ll accomplish your main goal of garnering feedback from the client (or upper management) without going “Oh… well, we haven’t tested this… the server is down.” It’s all gibberish and no one cares. Do not depend on code that is not yours (aka the back-end).

Instead, create a branch of the code base. If you are the only developer, you do not need to create a branch, but instead use copious “// DEMO” comments, much like TODO’s. The only difference is they “nudge” the app to work with fake data.

When you’re demo / meeting is done, and you’ve discussed the feedback and potential changes, either merge your branch with the real code base (SVN branch vs. SVN trunk) OR, if you are the only developer, just start commenting out your demo code.

I’ve found the “conflicting 2 priorities” of if the Flex app should look like the comps vs. be a fuctional for the sake of looks usually work themselves out by themselves. Naturally this wouldn’t fly in a design agency, but then again, I’ve seen a few start selling their services as more application specific… so it could go either way.