This is a good post-mortem on an app built by a small team trying to achieve sustainable revenue.
Summary: Strongly consider subscription model for mobile apps (free app w/ in-app purchase). Can still charge more for desktop apps, so good place to start for initial funding. Try to anticipate where the APIs are going to minimize your rework.
I am learning that if you try to follow the money you won’t be able to innovate; you’ll be too late.
The innovation precedes the payoff. But how can a project be built unfunded? Either by careful bootstrapping or by convinced investment.
So it seems innovation is a faith-based affair.
Even when endeavored the invention may not work. And even if it does the pay-off may never come.
So all the more faith is required to begin.
Don’t work for a company that is easily replaceable at a lower valuation.
One of the things I’ve been most impressed with at Facebook: GraphQL. It’s going to change the way APIs are done.
Looks like a great evolution in message-based web APIs. The idea is that the client describes the DTO it wants. Supports strong types but allows the client and server to evolve more independently.
Geoscientists with an interest in the Market will enjoy chapter 4 of Business Adventures by John Brooks.
The events that led to the S.E.C.’s action began in March, 1959, when Texas Gulf, a New York City- based company that was the world’s leading producer of sulphur, began conducting aerial geophysical surveys over the Canadian Shield…
Many authors can’t separate themselves from their work, but the ability to do so is a valuable asset.
While I sometimes lament forming explicit constraints on generic types, building shared libraries that use generic types is much easier in C# than C++.
Generics in C# are implemented dynamically (link time or later). Templates in C++ are implemented statically (compile time). Thus type constraints can be implicit in C++.
But, if you want to use a template type in your API (e.g. std::string) you need to [DLL] export the specialization(s). This is confusing in the best case, and seemingly impossible in others. It may be because nested classes cannot be forward declared. Or because I cannot figure out the correct specialization of all the helper classes…
After years of using both, I prefer the link-time approach. In particular when building a shared library.
In competitive endeavors some secrets are valuable. Other secrets are accidental and better shared.
It is frustrating to work with organizations where all work is confidential. One of the hidden costs is working alone on non-core problems. For example, encountering an obscure compiler bug can cost days. Sharing a work-around is unlikely to substantially help competitors. On the other hand it will likely lead to helpful comments from others with the same problem.
One day, every dollar you own will belong to someone else.
Handoff - this is a key ingredient of ubiquitous computing
Instant Hotspot
Dial phone from Mac
Family Sharing (but must be same credit card)
Photo Streams / iCloud integration
New Photos app
Cheaper iCloud pricing
Metal - precompiled shaders, gpu compute
“Apple engineers Platforms, Devices, and Services together … seamless experience for users” - Tim
Looking forward to 2015…loading tweets…