What Team Moulton Taught Us About Building GovTech Right

An Interview with Revere Design Partners, Danielle Leahy and Claudia Runk from the Office of Congressman Seth Moulton.

Every GovTech company says it wants to build for the people who do the work. Fewer are willing to hand those people the pen.

For the past year and a half, Civic has had the opportunity to work closely with the office of Congressman Seth Moulton (MA-06) as an official design partner. This invaluable partnership has been incredibly impactful for Revere’s casework module.

Long before Revere was a finished product, members of Team Moulton were walking us through their workflows, showing us where existing technology created friction, reacting to early ideas, and sending us the occasional “one-off random thought” when something happened during an ordinary workday that a better system ought to handle.

Those conversations did more than improve individual features. They reinforced something that should be foundational to GovTech design.

The people closest to public service are not simply users of government technology. They are experts in how that technology needs to work.

I recently sat down with Team Moulton’s Casework Manager Danielle Leahy and Immigration Casework Specialist Claudia Runk to talk about what the partnership looked like from their side.

Their experience offers a case study in what becomes possible when GovTech companies build with practitioners rather than simply building for them.

Start With the People Who Understand the Work

To understand why Team Moulton became such an effective design partner, it helps to understand how the office thinks about constituent service in the first place.

“Constituent services are really central to everything our office does,” Danielle explained. “The goal has always been to make government more accessible for our constituents, even down to the design of our district office.”

That is quite literal. The district office sits in a storefront in downtown Salem, Massachusetts, with large windows facing a popular shopping area instead of being tucked away in a federal building, hidden from the public.

Danielle explained how this impacts both visibility and trust for constituents in the district: “We take walk-ins, they can pop in, see what we’re working on, see what our office is about.”

That accessibility is also built into how the office operates.

“Constituent services inform every other aspect of the work that we do in this office,” Claudia said. She regularly communicates with Team Moulton’s DC immigration policy team about what constituents are experiencing with federal agencies because those experiences can inform the office’s policy work. As she put it, “constituent voices are like the through line through all of the Congressman’s actions.”

The office has built structures around that principle. The district and DC teams hold a fifteen-minute stand-up every morning to prevent the two offices from drifting into silos. Danielle shares regular casework reports with the full staff. When a caseworker begins noticing a pattern in USCIS cases, for example, that information can quickly make its way to colleagues working on immigration policy or oversight.

And the feedback loop extends outside the office.

The team has held passport fairs with the State Department, annual constituent services fairs, and immigration-specific office hours intentionally located in places where at-risk populations already feel comfortable gathering. Claudia also described her proactive efforts to organize a webinar with the National TPS Alliance after repeatedly hearing confusion from constituents about the status of Haiti’s Temporary Protected Status.

These are not just good constituent-service practices. They are examples of something technology companies need to understand. Frontline staff accumulate knowledge that rarely appears neatly in a requirements document. They learn by doing the work.

Frontline Expertise Is Product Expertise

That distinction of expertise came through particularly clearly when I asked Danielle and Claudia what they felt caseworkers could contribute to a technology project, even if they did not consider themselves “tech people.”

Danielle rejected the premise. “I think caseworkers, or anyone working in constituent services in particular, have a really unique skill set,” she said, “and it’s really important that that is heard as technology evolves.”

“I’m not someone who knows AI. I don’t know how to code,” she continued. But knowing “our strengths and what we work on every day and what we do well” complements the expertise of the people who do understand the technical side.

That is exactly what a design partnership should accomplish.

The practitioner does not need to know how to build the database, train the model, or write the code. Instead, they bring their own subject-matter expertise that should shape the intended systems: what happens when a constituent calls at 4:30 PM on a Friday because their Medicare coverage disappeared; why a caseworker may need to reopen a case that technically looks closed; which pieces of information suddenly become essential when an agency changes a process; and which seemingly minor administrative tasks quietly consume hours of staff time.

Claudia put the point even more clearly: the constituent services team, she noted, has “probably talked to more constituents in our district than most people in our office have.” While policy preference letters are increasingly frequent, caseworkers may manage portfolios of roughly 100 cases at a time. This expertise is invaluable for their work, and for the design partnership.

“We really understand intimately what our constituents’ experience is with government and interacting with government,” she said. “Because we’re on the front lines, we know what things are working well, what things aren’t working well.”

That knowledge is not ancillary to good GovTech design. It is the foundation upon which good GovTech is built.

A Design Partnership Has to Be an Ongoing Conversation

Team Moulton did not participate in one user-research session and disappear until launch. Danielle described the partnership as “really organic,” growing from formal sessions into quick email back-and-forths with iterative feedback.

The process also prompted the office to scrutinize its own operations. Danielle noted that working as design partners forced the team to step back and assess “what’s going well, what needs improvement and what we really need help on,” including places where technology needed to evolve and places where the office itself might adapt its processes.

And then there were those “random” thoughts: “I would send Megan just one-off random thoughts at any time,” Danielle recalled. It’s easy to overlook the small stuff when focused on such a big project, but keeping those lines of communication open meant everyday frustrations that might otherwise seem too insignificant to flag became part of the design process.

It was also vitally important to involve more than just one person in the office. Danielle and Claudia manage different portfolios and sometimes use the same existing systems wholly differently. The correspondence team has still another set of workflows. The legislative team, yet another. What one staffer notices, another may never encounter.

