Anatomy of a Project
CIVIC TECH DC
Section titled “CIVIC TECH DC”Technical Guide
Section titled “Technical Guide”Anatomy of a Project
Section titled “Anatomy of a Project”A practical framework for teams building civic technology
civictechdc.org
Introduction
Section titled “Introduction”Building civic technology is not like building a typical software product. You are working with communities, not just users. You are solving public problems, not chasing product-market fit. You are often working with under-resourced partners, limited timelines, and a volunteer team that may turn over.
This guide walks through the anatomy of a civic tech project from first idea to handoff. It is organized around the questions every good project needs to answer, and the decisions every team needs to make deliberately.
Use this guide when scoping a new project, onboarding contributors, or checking whether your project is on track.
Part 1: The Basics
Section titled “Part 1: The Basics”Before writing a single line of code, your team needs to clearly answer four foundational questions. Projects that skip this step tend to build the wrong thing, lose momentum, or fail to get adopted.
Problem Statement
Section titled “Problem Statement”A good problem statement is specific, grounded in real people’s experiences, and distinct from a solution. It answers:
- Who is experiencing this problem?
- What specific friction, gap, or harm are they experiencing?
- Why hasn’t it been solved already?
- What is the cost of leaving it unsolved?
Example
Section titled “Example”Grassroots organizers in DC collecting petition signatures have no reliable way to validate voter registration status in real time. Manual verification takes hours and introduces errors, leading to invalid submissions that disqualify campaigns from ballot access.
Solution Hypothesis
Section titled “Solution Hypothesis”Civic tech has a long history of teams falling in love with a technology and working backwards to justify it. Avoid this trap. Your solution hypothesis should be a testable claim, not a certainty.
A strong hypothesis sounds like:
“We believe that [doing X] will solve [problem Y] for [person Z], and we will know it’s working when [measurable outcome].”
Problem / Solution Linkage
Section titled “Problem / Solution Linkage”This is worth its own section because it is where most civic tech projects go wrong. Ask honestly:
- Does your proposed solution directly address the root cause of the problem, or just a symptom?
- Does the solution require behavior change from your users? If so, have you accounted for that?
- Is technology actually the right tool here, or would a policy change or process improvement solve it more effectively?
- Would the people experiencing this problem recognize your solution as useful?
Red Flag
Section titled “Red Flag”If you can describe your solution without mentioning the specific people it helps or the specific problem it solves, you probably have a linkage gap.
Success Metrics
Section titled “Success Metrics”Define what success looks like before you build, not after. Good metrics are specific, measurable, and tied directly to the problem you are solving — not just to shipping.
| Weak Metric | Strong Metric |
|---|---|
| The app is launched | 50 organizers validate signatures in the first 30 days |
| Users are satisfied | Partner organization adopts tool as their primary workflow |
| The code is open source | Two other organizations fork and deploy the project independently |
Scope creep kills volunteer projects. Define explicitly what is in scope and, just as importantly, what is out of scope. A tight scope with a real user is better than an expansive scope that never ships.
- What does v1 include?
- What are you deliberately deferring to a later version?
- What will you never build, and why?
Write your scope as a short paragraph, not just a feature list. If you cannot explain the scope in plain language, it is probably not clearly defined yet.
Part 2: The People
Section titled “Part 2: The People”Civic tech is about communities, not just code. Getting the people side right is just as important as the technical decisions — often more so.
Stakeholder Map
Section titled “Stakeholder Map”Before building, map out everyone with a stake in your project.
| Type | Who They Are | What They Need From You |
|---|---|---|
| End Users | People who will actually use the tool day to day | A tool that solves their actual problem with minimal friction |
| Community Partner | The nonprofit, org, or agency you are building with | Reliability, transparency, and a tool they can actually maintain |
| Approvers / Gatekeepers | People who have to say yes for the project to move forward | Confidence that the project is low-risk and high-value |
| Affected Communities | People impacted by the problem or solution, not necessarily users | To not be harmed, and ideally to benefit |
User Research
Section titled “User Research”You cannot build for people you have not talked to. Even a handful of conversations before you start building will save you months of building the wrong thing.
At minimum, before you build:
- Conduct at least 3 to 5 interviews with real potential users
- Ask about their current workflow, not your proposed solution
- Find out what they have already tried and why it did not work
- Identify what a successful outcome actually looks like from their perspective
Key Question
Section titled “Key Question”If you showed your project to the people experiencing this problem, would they immediately understand why it was built for them? If the answer is uncertain, do more research.
Community Partner
Section titled “Community Partner”Every Civic Tech DC project should have a real-world partner — a nonprofit, government office, or community organization that validates the problem and will use or champion the output.
A strong partner relationship means:
- They have confirmed the problem is real and significant
- They have a named point of contact who attends check-ins
- They have agreed to test or adopt the tool after handoff
- They understand this is volunteer-built and timelines are flexible
A partner who is enthusiastic at the start but unavailable to give feedback or access data is a risk. Establish early whether they can commit meaningful time to the project.
Part 3: The Build
Section titled “Part 3: The Build”Once your problem is validated and your people are aligned, it is time to make technical decisions.
Tech Stack Decisions
Section titled “Tech Stack Decisions”Choose boring technology. In civic tech, the goal is a tool that works reliably, can be maintained after handoff, and can be contributed to by a range of skill levels.
When choosing your stack, ask:
- Can a mid-level volunteer contributor understand and work with this?
- Will the partner be able to find someone to maintain this in two years?
- Are there security or privacy considerations that constrain the choice?
- Does the stack match the skills available in the CTDC volunteer community?
Architecture Overview
Section titled “Architecture Overview”At minimum, document:
- The main components and what each does
- How data flows through the system
- Where the major integration points are
- What external dependencies exist
Architecture Decision Records (ADRs)
Section titled “Architecture Decision Records (ADRs)”A minimal ADR includes:
- Context
- Decision
- Alternatives
- Consequences
- Status (Proposed / Accepted / Deprecated / Superseded)
Open Source Requirements
Section titled “Open Source Requirements”All Civic Tech DC projects must be open source.
- Use a public GitHub repository under the civictechdc organization
- Include a LICENSE file
- Write a README
- Use issues to track work
- Document your contribution process
Security and Privacy
Section titled “Security and Privacy”Before you build, answer:
- What personally identifiable information (PII) will this project collect or process?
- Who will have access to that data and under what conditions?
- What is your data retention and deletion policy?
- Are there legal constraints on the data you are using?
- What happens if the system is compromised?
Rule of Thumb
Section titled “Rule of Thumb”If you are unsure whether a data decision is safe, collect less data.
Part 4: The Sustainability
Section titled “Part 4: The Sustainability”A civic tech project that launches but cannot be maintained is not a success.
Maintenance Load
Section titled “Maintenance Load”Estimate:
- How often updates are needed
- Whether data needs active updating
- What breaks after six months of no maintenance
- Whether the partner has technical capacity
Adoption Path
Section titled “Adoption Path”Think through:
- What the partner must do to start using the tool
- Whether adoption requires training or onboarding
- External dependencies
- Who the internal champion is
Common Failure Mode
Section titled “Common Failure Mode”A technically complete project that never gets adopted because no one planned for change management.
Part 5: The Civic Impact Argument
Section titled “Part 5: The Civic Impact Argument”Civic Impact Framework
Section titled “Civic Impact Framework”Your project should answer:
- What specific aspect of civic life does this strengthen?
- Who benefits and in what measurable way?
- Does this increase access, participation, transparency, or accountability?
- Could this cause harm?
- Is this replicable?
Nonpartisan Test
Section titled “Nonpartisan Test”Before launching, ask:
- Could this tool be used across the political spectrum?
- Does this project advance a specific political agenda?
- Would outputs be seen as partisan?
Working with advocacy organizations is fine. Building tools for a single political party or campaign is not.
Project Readiness Checklist
Section titled “Project Readiness Checklist”The Basics
Section titled “The Basics”- □ Problem statement is written and validated with real users
- □ Solution hypothesis is testable and clearly linked to the problem
- □ Success metrics are defined before building begins
- □ Scope is written down
The People
Section titled “The People”- □ Stakeholder map is complete
- □ 3 to 5 user interviews completed
- □ Community partner identified
- □ Partner committed to feedback and testing
The Build
Section titled “The Build”- □ Tech stack chosen and documented
- □ Architecture overview exists
- □ Public GitHub repo created
- □ README, LICENSE, CONTRIBUTING present
- □ PII decisions documented
- □ Security review completed
The Sustainability
Section titled “The Sustainability”- □ Handoff plan written
- □ Maintenance load assessed
- □ Adoption path documented
The Civic Impact
Section titled “The Civic Impact”- □ Civic impact argument is clear
- □ Project passes nonpartisan test
- □ No unintended harms identified
This guide is open source and community-maintained. If something is unclear, outdated, or missing, you are encouraged to contribute. Find us at civictechdc.org or on GitHub at github.com/civictechdc.