If there is one thing most people will learn immediately when they meet me, it’s that I ask what the end is.

As humans, we like to have an end. It allows us to close the chapter, check off a list, and write down our accomplishments. Especially in product design, it is easy to see that the end of a project is the successful creation and deployment of said product.

In product design, the arc is linear:

idea → build → ship → maintain → sunset

But in community building, especially in volunteer capacities, what does that look like? Is there an end? The shape of the work is fundamentally different, with a more cyclical look:

gather → experiment → support → adapt → regenerate (or conclude)

Honestly, that is a little frustrating. When you naturally seek out the finish line, working in a space where one doesn’t exist, at least not in any visible way, feels like running without a destination. It’s hard to know if you’re making progress when there’s no clear metric for what progress even looks like.

But frustration has a way of forcing you to look closer at the work itself. And the more I sat with that discomfort, the more I started seeing it show up in real, specific ways.

I’ve seen this play out in my own work. With Mango Tree, there is the goal to build software tools to detect coordinated inauthentic behavior. But the overarching mission is to “build for a healthier, more robust internet.” What does that actually mean, and how do you know when you’ve gotten there? Civic Tech DC is where that question gets even harder to answer. It’s a community of volunteer technologists in which people show up, they find a project, they build it. When it’s done, it’s done. But the group itself? It doesn’t end. Some people stick around for the next project. Some don’t. New people filter in. The structure of the group is the thing, and the thing doesn’t have a finish line.

Mango Tree is an interesting case by comparison because we actually have a hybrid model. We develop disinformation detection tools (that’s the product side) but we also contribute to broader community output, with the long-term aspiration of a healthier information environment. To help navigate that tension, we have systems in place: sprints, a biweekly cadence, regular project nights. People want to do something meaningful, but motivation ebbs, and that’s very human. The structure gives people the push to actually show up and keep building. And here’s the thing: that capacity doesn’t just benefit the people involved, it feeds back into the work itself. Building the community isn’t separate from building the tool. It supports the tool in its reach, its legitimacy, and its resilience. The two reinforce each other.

And yet, even with those systems in place, the honest answer is that there is an end to everything, but it’s rarely visible from the beginning, and it’s almost never a single moment. It’s not about completing an object but about creating conditions of openness for the community to lean into.

So, in my time with both projects, I learned a better reframing: the goal of a community is not permanence; it’s capacity. And that’s actually a good thing. Capacity can look like people gaining skills they didn’t have before, or relationships forming that outlive the community itself. It can look like norms and practices that spread to other groups, or work that simply would not have happened without the shared space. These aren’t side effects — they’re the point.

A useful mental model for all of this is thinking about communities as infrastructure, as a form of scaffolding. And I have also learned that there is no such thing as a community dying. They end because they completed their role in a particular moment in time. If the capacity they built outlives them, then they did exactly what they were supposed to do.