For Claudia, the regularity of intentional conversation with knowledgeable collaborators was part of what made it work. She noted the value of working with designers familiar with existing workflows. Civic came into the partnership with experience in Congress and constituent services, which to Claudia meant the team already understood “what the job is” and “where there are problems.”

But as important as this expertise was, it could never replace the experience of fluid conversation during the build. Something might happen a week after a meeting that suddenly illuminated an issue nobody had thought to raise. That could become an email, a conversation in the next meeting, or eventually a successful design change to the product that feels small in comparison but saves caseworkers substantial time in context.

This is a fundamentally different process than simply asking practitioners what they want once a system has already been designed. Design partners are not a final check on a product; they are part of the process that determines what the product becomes.

The Best Features Often Start With Mundane Frustrations

A clear line running through both the process and this interview is that some of the most important features for caseworkers are some of the easiest things for inattentive designers to overlook.

The clearest examples of how Revere was built to meet the frustrations of modern casework are not flashy AI capabilities. Instead, they are fixes for things that caseworkers should never have needed to spend so much time doing in the first place.

Both Danielle and Claudia repeatedly brought up their frustrations with their current ability to access data on existing CMS platforms. Traditional workflows make it difficult to quickly answer relatively straightforward questions about their own caseload.

Danielle described needing to determine how much money the office had returned to constituents in a particular community over a specific period of time for an upcoming report on the district. She could not simply pull the information herself; instead, she needed help from the system provider. A process which involved filing a help request and waiting on the platform’s service team to respond. While she was careful to note they did eventually return the report, the time lost on what should have been a relatively simple process was evident.

Claudia described a typical process where she manually audits cases to identify patterns across the office’s work: “That’s a huge time commitment,” she said, because staff must review cases one by one and commit hours to identifying trends instead of “actually doing the casework.”

That frustration directly informed the reporting features built into Revere.

When I later asked Claudia what she was most excited to see emerge from the partnership, she immediately pointed to the trends and mapping tools.

“The maps and the trends page is amazing,” she said. Rather than manually searching for patterns, staff can see where requests are coming from across the district and which case types are appearing most frequently.

“We don’t have to manually go in and think about patterns that we’re seeing. It just automatically did it,” she said. “That takes a huge lift off” the mental space required for manual audits.

Danielle explained things a bit more plainly. When asked about her favorite features she had helped design for Revere, she said: “I think it is just making simple things easier.”

Casework does not always progress neatly from open to resolved. Constituents come back. Agencies need another follow-up. A supposedly resolved tax issue returns. Under the existing workflow in most platforms, reopening that conversation can mean exporting information into Outlook, starting another ticket, and manually carrying the history forward.

Danielle told us how frustrating this can be when caseworkers prefer continuing the existing agency email thread. Often, when they are able to reopen and continue a case instead of starting a new case, the agencies respond more quickly and it avoids contributing unnecessarily to their backlog. This feedback was directly integrated into Revere, so that caseworkers can simply reopen a case while keeping its history together.

“It’s just way simpler to just open it back up,” Danielle said.

Neither feature sounds revolutionary, but that is precisely the point. Someone designing casework software from a distance might never identify either problem as a priority. Someone doing the work encounters them constantly.

What Efficiency Is Actually For

It would be easy to tell the story of this partnership as a story about productivity: faster reports, fewer spreadsheets, easier data pulls, and less copying and pasting.

While all of these things hold true, Danielle and Claudia found something just as important during this process.

For Claudia, the promise of Revere is “freeing up mental energy” so that when a caseworker is talking to someone, they can “really be present.” Eliminate enough of the repetitive manual labor, she explained, and “we can really just be present with the constituents and do the important parts of our job.”

Danielle made almost exactly the same point.

“It frees up time, it frees up mental space,” she said. “Being a caseworker takes an emotional toll as well.” People usually contact congressional offices because something has gone wrong. Their Medicare has been cut off. They are afraid of what may happen to their green card. They have exhausted the other avenues they know how to pursue.

“If we can free up that mental space and even time in our schedule,” Danielle said, “we can give more of ourselves to our cases, and we can be more present with every constituent we talk to.”

That is the real purpose of good GovTech. Efficiency is valuable not because government should move people through a system faster. It is valuable because every unnecessary administrative task competes with the human work public servants are actually there to do.

From One Office’s Best Practices to Better Public Infrastructure

The collaborative design process between Civic and Congressman Moulton’s casework team wasn’t just about creating a bespoke platform for one office. Claudia described the larger goal as “integrating those best practices into … a widely usable platform to be used nationally and replicated nationally.”

That idea matters beyond Revere, and beyond Congress.

The people doing government work well have already solved countless problems through experience, improvisation, and institutional memory. They have figured out which workflows work, where constituents fall through gaps, what information staff need at a moment’s notice, and what seemingly efficient processes create barriers for the very people the government is supposed to serve.

Too often, that knowledge remains trapped inside individual offices, or even inside individual staffers’ heads. A good design partnership should create a way to capture it.

Technology companies bring technical expertise. Practitioners bring operational expertise and firsthand knowledge of the people the technology ultimately affects. Neither can substitute for the other. And when GovTech companies genuinely put both in the room from the beginning, the result is not simply a better product. It is technology that is much more likely to understand the government it is being asked to improve.