cmchien

Per this technical documentation link, the data is supposed to be current to 2018:

http://livingwage.mit.edu/resources/Living-Wage-User-Guide-a...

The Economic Policy Institute's Family Budget calculator, which is a better estimate of area-adjusted living costs than the federal poverty line "measures the income a family needs in order to attain a modest yet adequate standard of living"[1].

For the San Francisco, CA metro area (which in their model includes Menlo Park, where the family lives), they estimate that this "modest yet adequate" standard of living would cost ~$116K per year, inclusive of housing, food, child care, transportation, health care, other necessities and taxes. Even removing housing from the equation ($32K), that leaves about $85K to meet a basic family budget. So I think that their experience that their income is a real stretch to meet basic needs is not so far from reality as you might conjecture.

[1] http://www.epi.org/resources/budget/

Sure thing.

I don't know the specific tech that Adobe is using, but I'd look pretty carefully at the technology before committing to a platform like this as a true cross-platform development environment. "Cross-platform" can mean lots of different things.

We had a native app developed in Android. When we decided to create an iOS version, we selected Appcelerator after reviewing a few different options and seeing what we perceived to be good adoption of Appcelerator (and after talking to another firm that chose the same thing). And, we (mistakenly) thought that it's "generating native code", so, if anything goes wrong, we can always debug in the Objective-C. Right?

Wrong.

About 6 weeks into the development process, we were doing a round of testing to get a version out to Beta testers and found that we simply couldn't debug the code and get it to 100% stable. That's when we dug deeper (yes, a bit late for that...) and found that Appcelerator is essentially a VM running on top of the native stack. So crashes get logged to the same few lines of Appcelerator interpreter code--which is pretty much useless for debugging. For prototyping, it's great, but for production quality code, I would say stay away.

Shortly before we finalized this decision, we reached back out to the other firm whom we had originally spoken to before making the Appcelerator decision. They told us that they were in the same spot and had just made the decision to move off Appcelerator a couple days previous--for the same reason: stability and lag issues and no way to get to zero defects.

We moved to native Objective-C and the dev team is much happier. Crashes have full stack traces and we can identify exactly what to fix.

We got some benefit out of Appcelerator because the second round of development took less time, but given the choice (and knowing that we weren't just prototyping--we had a native Android app and we were generally happy with the screen flows) we would have gone native to begin with.

Re: the Starbucks effect, I'm not sure I agree. I think the difference between Starbucks moving in next door and Apple implementing a feature like Reading List is that in the case of Starbucks moving in next door, their marketing drives foot traffic to the vicinity of your location--which you can then take advantage of. I.e., people walking by see your signage and therefore you can capture sales. It is the creation of demand, but it's the creation of demand that your own (much less resourced marketing) can then take advantage of.

In the Reading List case, there's no guarantee that customers that "get educated" about the product will necessarily ever find out about yours. It's still up to you to be in the same "location" as the competitor's product in order to benefit from their marketing.

This may be the case for very well-known products that are always going to be discussed in concert with a feature launched by an Apple in the media, product reviews, etc. But it's certainly not categorically the case.