Built for Us, Not for Them: The Artists Quietly Coding the Tools That Actually Matter
Photo: Usmanagm, CC BY-SA 4.0, via Wikimedia Commons
There's a version of technology that gets announced at conferences, backed by people in fleece vests, and rolled out with a press release about disruption. And then there's the other kind — the kind built in shared studio spaces and community centers, passed around through Signal chats, quietly powering things that actually matter to the people using them.
The second kind doesn't get a TechCrunch writeup. But it's everywhere once you know where to look.
The Problem With "Solving Problems"
Venture capital loves the word "solution." Every pitch deck promises one. But solutions, in that world, are only worth building if someone can eventually charge for them — or sell the whole operation to someone bigger who will. That filter quietly shapes what gets made. The result is an industry that's very good at helping people hail rides and very bad at, say, helping tenants organize against a landlord, or giving a rural health clinic a way to manage patient intake without paying for enterprise software they can't afford.
Artists, it turns out, are unusually good at noticing this gap. Partly because they've always had to build workarounds. Partly because their practice already involves asking the question: what would this look like if it wasn't optimized for someone else's benefit?
The answer, increasingly, looks like code.
Small Tools, Real Stakes
Take the cluster of projects that have emerged around tenant and housing organizing over the last decade. Legal aid organizations and tenant unions across the country have quietly adopted tools built by people who straddle the line between artist, activist, and developer — people who got tired of watching community groups try to wrangle Google Sheets into doing the work of actual organizing software.
These tools don't have venture backing. They don't have growth roadmaps. They have GitHub repositories and mailing lists and, sometimes, a single overworked maintainer keeping everything running on a shoestring. What they also have is a design philosophy that starts with the user's actual situation — often someone with limited tech access, limited time, and a real urgent need — rather than an assumed baseline of high-bandwidth connectivity and digital fluency.
That starting point changes everything about what gets built.
Open Source as a Political Act
The open-source software world has its own complicated politics — it's not automatically radical just because the code is free to view. But in the hands of artist-technologists who are thinking explicitly about power, open source becomes something more deliberate. It means no single company can buy the tool and lock it down. It means communities can adapt it for their own context. It means the infrastructure doesn't disappear when a startup runs out of runway.
Projects like Ushahidi — originally built to map post-election violence in Kenya — demonstrated years ago that tools designed for crisis and community could travel globally and get repurposed in ways their original creators never anticipated. That model of adaptable, community-owned infrastructure has influenced a generation of builders who are less interested in owning a platform than in making sure the platform can't be taken away.
In the US context, this plays out in everything from mutual aid coordination tools built after Hurricane Harvey to archival platforms created specifically for movements that have reason to distrust corporate cloud storage. The throughline is the same: build for the people who need it, make it open, make it durable.
When Art and Infrastructure Blur
Some of the most interesting work happening right now doesn't announce itself as either art or technology — it just exists at the intersection and dares you to categorize it.
Consider the experimental radio networks that artist collectives have built in cities like Detroit and Los Angeles, using low-power FM infrastructure and open-source streaming software to create broadcast ecosystems that bypass commercial licensing structures. Or the mesh networking experiments happening in neighborhoods where internet access is expensive and unreliable — projects that are simultaneously technical infrastructure, community organizing, and a kind of ongoing conceptual art about what it means to own your own communications.
Or look at the data visualization tools being built by artists working with environmental justice organizations — tools that translate raw EPA data or industrial permit filings into something a community meeting can actually use. The code is functional. The output is political. The process is, in its own way, a creative practice.
None of these projects fits neatly into a category. That's part of the point.
The Maintenance Question
Here's the thing nobody wants to talk about: building the tool is the easy part. Keeping it running is where the whole enterprise gets hard.
Corporate software has support teams and update cycles and the implicit promise that someone, somewhere, is being paid to make sure it still works next year. Community-built tools often have none of that. The person who built the thing has a day job. The documentation is incomplete. The server costs are covered by donations that may or may not show up.
This is a genuine crisis for the ecosystem, and artist-technologists are wrestling with it in real time. Some projects have found homes inside universities or nonprofits that can provide institutional stability without dictating direction. Others have experimented with cooperative structures — treating the software project like a worker-owned business, with dues-paying members who have a stake in keeping it alive. A few have built in deliberate sunset clauses, deciding in advance what happens to the tool if the community around it dissolves.
None of these solutions is perfect. But the fact that people are thinking about them at all — asking who owns this, who maintains it, what happens when the founder burns out — reflects a maturity that a lot of venture-backed startups never bother to develop.
What This Actually Looks Like
If you want to find this world, you're not going to find it at a product launch. You'll find it at the overlap of a few different scenes: the digital rights and tech justice space, the experimental art world, the mutual aid networks, the labor organizing ecosystem. People move between these worlds carrying ideas and code and connections.
The tools they build tend to be unglamorous. A database for tracking community land trust applications. A simple encrypted messaging setup for a legal observer network. A website template that lets a neighborhood association maintain their own site without paying a developer every time something changes. Small things. Crucial things.
The invisible infrastructure doesn't look impressive from the outside. It looks like a GitHub repo with 47 stars and a README that hasn't been updated in eight months. It looks like a mailing list thread where someone is asking if anyone has bandwidth to fix a bug. It looks, honestly, like a lot of work done by people who aren't getting enough credit for it.
But it's holding things up. And the people building it are doing something that the tech industry, for all its resources and ambition, has mostly failed to do: starting with what communities actually need, and building from there.