Do you think it's impossible for health apps focused on low-income/Medicaid populations to make it in the consumer market?

There are two sides to that question. One is the mobile app itself and the other is the backend. If I misunderstood in any way and you didn't mean "native" app I apologize in advance. On the backend, there is no clear cut answer to which is the "best". It depends solely on the developers you are able to get. We for example use Node.js , mongoDB, redis, elasticsearch and a couple of proprietary tools in the backend. But you have your pick of the litter now both on the backend api and the datastore with the myriad of options available and touted as the "best" currently on the market. Now on the app side again it solely depends on what you need your mobile app to do. Experiencing first-hand "develop once, run anywhere" I can say it's more like "develop once, debug everywhere" to quote a Java saying. We have tried Phonegap and Titanium Appcelerator and we have switched to native (ObjC and Java) after a couple of months of trying to go the hybrid route. The reasons behind the choice are as follows: - anything that breaks the pattern of how those frameworks NEED to operate is just a huge technical debt that keeps accruing a huge interest. - anything that uses css3 accelerated animations on Android is buggy at best and slow as hell at worst on any lower (< 4.1 I think) versions of Android I hope this gives you some insight. If you need/want to ask me anything feel free to contact me. Mihai

You won't find anyone worth adding to your team willing to work for equity only, no matter how compelling your product and business is. The realities of the talent market for mobile developers anywhere is such that a developer would be foolish to work only for equity unless they are a cofounder and have double digit equity. Happy to talk about hiring and alternatives to full-time hires.

Apple will allow a developer to register 100 UDID devices per 12 month cycle to test via TestFlight or HockeyApp. Having started with TestFlight, I would really encourage you NOT to use it, and go directly to HockeyApp. HockeyApp is a much better product. There is also enterprise distribution which allows you far more UDID's but whether you qualify for enterprise distribution is difficult to say. As part of your testing, I'd encourage to explicitly ask your testers to only register one device. One of the things we experienced was some testers registering 3 devices but only used one, essentially wasting those UDID's where we could have given to other testers. Who you invite to be a tester should be selective as well. I think you should have no more than 10 non-user users. These people should be people who have either built successful mobile apps or who are just such huge consumers of similar mobile apps to what you're building, that they can give you great product feedback even though they aren't your user. Specifically, they can help point out non obvious UI problems and better ways to implement particular features. The rest of your users should be highly qualified as actually wanting what you're building. If they can't articulate why they should be the first to use what you're building, they are likely the wrong tester. The more you can do to make them "beg" to be a tester, the higher the sign that the feedback you're getting from them can be considered "high-signal." In a limited beta test, you're really looking to understand the biggest UX pain-points. For example, are people not registering and providing you the additional permissions you are requiring? Are they not completing an action that could trigger virality? How far are they getting in their first user session? How much time are they spending per user session? Obviously, you'll be doing your fair share of bug squashing, but the core of it is around improving the core flows to minimize friction as much as possible. Lastly, keep in mind that even with highly motivated users, their attention spans and patience for early builds is limited, so make sure that each of your builds really make significant improvements. Happy to talk through any of this and more about mobile app testing.

Cash money should be treated separately than sweat equity. There are practical reasons for this namely that sweat equity should always be granted in conjunction with a vesting agreement (standard in tech is 4 year but in other sectors, 3 is often the standard) but that cash money should not be subjected to vesting. Typically, if you're at the idea stage, the valuation of the actual cash going in (again for software) is anywhere between $300,000 and $1m (pre-money). If you're operating in any other type of industry, valuations would be much lower at the earliest stage. The best way to calculate sweat equity (in my experience) is to use this calculator as a guide: http://foundrs.com/. If you message me privately (via Clarity) with some more info on what the business is, I can tell you whether I would be helpful to you in a call.

It all depends on what one decides to be a definition of a "success story." For some entrepreneurs, it might be getting acqui-hired, for some -- a $10M exit, for some -- a $200M exit, and for others -- an IPO. Based on the numbers I have anecdotally heard in conversations over the last decade or so, VCs fund about 1 in 350 ventures they see, and of all of these funded ventures, only about 1 in 10 become really successful (i.e. have a big exit or a successful IPO.) So you are looking at a 1 in 3500 chance of eventual venture success among all of the companies that try to get VC funding. (To put this number in perspective, US VCs invest in about 3000-3500 companies every year.) In addition, there might be a few others (say, maybe another 1-2 in every 10 companies that get VC investments) that get "decent" exits along the way, and hence could be categorized as somewhat successful depending on, again, how one chooses to define what qualifies as a "success story." Finally, there might also be companies that may never need or get around to seeking VC funding. One can, of course, find holes in the simplifying assumptions I have made here, but it doesn't really matter if that number instead is 1 in 1000 or 1 in 10000. The basic point being made here is just that the odds are heavily stacked against new ventures being successful. But that's also one of the distinguishing characteristics of entrepreneurs -- to go ahead and try to bring their idea to life despite the heavy odds. Sources of some of the numbers: http://www.nvca.org/ http://en.wikipedia.org/wiki/Ven... https://www.pwcmoneytree.com/MTP... http://paulgraham.com/future.html Here are others' calculations of the odds that lead to a similar conclusion: 1.Dear Entrepreneurs: Here's How Bad Your Odds Of Success Are http://www.businessinsider.com/startup-odds-of-success-2013-5 2.Why 99.997% Of Entrepreneurs May Want To Postpone Or Avoid VC -- Even If You Can Get It http://www.forbes.com/sites/dileeprao/2013/07/29/why-99-997-of-entrepreneurs-may-want-to-postpone-or-avoid-vc-even-if-you-can-get-it/