Today, we are switching Ulysses to a subscription model. The short story is this (tl;dr): Our users expect a continuously evolving high quality product — and subscription is the only way we can truly deliver on that expectation.
The following post then, is the long story. I will try to explain all the thoughts we have gone through, all the options we considered, and why we concluded that subscription works the best for us and for our users. If you’re just interested in Ulysses’ new prices etc., please feel free to read the announcement post on our blog.
Before getting into details, though, you should know that this switch was neither a quick decision, nor did we take it easily. We have been talking about it for over 2 years now. We’ve had uncountable discussions, and the topic came up at least once every month — yet we always postponed a decision. The sheer complexity and far reach of this change were too intimidating. I am not exaggerating in saying that this was the hardest decision in our whole time as professional software developers. After all, we have a system which currently works — after 14 years we are still around, Ulysses is still “a thing”, it’s even going better than ever before, and there are no immediate signs which hint at a change coming soon.
So why bother at all then? Well, we need a good way forward before we run into trouble. We want to make sure the app will be around for years and years to come. We want to heavily invest in its development, and this requires the right setting for our team, our families and our users. Writers want to rely on a professional tool that is constantly evolving, and we want to keep delivering just that.
A tiny bit of history
Software purchases used to be very different from how they are today. Until not too long ago, you would purchase an application and get a physical copy on a bunch of floppies (or later a CD). The thing you got — that was it. No patches, no updates. Developers had to put forward an extreme amount of attention to get everything right, because once an app was out, development had to be done.
And that’s also what you paid for: A finished product. Essentially, you paid the development time spent up until the app’s release. New features were then delivered via a new version, and you had to pay again, if you wanted that new version.
Things changed with the advent of the internet, of course. As soon as we had dial-up connections, developers could offer small patches to fix issues that were found after shipping. And once broadband connections were ubiquitously available, larger and more frequent patches were possible. At first, these resulted in new features being added on-the-fly, but it quickly evolved into issuing more and more substantial patches — until today, where most v1.0s are mere sketches of a future product.
The “pay upfront” fallacy
Interestingly enough, the way we pay for software hasn’t caught up to that rather drastic change in development yet. We still pay for the product at the time of its release, meaning we’re still paying for its past development cost. However, we now expect the product to magically evolve over time, via downloadable updates, without a need to constantly pay for new versions.
For some reason, this model has gained a popular label which can only be seen as a major fallacy: Paid upfront. No, it isn’t. It never was. We still only pay for the version at time of release; apps don’t spring into existence, after all. If anything, this model is “pay once”.
Crunching the numbers
Let’s map this onto Ulysses for a moment: If you bought Ulysses at its launch in April 2013, you will now have received nine major feature releases. For free, at no additional cost. At least 80% of that originally purchased app have since been scrapped and replaced. Its functionality has quadrupled during the same time.
Each of these nine updates required a considerable amount of time on our part, which of course translates into a considerable amount of development cost. But with customers ever only paying for the development of the current version — how did we manage to finance new versions then?
The answer is simple: New users.
Or in economic terms: Expanding our market.
Now, as long as there was a strong-enough flow of new customers every month, development costs could be covered by those sales. But since ours is a growing product (updates!), it hence needs a growing team (more code), which means growing development costs (devs need food), which in turn means we need an ever-growing stream of new users.
Needless to say, solely relying on new customers to keep your business going, is a very unstable idea — at the very least, there will come a time of full market saturation, right? But the main issue with this model is something rather different.
Update for the heck of it
See, in order to get new users, you need to catch their attention first. This means media coverage, App Store features and so on. The only way to predictively achieve this, are new versions, obviously. Big point releases, like 1.5, 2.0 and so on. And yes, these would create huge spikes in sales, but after an initial period, revenue would drop considerably, because… no more coverage. So we’re caught in an unholy cycle of
update › attention › sale spike › sales drop › update
…ad infinitum.
And just to be clear: In-between such big point-releases, sales will often drop to a non-sustainable level. So it’s not that we’re getting rich during the development period, and even richer after each update. No. We’re actually losing money during development. And so the longer it takes to ship an update, the riskier it becomes financially. We are, in fact, highly dependent on these sale spikes, in order to make money. Here’s an illustration of what I’m talking about:
Every sales chart you will ever see, of any paid app, will look like this — give or take the height/duration of the spikes. And yes, some apps may have a steady income which actually covers their recurring costs. But it should be clear by now, that this model creates a huge pressure to get new releases out as quickly as possible. But wait, there’s more.
Who’s the target?
As we have shown, we need a constant stream of new users in order to make money. This means a constant stream of new versions, in order to generate attention. Now… since only new customers will be paying for our development costs — for whom do you think should we optimize these new releases?
The answer is obvious, and so it’s no wonder why you see lots of apps change so much with each major update. There’s just no economic or even marketing reason to fix and tune things, or dive into long phases of cleaning up and optimizing central parts of the app. “Now has less bugs” is not what makes the headlines. Features, however, do, and so you see apps grow and grow, developers add and add, and… bloat, ultimately.
Of course, we don’t have to give in to this — and we’re proud to say that we think we didn’t –, but if your business model is bound to push you into a direction you’re not willing to go, then maybe it’s time to change the business model. If you want a stable financial foundation, “paid once” is clearly not it.
Paid Updates
There have been concepts to mitigate the above problems. The most common one being “paid updates”. Paid updates mean, that instead of improving an app for free forever, there will be a point where no new features are added to the current version. Instead, the developer will make a copy of the app in its current state, and add new functionality to that copy only. Nothing changes for new users, of course, but existing users will have to pay again, if they want to get the new features.
Now, in order to make existing users pay again, developers usually offer them a substantial discount on the new version. So new users will pay full, existing customers will pay just a fraction of the asking price.
At first glance, this solves the problem of a developer not getting appropriate compensation for their work, right? After all, they are being compensated for their development cost, so income is somewhat continuous. Problem solved, eh?
Well… this post wouldn’t exist if we believed this was the answer. A lot of problems remain unsolved with this model, and new problems are introduced. And then there are problems with Ulysses in particular. Worst of all, the most glaring issues with the “pay once” model remain untouched: Huge spikes during releases, relatively low sales otherwise, and the persistent uncertainty of how new user streams will develop in the future.
Let’s just update our picture from above…
It’s perfectly obvious that the overall situation is the same for paid updates as for one-time purchases. The situation is less severe than with the paid-once system — the sales spikes after bigger releases will be much higher –, but after each release, sales will fall back to a similar level.
Also, existing users may not update at all. As such, sales will essentially fall back to a comparable level of what would have been without a paid update. And so it comes as no surprise that developers of apps on the paid upgrade model keep mentioning that they depend on users upgrading. The sale spike (i.e. the number of updaters) during each release is still elementary to them getting over the development time. There have to be paid updates. On a (somewhat) regular basis.
… mo’ problems
Now, paid updates need justification. You can’t just change a few small things, add a new icon and call for money. The update needs to add significantly to the current experience, or else there’s no reason to even update. So in order to create an interesting, pay-worthy package, multiple major features need to be bundled together. But… big releases take time, and the bigger the release, the more time it takes. You risk getting delayed, users will start to complain and probably look elsewhere — there’s a huge risk in depending on paid updates, if you can’t guarantee release dates. Which usually you can’t.
Plus, updates pose a certain risk for the users, too: Will everything still work as expected? Will my beloved interface have changed? And what about the user who just bought the app? Buy it one week and be asked for more money the next? Nobody is happy about that. You can keep the “old” version, sure, and developers try to solve this conflict by pre-announcing releases, or by offering free updates if you bought within the last 8 or 12 weeks or so, but that certainly doesn’t help to keep things simple, does it?
And let’s just say you don’t update. You simply stay on the previous version, because you don’t think you need the new features, or because you find the update price not worth it. How long will this very version continue to work? On the same device and the same operating system… probably “forever”, sure. But does that really hold nowadays, when people get new phones every two years and OS updates are free?
New is the new new
How many of us will resist updating our devices just to keep some previously purchased app running? Tendency: zero. We do get the new devices. We do update our OS. But the next major device or OS update will certainly introduce something very different to what there was before — a new screen size, modified system behavior, stricter rules for apps accessing user data, some features getting removed, bugs getting fixed (and new ones created), and what have you. Apps can’t “be ready” for that. They need to be updated. Kept up-to-date.
Ulysses, for example, had critical bugs on every new version of macOS and iOS that came out since we launched in 2013. Yes, we fixed them immediately, but the next device, the next OS, will break some stuff again. The old app will break eventually, there’s just no way around it. As soon as the user’s environment changes, old stuff breaks.
So if you want to keep using apps across devices and system generations, you better get their latest versions. You are literally forced to update your apps these days, just in order to continue using them on your latest hardware. But since you’re forced to update anyway, it’s somewhat… controversial… to make you pay just to keep the app running, no?
Not for us
Making paid updates work is definitely possible, as has been proven many times. It’s neither particularly stable financially, though, nor is it in the users’ best interests. There are workarounds for most of the issues, sure, but you’d be hard pressed to not just call them “hacks”: Keep old versions available somehow, introduce grace periods, update old versions until their usages falls to zero, etc. — but during our year-long discussions, we simply concluded that “paid updates” can only ever be a quirky bridge between the old-school “pay once” model and modern user expectations and behavior.
Ulysses and cross-platform updates
Let me side-step for a moment: Would adopting update pricing even work for Ulysses? Let’s just say we found viable solutions for all of the standard problems — would it even work?
Ulysses makes the most sense when used on multiple devices. If you have a Mac, an iPad and an iPhone, you want to edit your texts on all of these. Up until now, you had to purchase two somewhat arbitrary parts, though: one for Mac, and one for iOS. That’s how the App Store works, there is no way to combine both platforms in a single purchase. So the moment we’d do a paid update, users would have to buy two new apps.
And the very moment we’d introduce a new feature which requires a change to the file format, you’d be forced to update both platforms — or else compatibility will get out-of-sync. Users won’t be able to open their newly created documents on the device that is missing the update:
As a matter of fact, the second platform must be updated as well, or its old version will simply cease to work correctly. So for Ulysses, a “paid update” would actually be two paid updates. Now that’s neither elegant or simple or clear — it’s a weird and complicated mess, and it only emphasizes that taste of “not for us”.
Other options
Ok, so “pay once” and “paid updates” don’t provide a feasible outlook. What are our options?
Idea #1: Make either platform’s app free. Easy. Just one purchase and you get the full app. Once you have that, download the other one as you like, and sync away. One primary app, one companion app. Cool or not cool? Not cool, sorry. First, not all users have both platforms. If they happen to be on one platform only, they will either get it all for free or be the ones who pay for “the other guys”. Besides… which one to make free?
Sure, the Mac version is more expensive, so we could offer iOS for free. But wait, iOS is the future of computing, and as such is the wiser choice thinking forward, so… increase its price and give away the Mac version. But… the Mac is currently our bigger source of income, and we can’t just kill that, so the choice is obvious: iOS goes free. Uhm… but what if Mac sales start to decline, because our iPad version fits the bill of most users just perfectly? Switch the “free” version?
We seriously can’t answer the question, of which app to make free, and I doubt anyone can. And so “one-platform-free” is clearly out of the picture.
Idea #2: Go “free with in-app-purchase”. Just release both apps for free, and then let people buy certain “Pro” aspects. Export maybe. Or sync. Or umlauts (we seriously considered that). This would allow a free trial, and the in-app purchase could unlock all platforms. It’s a tempting idea, but would it really solve the issues we’ve been describing? I fear not. After all, it would be just a variation of “pay once”. We would still have to do major updates from time to time, with all the issues of arbitrarily aggregating features to form a “package”. The same unsteady income, same minimal planning security, etc.
We would also cut our user base into several groups: Has IAP 1; has 1&2; has 1&3, and so on. It’s certainly suboptimal. But we’re getting there…
Universal subscription
Going forward, our solution to all those aspects will be subscriptions. Recurring payments that unlock the full app. Cancel anytime, stop paying and the app enters read-only mode. Continue paying to re-enable editing texts. Export stays alive, as do all other features — just disable editing. Simple, right? Well, it is! 🎉
And it comes with so many benefits over all the other options:
- First and foremost, there will no longer be two purchases. A single subscription will unlock the app on all devices.
- Ulysses can now be downloaded “for free”, and we can offer a fully featured, time-limited trial across all platforms, with sync and everything. Which certainly beats a Mac-only demo.
- We can now offer multiple plans, instead of “get all or nothing at all”. Users can choose between a flexible monthly, or an overall cheaper annual plan. A few dollars for a monthly payment sure are a much smaller barrier than shelling out the full $70 at once.
- Subscriptions make the app more accessible to many more people. There are tons and tons of folks out there who just cannot afford a full purchase. But most of these folks will be able to pay a few dollars every month. Even better: monthly payments allow the casual user to subscribe only during their months of actually writing. Subscriptions adapt much better to on-off or low-budget users.
- On the heels of #4: We are finally able to offer student pricing! Having been students ourselves, we know how tight a student’s budget can be. Yet students must often write massive amounts of text, and are in a great need for a great writing app. From today on, we will offer students the full app at a considerably discounted price.
- Subscriptions set us free from the pressure of rolling out massive updates every year. We no longer need to combine an arbitrary set of features to create a fuzz or make a good reason for a paid update. We will still have updates, of course, but you will be receiving new features earlier and hopefully also more often, because we can just… stream them in.
- Subscriptions are also the only match for the way technology works these days. As explained earlier, operating systems and devices get overhauled every year now, and major new features come out even throughout the year. Think TouchBar on the new MacBook Pro, or think the iPad Pro’s 12.9” and 10.5” form factors. It’s why Phones get “bought” on a subscription now, and why most people get a new one at least every two years. But with each device generation come new features, so the environment for apps is changing at a rather rapid pace, and we need to keep up. Our users expect us to always perform well. All those adjustments, as small as they may seem, continuously take time and energy. Subscriptions are the only sensible match for these new cycles.
- One common issue with traditional software models is that the apps will at some point stop functioning. Users tend to update their computers first, only to then find out about the compatibility of their apps. As a consequence, files that have been created with apps purchased a couple of years ago will likely not open anymore — due to the apps having become incompatible with their device or OS. With subscription, however, even if a user stopped subscribing, the app will still get updates and it will be possible to open and retrieve all texts even in years to come.
In addition to those “big” arguments from above, there are bunch of smaller advantages, too. One example: if you use Ulysses via the Setapp subscription, we will now automatically unlock the iOS app as well. And the way we modeled and priced our subscription plans, now much closer resembles the value each plan provides, than a “pay once” model ever could.
Last but not least, subscriptions are the only model that truly address the “peace of mind” aspect from the beginning of this post. That old graph from before will hopefully soon look like this:
Conclusion
So many upsides, and we believe there are very few downsides. App subscriptions are a bit unpopular at the time of writing, but we think they clearly are the way forward, at least for our kind of app:
A complex, multi-platform productivity app.
For us as developers, it’s important that we have the freedom to experiment and try things out. Recurring payments give us planning security and enable deep thought. We are less rushed to release features, and we are more inclined to iterate on them, if we do so on a sound financial basis. And finance we must — after all, we have a bunch of families to feed. If you’re a parent yourself, you will know that a family is enough of a task in and out of itself, and does not need any additional uncertainties.
Oh, and planning security allows us to staff up. Meaning more features, higher quality, faster support and greater help. Did I say more features? I meant… “better features”. Of course I did.
This article was first published on Medium.