Working With Community Partners

A civic tech project can have a strong team and good technology, but still miss the mark if it isn’t connected to the people experiencing the problem.

Working with a community partner helps keep the project grounded in a real need. A partner might be a nonprofit, government office, community group, or another organization connected to the people the project is intended to serve.

This guide is for project leads and contributors working with partners. If you’re an organization bringing a new idea to Civic Tech DC, start with Build a Project.

Start With the Problem

Before discussing what to build, spend time understanding the problem from the partner’s perspective. Ask what is happening now, who is affected, and what they’ve already tried.

A few useful questions:

• What problem are you trying to address, and how does it affect your work or community?
• Who would use or benefit from a solution?
• What do people do today instead?
• What has been tried already?
• What would a useful first outcome look like?

Try not to assume that a website, app, or dataset is the answer. Sometimes research, clearer information, or a change in process may be more useful.

Set Expectations Early

Civic Tech DC projects are volunteer-driven. That means we cannot promise a particular timeline, a dedicated team, or ongoing technical support.

Before work begins, make sure the team and partner understand:

• Point of contact: Who can answer questions and give feedback?
• Decision-making: Who can confirm that the work meets the partner’s needs?
• Time and availability: How often can the partner meet or respond?
• Scope: What is the team trying to accomplish first, and what is outside the project?
• Ownership: Who will use, manage, and maintain the work when the volunteer project changes or ends?

These conversations don’t need to be formal, but the answers should be written down somewhere the team can find them.

Involve the People Who Will Use the Work

A partner can help explain the problem, but the people who use a service or tool may have different experiences.

When possible, ask the partner to connect the team with users or other stakeholders. This could involve interviews, reviewing an early design, testing a prototype, or giving feedback on research findings.

Be respectful of people’s time. Explain what you’re asking for, how their feedback will be used, and what the team can realistically change. Don’t collect information you don’t need, especially sensitive personal information.

Keep the Relationship Active

Partners should not hear from the project only when the team needs something. Agree on a simple communication rhythm that works for both sides.

A short update might cover what the team has worked on, what decisions are needed, what has changed, and what comes next. Share unfinished work when feedback could help the team avoid going in the wrong direction.

If priorities change, say so early. The same goes for delays, volunteer capacity, or concerns about whether the proposed solution is useful. It’s better to revisit the scope than to keep building something nobody needs.

Plan for What Happens Next

A project doesn’t become sustainable just because the first version is finished. Talk with the partner about what happens after a milestone, launch, or handoff.

Will someone maintain the tool? Does the partner have access to the documentation and data? Is the work ready to be used, or does it need more testing? If there isn’t a realistic plan for ownership, the team may need to reduce the scope or reconsider what to deliver.

See Project Cycle for how teams evaluate progress and Maintain or Close a Project for planning a transition.

A good partnership is more than a request for volunteers to build something. It is an ongoing conversation about the problem, the people affected, and whether the work is actually helping.