This year alone, there have been tens of thousands of songs released about breakups. You don’t need to have a serious letterboxd addiction to name 3 movies about political events. There are more novels about coming of age in New York than one can probably ever read.
We make endless media about our lives and the culture around us. Why don’t we make software about it?
Until recently, the answer was pretty obvious: software was too hard to make. If you were going to spend six months and a lot of money building something, it probably needed to be useful, it needed users, and it had to make back the money you spent on it.
That’s no longer true; you can now make an entire software project in an afternoon for the cost of a cheap dinner.
For the past year, we’ve been trying to figure out what changes. Instead of asking what software could do for us, we started asking what software could say. Could it be funny? Could it capture a feeling? Could it respond to something that happened yesterday? Could you make an app for 500 people, leave it online for a week, and consider that a success?
We attempted to answer this question by making a lot of software. Over the past year, we’ve built and released 80 apps. Some took off, and some were complete failures, but they all taught us more about what makes software compelling when you treat it as a cultural medium instead of a tool.
Here are five things we learned from this experience.
Michel Majerus is one of my favorite painters. His work samples freely from video games, logos, advertisements, and other artists. In most creative mediums, this feels natural: musicians sample, fashion designers reference, writers allude, and so on.
That kind of visible influence has yet to fully reach software. Software still carries the strange expectation that it should emerge from a blank slate, or at least obscure its sources of inspiration.
If we want to treat software as an artistic or cultural medium, we should do what artists do best: notice, borrow, and transform. Best of all, the full breadth and history of software is already at our fingertips. It is all right there on the internet.
What do you notice as you browse? What stops you? What stays with you?
We first saw this principle in practice when Los returned from Japan and combined a Japanese train jingle with graphics from Baby Invasion and a Michel Majerus color palette.
The app pulled from the things he was seeing, hearing, and thinking about, turning his immediate cultural surroundings into software, and making the experience richer in the process.
Consumer software overwhelmingly optimizes for retention and session time. When software doesn’t need to create a persistent artifact, metrics like daily active users and engagement frequency don’t make much sense anymore.
Instead of designing for retention, what if you design for the punchline? A perfect, surprising moment users feel compelled to share. We call this the “screenshot moment”.
When designing an app, we often begin by asking, “What is the screenshot moment?” and work backward from there.
This ensures the app feels alive and cuts through the noise on the feed. The “screenshot moment” is designed to demand a visceral response.
When you make the user the main character instead of a passive observer, you shift them from simply experiencing the story to actually living it. We aim to make apps that put the user inside the moment we’re trying to convey.
How can software help us experience what it might be like to be in someone else’s shoes? How can it let us experience a cultural moment through someone else’s eyes, or give us access to experiences we wouldn’t normally have?
These are questions we explored through apps like Elon’s iPhone, Girl Hinge, and Zoom Timothee. What would it be like to spend Elon’s money, or be a girl on hinge, or be on the Marty Supreme Zoom?
Software gives us something other media can’t: a way to both see and interact with an experience. You can participate in a way you can’t with film, literature, or other media. Instead of just watching something unfold, you get to step inside it.
We try to bake distribution into the software; we don’t want to make something cool and then figure out how to get people to share it. The reason to share should be a part of the product experience.
We ask ourselves: what does someone leave this experience with? It could be a screenshot, or a story, or a result, or something they made themselves. Whatever it is, the experience should produce an artifact that can travel beyond the app.
The artifact should be both the output of the experience and the way the experience moves through culture.
Link Bouquet is a simple example. You assemble YouTube videos, Spotify songs, links, and memories into a digital flower, then send it to someone you love. You don’t send someone Link Bouquet because you want them to try a piece of software. You send them the bouquet you made for them.
There’s no separate growth mechanic required: creation and distribution are the same gesture.
Most media responds quickly to cultural moments. When a movie comes out, people are quoting it, reviewing it, and making jokes about it within hours. A politician says something funny on television, and by the end of the night there are memes about it that have travelled further than the original clip.
Software gives us another way to respond. It can comment on, remix, and participate in culture, and it can now be built quickly enough to join the conversation while that conversation is still happening.
We made Vandalize Friend.com, a website responding to the reaction around Friend’s vandalized New York City ad campaign, in a matter of days. It was online a week before The New York Times published an article about the same phenomenon. It responded at the speed of culture, becoming part of the conversation it was responding to.
Our intuition is to judge software by its longevity: How is it retaining users? What market can this tool grow into? How will it scale indefinitely?
But we don’t expect every song, joke, poster, or magazine to hold our attention forever. Cultural objects can be temporary and still matter.
Software can be made for a particular audience, in response to a particular event, at a particular moment in time, and disappear when the moment passes.
We don’t fully know yet what people will make when software no longer has to justify the cost of making it, and as Los and I have seen ourselves, a lot of it will be bad and wont work.
Either way, we want to find out.
If you’d like to follow us along on this journey, you can subscribe to our Substack and follow us on X (Los, Marc, Danger Testing).
A big thanks to new DT member Rachel for helping put this piece together.