Software as Business and the Passion Project

There has never been a better time to start a software business. At the same time, for certain types of software, there has never been a worse time to start a software business. The same forces that have made it easier than ever to distribute software to users around the world and collect payments from them, have made those users reluctant to pay, and driven the up-front price they are willing to pay to effectively zero.

This piece is targeted at business-minded software indies, potential future investors in my Lightbox enterprise, and anyone else deeply curious about business models in software, especially productivity application software. It gets wonky in parts, so be warned!

Software applications can be organized in a variety of ways, depending on the functionality that they provide and the interface the user engages with. Most applications can be structured as “web apps,” where the user engages with an interface hosted in the web browser—which can now be quite robust, visually sophisticated, and interactive—and transfers data to and from a remote host. Not only social networking and streaming media, but productivity applications from document creation (and collaborative editing) like Google Sheets and Slides, to “groupware” like shared calendars and project timelines, to visual design like Figma and Canva.

That last category is most relevant to Lightbox, and serves as a useful lens for examining its structuring, delivery, pricing, and the overall business model. It used to be that graphically intensive applications needed to run entirely locally, only synchronizing their (large) files to remote storage, because the web was “too slow and laggy.” Improvements in network speeds, and browser technologies such as Local Storage, the HTML <canvas> element for drawing, and much more sophisticated JavaScript engines for dynamic interactivity, have combined to render that truism false. There are even web-based video editing and markup applications, from SyncSketch to ClipChamp to Adobe Spark. So why isn’t Lightbox being designed as a web application?

The fundamental constraint is input. Computing devices universally offer pointer input, either in the form of the mouse/trackpad on desktop and laptop personal computers, or as capacitive multi-touch on our mobile devices. It is possible to create a drawing app using only these relatively crude inputs, and even to infer more sophisticated intent by clever application of velocity and more, but digital artists expect a high-precision, pressure-sensitive stylus that gives software the ability to more faithfully mimic traditional materials (pen and paper), or interpret their multifaceted inputs in fresh and new ways. For personal computers, this has been via tablet digitizers such as those from Wacom, Huion, or XP-Pen; for mobile devices, the Pencil remains unequaled at this moment. For now, then, Lightbox needs to be a native iOS application because the Pencil only reports its full data to the native system API.

(There is a Working Draft W3C specification for Touch Events, but it has certain lowest common denominator characteristics. For instance, with the native iOS APIs and because of the way it is connected to the iPad, the Pencil reports estimated values for some of its input properties. It then gives you an estimationUpdateIndex which lets you receive more accurate measurements of the properties once available. None of this is represented in the TouchEvents Web API.)

Web applications have certain advantages, such as every user being updated to the latest version whenever you want, but also come with certain expectations such as user-created data being stored remotely and needing to be exported/downloaded to a local device. This expectation allows web app publishers a measure of leverage, in that they can charge a fee to grant users access to the data they create using the app. Canva, for instance, allows you to download your data freely, but charges for access to use its templates, stickers and other elements in your designs. Their ideal user profile is designing a poster or flyer, or other kind of purpose-specific communication and appreciates the access to a library (store) of elements they can incorporate to achieve their goal faster.

Say that user is now tasked with developing a comprehensive brand identity, and applying it to communications across print, web, video (television, film, streaming), packaging… That user also wants the production process to be fast, and is not prepared to wait for the web application to transfer large file assets “to the cloud” or vice versa. The demand for performance at scale drives them to something they can install locally, and use local file assets against, simply periodically syncing to remote (“cloud”) storage. This is the Adobe Creative Cloud model, charging for continued access to the programs—and any data the user has created, locked up in often proprietary formats—and while Adobe has been quite financially successful with it, there was a nontrivial backlash to it when first introduced, so much so that there were multiple Change.org petitions to have Adobe revert the change, or at least make subscription-based access to Creative Cloud an option rather than the only way.

These petitions were unsuccessful, but I firmly believe that the response to this change by Adobe spawned dozens of new design and creative applications, almost all of which opted for the “traditional” pay to purchase/license in perpetuity model: Pixelmator, Procreate, Affinity Photo, Affinity Designer, Sketch, LumaFusion, etc. (Sketch has since modified its perpetual license, with feature updates and non-critical bug fixes gated on yearly renewals.)

Overlapping all of this were changes in user expectations around the price of downloaded and installed application software, driven primarily by Apple’s App Store. While early apps had price points comparable to desktop software of the early and mid-2000s, the competition for audience and the willingness of publishers of substitutes to undercut each other on pricing created a “race to zero,” such that today the average app’s price is barely $1.

One dollar.

And that “sale price” is for a perpetual license, supported by user expectations of regular bug fixes and software updates. From a business perspective, the customer lifetime value (CLV) of an App Store user, based solely on app purchase revenue, is negative. This is why it seems almost every iOS game is now "free to play" with heavy in-app purchases and/or ads. This is also why the majority of productivity applications either want subscription revenue, or require an external service account (which is then tied to subscription or ad revenue).

With Lightbox, my intent is to offer the application core for a flat rate, granting a perpetual usage license that entitles the buyer to receive bug fixes and security updates. I haven't decided on price point yet, but I intend on a discount introductory rate that will ramp up with each release, until I hit the intended long-term price. By doing so, I will be rewarding those users who took an early chance on an unproven, possibly buggier, less feature-complete version of the app by delivering additional value (feature updates) at a lower net price.

Note that I said that was the application core. I intend to offer modular, versioned add-ons priced individually. Not all add-ons will be relevant to all users, so the CLV from doing this will depend on the attach rate—the number and price of add-ons that the average customer purchases. But that is not the real revenue driver. There is an entire second phase of the Lightbox project which is where I believe the business will either prove sustainable long-term, or falter. I'm excited to talk about that, but I don't want to get ahead of myself.

The entire first phase of Lightbox is about delivering value to users, satisfying something of a lifelong passion of mine, and seeing enough financial return to make scaling the business through Phase 2 an attractive, and potentially venture-backable proposition. I'll talk about that in my next update.

Lightbox is a passion project, though, and that significantly distorts my personal calculus. While I am hopeful that my venture hypotheses are proven correct and I can build a sustainable business from it, I am going to build this application regardless, because it is the culmination of an almost life-long preoccupation with making images move and giving that power to artists—myself included.

There's a funny story about my penultimate Cornell Tech "startup studio" pitch eschewing fantastical competitive landscapes with one's own firm conspicuously placed in the upper-right quadrant, and hockey-stick valuation graphs that shoot steeply upward, because I realized that I had to do this regardless of financial return.

This is part of why I ultimately chose not to pursue venture capital at this stage of the journey. Part of why I took a day job, and the specific day job I took, and why I'm working on this as a side project.

I need Lightbox to exist, to come into being the way I imagined it, first, without an investor or advisor suggesting/pressuring me to "pivot" toward some ostensibly more lucrative audience. I need to excise this fixation, and once it is in the world I believe I'll be more objectively able to assess its prospects and grow it accordingly.

Or let it go.