Do you actually need a mock app, or just a wireframe/interactive design? It seems like you are trying to shop around to find a developer and they should be able to work from a design. A quick Google search reveals Pixate and Invision, either of which might do what you need.

One element of your question would concern me; if an incumbent sees your success, they could easily add your unique feature. If it really is just that simple, it seems like a risky project. On the other hand, if you also have a lower margin business model that your competitors can't easily match then that risk is mitigated. For example, you launch with free base product and $1+/month for extra features whereas they are $10/month basic. It's hard for a company to come down in price like that (see Innovator's Dilemma). Of course there are other factors, but that one stood out.

Congratulations on the opportunity...! I've seen situations like this from the other side, working for a big ERP vendor. To try to answer your questions out of order: How to structure? Based on the info provided, the simplest thing would actually be no specific arrangement at all. Lots of ERP add-ons are sold to ERP customers without being "contracted" by the vendor. However, if they want to work with you directly then a contract (not a joint venture or anything else) is the best place to start. A contract ensures all factors are on the table such as your investment to provide the integrated product, and so on. Is the arrangement month-to-month or for several years? Is there any guaranteed volume, or is it just "best efforts". And so on. What's realistic? Again, for two companies that don't really know each other and with a size differential, you're unlikely to get anything you'll like other than a contract. The exception is if they see you as extremely strategic to their future, in which case you might swing an acquisition -- if you actually want to lose control in exchange for equity in their company. What key factors? It's hard to say without knowing more. I'd say stick to a simple contract unless an outright acquisition is likely. Make sure you don't put too much in up front without a reasonable guarantee of return; a bigger company can easily change direction six months from now and leave you hanging. As soon as you have one customer in common, you'll be stuck to this other company for years, so play fair! If they are not good partners, consider walking away. ERP has a very long lifespan. I'm not sure what you feel you might lose control over (you think they might copy your product?) but if you negotiate a reasonable contract, you shouldn't have too much exposure. Hopefully this is useful; there are a lot of issues that will be specific to your exact situation.

I guess the first question is whether the apps already have a database component, or if you are needing to introduce a server call for the first time. If you have no other factors involved it sounds like a pretty simple database query is all that's needed, in which case pick your favorite stack. I use Apache/PHP/MySQL, and I'm sure plenty of people use Windows/MS-SQL. If you can provide more information, it would help refine the answer.

I think push vs in-app are two different things, like email and telephone call. Push reaches people who are not using your app, but require OS-level permission. In-app gives you much more flexibility but they only reach people who are using your app (obviously!). As to whether in-house or external SDK is best, it depends what you are trying to do and whether an external system handles it. For a typical retail environment the SDKs might be easiest--it's a well-established use-case. For something needing a more customized algorithm, an in-house system might work as well as an external SDK (for less money). There are simple options to save you from starting completely from scratch, from PHP toolkits to Amazon SNS. It depends on what (if any) server environment you have... Hope that helps!

The other answers are good, and here is one practical approach to handling this. First, the accounting capitalization (10m x $0.001 = $10k) is really irrelevant. In fact, we went for 10m x $0.0001 = $1k. Whatever you pick, your company after formation will show $X of assets (the cash in the back) and $X of shareholder equity. So far so good. You then need to start spending money through the company. Rather than issue more shares, you can lend the money to the company; write out a loan agreement (probably something like a balloon payment 10 years out with 0% interest) and deposit the check. If you're doing everything at the same time, and want to have $1k of shareholder equity with a total of $25k to spend, then deposit the $25k check and call it $1k to purchase the founder's shares and $24k loan. In this case, your company now has $25,000 assets/cash, $24k liability (to you) and $1k shareholders equity: assets = liabilities + shareholder equity. Hope that helps clarify things a bit...

Are you looking at iOS or Android? They have very different technical profiles when looking at beta scenarios...!