When making apps, we often think of a stack of features. There might be a foundation with smaller features on top. Or, we might think of it as a technical stack, with underlying back-end with font-end on top. It’s the features list in your marketing page. It’s the bullets on the side of the box. It’s the list of todos in JIRA, Fogbugz or Trello.
Us designers are the most stack-central. This is because we work on a 2D representation of the app in front of us. A static, beautiful, thing. Often abstracted away from the underlying technologies that are in constant change, we see only the instant slice of time. Yes, we may be prototyping, but that’s interactions on the second, and minute, granularity. Technology tends to move in months and years.
The truth is that an app is not something that exists in frozen Matrix-like bullet-time. It has a lifetime. An x axis. And if it doesn’t have the support and love it needs over that x axis, it will die. You might almost call it the x-factor. The world and OS around it change, breaking how software works, or making it redundant. In a worse case, this means an EOL (End of Life) decision, or worse, a bunch of broken apps on people’s devices. In a best case, it becomes a paradigm-shifting tool that lives forever.
At the beginning of my career, I was blind to much of this. Over time, I’ve realized how important this lifecycle is. This article shares some thinking on this.
So let’s imagine two products: one is a ‘vanity’ app, and the other is one with a sustainable, integrated, business model. By vanity, I mean an app that’s made because some CEO says ‘we need an app’.
Both types of apps in our scenario look great at 1.0. In fact, there are reasons why the vanity app might look more eye-catching.
- It’s using lots of (hard-to-maintain custom) drawing code
- It is heavily optimized to look good on slides and pitch decks
- Development has been maxed-out (burnt-out?) for 1.0 release
- Agreed terms require features to be ‘in’, bugs be damned
In contrast, the sustainable app in this imagined graph has less features targeted for 1.0. And some of the features even get removed before 1.0 because they don’t work. It is a beautiful app, but not at the expense of its functionality. The development team is not burnt out, and the hard decision to drop features have been made.
Once the vanity app launches, there’s a bug fix and a few more missing features added. The development team is then moved on to another project because the app is ‘done’. But somewhere along the way, a system OS update breaks some features, so the app gets some fix release. But it happens again, and the app gets End Of Life’d.
In this imagined comparison, the sustainable app continues to put out releases year after year. For example, Photoshop was created in 1988. And I bet somewhere in today’s app there is still 1988 code running. Which means there are 20-somethings alive today using software, that is in-part, older than them. Another old example I found was MOCAS, US government cost-tracking software running since 1958. That makes it 60 years old.
I’ve grappled with what decisions make a more sustainable app. Here are my ideas so far.
Core technologies that are used one product can power new products.
- Skype re-used an earlier product (Kazaa’s) P2P tech
- Unreal Engine, possibly the most popular game engine today, was first created for the Unreal game and later made available to the public
As told in the opening chapters of Daniel Pink’s Drive, Wikipedia won out over Microsoft’s Encarta. The community, and their drive to contribute, kept improving Wikipedia. Other example of commercial software built on a community driven foundation:
- Safari on open-source Webkit
- Linux and Mac OS on open-source Unix variants
- Wordpress Hosting on top of the open-source Wordpress software.
Expandability through building
Related to community is expandability through extensibility. My favourite desktop app at the moment is Bohemian Coding’s Sketch. The plugin commmunity around it is simply phenomenal. Almost all are free.
Here is an example of the Runner plugin being used to find and install and launch the Segmented Circles plugin. The flow means I can go from an idea—in this case draw a segmented circle—to actually doing it, in a few clicks.
Expandability through in-app stores
Another kind of expandability is through in-app purchase or integrated store.
There is a story that why the iPad didn’t launch with a bundled calculator app. The story is that Steve Jobs yanked the one they had developed at the last moment. Scott Forstall’s team had taken the existing Bruan-inspired design and stretched it out. Steve didn’t like it. Of course, Steve had designed the original Mac calculator, so maybe he was particularly sensitive to calculators.
But something else had changed since the iPhone—the App Store had launched. And part of me thinks the reason why the iPad still doesn’t have a calculator app. It’s not wabi-sabi. It is because a calculator is a great application to have on an iPad. A calculator is a great app to learn to build due to its constrained, well-understood functionality.
So, the moment a user looks for a calculator on their iPad, assuming one would be there, they’ll find nothing. With a gasp of wonderment, they’ll go to the App store. After all, that is where one goes for apps. And they’ll find an assortment of wonderful, and varied, free and paid, calculators. And while there, be exposed to other apps, featured apps, and well, more reasons to give Apple more money.
In the process, the user discovers one of the most powerful features of a modern device: new functionality with just a few taps.
Building on a growing thing
If I may use another Steve Jobs quote :
We try to look for these technical vectors that have a future, and that are headed up, and, you know, different pieces of technology kind of go in cycles. They have their springs and summers, and autumns, and then they, you know, go to the graveyard of technology. And, so we try to pick the things that are in their springs.
While at Evernote, I worked on Scannable, a document scanning app. The app used machine vision on the GPU. It could find documents (skewed rectangles), choose when to capture, dynamically clean up, crop and rotate. We could tell if something was a magazine article or a mostly black and white document, for example. This let us crunch down images to über-clean, tiny files for easy sharing and fast uploading to the cloud.
We were pushing the GPU hard, CPU, and camera hardware hard. But we knew that those three things were on a rocket trajectory. With each new iPhone hardware release our app got remarkably better, with no effort from us. Each new phone has
- Higher resolution cameras
- Faster capture times, including indoor low-light (usual document-scanning place)
- Better in-camera stabilization, a big deal for document capture.
- More powerful GPU and CPU to handle on-the-fly image processing
Starting from today, if you had to predict a couple of years away, you could count on the above continuing to improve. And I’d throw in the following:
- Improved ability to understand the content of images and audio
- 3D imagery available at all times
- Improved awareness of place and human focus, and activity
Back in the day, I was part of plasq when we released Comic Life—a Mac app for turning a set of photos into a comic book. It was a very successful shareware app. We were approached by Apple to bundle it with new Macintosh computers. We were afraid that bundling with new machines would kill external sales. The logic being, that people who buy new Macs, were also the ones shelling out for new software.
In the end, after some negotiation on price made that less of a concern, we opted in. But—we didnt see a reduction in sales of our shareware version. From memory, there was actually an increase in shareware sales. I’m guessing the increase was caused by people seeing the app on friend’s computers and deciding they needed it for themselves.
A few years later, I saw something similar: We were offering Skitch in a fremium model. Modelled somewhat after Evernote’s model, we offered a premium version of the app bundled with a premium version of the online experience. But sales were slow, and cash was running out.
So, we decided to put a premium-featured version on the App store as a once-off purchase. Again, counter to our expectations, App store sales were additive. It was two independent markets.
I learnt that there are often multiple, completely disconnected, markets. If you can design and engineer your product to accommodate both, then sustainability is increased. My previous example, Scannable, leveraged the engine that Evernote used internally for document OCR. The document cleanup was used to improve character recognition, but the resulting cleaned-up document was never shared back to the user. When Scannable was released, there was now two ‘consumers’ for that core tech.
What to do with Tabby
Now the bit where I ask for your help! I want to make my personal startup, Tabby, a sustainable thing from day one. Because it’s really a tool for connecting remote workers, it feels like a monthly recurring service is the best fit. Is there another market? Do people want to write extensions, like they do in Mac productivity apps like Alfred? Should I do an ICO? (I kid, I kid).
So, if you got this far in the article…
- Please take a look at teampurr.com
- Let me know in the comments below which approach you think would work best for Tabby?
Please do let me know in comments below.
And as always, if you found this article useful and/or entertaining, please give it a 👏 to help others discover it. Thanks!