The Design Issue

In April 2013, Leo O’Farrell, director of the CalFresh food-stamp program in San Francisco, received a note from Trent Rhorer, the city’s executive director of human services. It was about a deal Rhorer had just struck with Code for America, a civic-tech nonprofit that places young experts with local and state governments. In return for a $255,000 fee, the city would get 15-month commitments from fellows, as they’re called, drawn from Code for America’s ranks of engineers, designers and product managers. Their job would be to create, according to the language of the contract, a “web-based technology solution to increase the ability of the lowest-income San Franciscans to access public benefits.” Rhorer knew that a young staff member in O’Farrell’s office, Tiana Wertheim, had distinguished herself working on these kinds of “digital delivery” projects; he wanted O’Farrell and Wertheim to meet with the fellows and see what they could come up with.

O’Farrell, who has been involved with government food programs since graduating from college nearly three decades ago, understood why his office would be a promising target for this kind of tech push. California’s food-stamp participation rate, roughly 50 percent of eligible residents, was one of the lowest in the country, and the bureaucratic friction in the application process deserved at least some of the blame. Enlisting technology’s aid made a lot of sense: More than three-quarters of Americans who earn less than $30,000 a year now use the internet, and Obamacare has ushered in a new generation of social-service clients who grew up on their smartphones and expect to interact with government the same way they do everything else. Yet CalFresh — in contrast to the Silicon Valley companies in the neighborhood, where teams of designers, product managers and data scientists cater to their online users with intense precision — offered a poor “user experience” for clients on its digital channels. It lacked text or email support; its website didn’t work well on mobile devices. These were just the sorts of problems that Code for America fellows figured they knew how to solve.

Over the next year, the fellows started spending time at CalFresh. Their first months were spent interviewing employees and clients, trying to get a sense of what needed their attention. An early project involved texting reminders to clients whose benefits were about to expire. They also introduced a tech-industry practice called “dogfooding,” which means consuming and hence evaluating your own product. One of the things they dogfooded was CalFresh’s website, which evolved from a precursor site called BenefitsSF. BenefitsSF was a victim of its own competence: A well-designed, user-friendly site intended to serve San Franciscans applying only for food benefits, it was deemed “shovel ready” by the federal government during the Great Recession and made to expand to process applications for MediCal and Medicaid in 17 other California counties. “We built this boutique, and it got turned into a Walmart,” O’Farrell told me ruefully. The resulting site, MyBenefits CalWin, had dozens of screens and instructions for users that seemed to have been cut and pasted directly from some legislative handbook.

The fellows soon discovered that an external vendor, Hewlett-Packard, had been contracted for years to maintain the site. A bigger obstacle to remaking MyBenefits CalWin would have been negotiating the cooperation of all 18 counties that used it. But one fellow, Jake Solomon, had an idea. The only information legally needed to submit a complete food-stamp application, he had learned, was a name, an address and a signature. Code for America could work around MyBenefits CalWin and build its own simple website just for CalFresh applicants. At the very least, this would make for a good proof of concept, a way to show various government officials that social-service delivery could be, in Solomon’s words, “dead simple.” In 2014, after his fellowship had ended — he was still affiliated with Code for America — Solomon pitched this idea to his colleague Dave Guarino one afternoon, and they coded a prototype over the next few days.

The following week, Solomon and Guarino gave a demonstration at O’Farrell’s office. Guarino handed a phone with the prototype on it to O’Farrell, who filled out an application in a few minutes. With its clear language and big buttons, it felt slick, like Twitter or Facebook, not kludgy, like most .gov sites. O’Farrell was impressed. “This could be a game changer,” he said. “Go for it. We like it.”

And so they did. Within a month or so, Solomon and Guarino, along with a third Code for America colleague, a designer named Alan Williams, turned their prototype into a full-fledged website; within 18 months, pilot versions were running in San Francisco and five other California counties. Today Code for America considers GetCalFresh, as the website is called, to rank among the most successful projects in its program’s five-year history. But what its young creators discovered, however, was that while proofs of concept are easy — demonstrating feasibility is common enough in civic tech — building a full-fledged anything for the government is hard, and not solely because of technical hurdles like security or bureaucratic ones like overextended I.T. personnel. When your goal is to make public benefits more accessible to low-income Americans, you are beholden to all sorts of things — laws, institutions, budgets — other than low-income Americans.

“My biggest lesson this year was that local governments are constrained,” Solomon wrote in a blog post. “They’re constrained by a complex web of local politics, state legislation and federal laws. The constraints cascade downhill, as does the responsibility.”

Code for America can trace its origins to a family reunion. That was where Jennifer Pahlka ran into her best friend’s husband, who happened to be an aide to the mayor of Tucson. For months afterward, the aide tried to convince Pahlka to tap her tech-world connections on his behalf. Pahlka then made her living flying around the country organizing tech conferences and putting on big-budget events for game developers, and some of that project-manager steeliness remains evident in her bearing. “No web 2.0 developer is going to work for the government,” she told the aide. “That’s not going to happen.” This was 2009. It was conventional wisdom in the tech world that the public sector was so slow and inefficient, so bureaucratically hidebound, that it wasn’t worth collaborating with. But the idea stuck with her, as she wrote in Code for America’s first annual report, “that the same talent, passion and skills that have connected us and made our lives easier through web and mobile technologies could also reconnect us to the institution designed to benefit us all: government.”

Pahlka founded Code for America that year, and in January 2011, with $225,000 from Boston, $275,000 from Philadelphia and $50,000 from Seattle, the fellowship program got underway. Nineteen fellows joined up that first year, and a model was quickly established: Cities would apply annually to “partner” with Code for America on themes — community health, for instance, or public safety. Fellows would be based in San Francisco but spend roughly half their time in partner cities, promoting close collaboration between local governments and the San Francisco start-up scene. At the end of the first year, the fellows came back with 70 interfaces for various government data sets and 21 apps, including Adopt-a-Hydrant, whereby Boston residents picked a fire hydrant to shovel clear after heavy snowfalls. For the next year, Pahlka raised another $1.5 million from Google’s nonprofit arm, Google.org, which enabled her to expand the program to eight cities and 26 fellows.

Then healthcare.gov happened. Immediately after the debut of President Obama’s online marketplace for health insurance, the White House realized that the site, despite a lead time of two years and spending of more than $300 million, was a disaster. Users almost inevitably encountered “error” screens; only 30 percent of them could complete an application. Over Christmas 2013, a team of engineers from the private sector fixed the site, in an effort that many young Obama supporters in the tech world soon came to regard as a sort of “Apollo 13” for the digital age. That triumph gave strength to the sense that a new path now existed. For years, earnest young graduates interested in white-collar public service had few choices but policy work — to take jobs on Capitol Hill, at the Brookings Institution, in academia. But for those with tech skills, the appearance of Code for America and similar ventures promised a different option, one that would produce quicker results. You could join the Veterans Affairs Digital Service and make a digital appointment system, cutting back waiting times at Veterans Affairs hospitals. You could go to Nava, a civic-tech design start-up, and streamline government websites. You could participate in a civic hackathon and take previously inaccessible parks data to the public. You could code a better food-stamp application over the weekend and have people filing it by Monday.

In 2013, Code for America had nearly 30 fellows — selected by competitive application — working on behalf of 10 partner cities. Its annual operating budget was $7 million, more than half of which came from private grants. Pahlka often found herself on the road, giving talks and courting donors. Her pitch was simple: Use technology to make government better. What exactly she meant by that could be hard to parse, but the apps she cited and the anecdotes she shared were compelling, with a folksy, community-driven appeal. (Take care of your neighborhood storm drain!)

Solomon, Guarino and Williams, part of the 2013 class of fellows, were initially assigned to different cities and themes. Solomon went to the Human Services Agency of San Francisco. Before Code for America, he worked for the RAND Corporation on health policy; before that he was at Palantir, a Silicon Valley data-analytics start-up that created software for intelligence services and other clients. Guarino, a software developer and policy wonk who had spent time at the California Health Benefits Review Program, devoted his fellowship year to building an app that allowed residents in South Bend, Ind., to report on the conditions of vacant and abandoned properties. Williams, a designer, built digital trail maps for parks in northeast Ohio. As a junior at Tulane during Hurricane Katrina, he had seen the storm sweep across Lake Pontchartrain and then flood much of New Orleans. “I watched government fail on so many levels,” Williams says. “In this very visible, physical way, where levees failed, but also the soul-crushing process that people went through afterward to get FEMA support.”

The three young men had an easy rapport from the start. None of them fit the stereotype of the Silicon Valley engineer. Each majored in a social science — Solomon in economics, Guarino in political economy, Williams in English and political science. I saw them at their most animated in long conversations over Mexican takeout, talking about John Rawls and social contracts and the unfortunate amount of discretionary power wielded by street-level bureaucrats. For them, and for many of their Code for America colleagues, technology was a means more than an end, a lever with which they could move people’s lives toward the good. While their peers in Silicon Valley wanted to play with cool new programming languages for the sake of playing with cool new programming languages, Solomon, Guarino and Williams, it seemed, found their motivations elsewhere. “I care about helping people, period,” Guarino told me.

In the months after they presented their successful demo to O’Farrell, the Code for America team sought a balance in their design between simplicity — not asking for so much information that users would get frustrated — and utility. While their prototype application featured only three prompts, in practice you couldn’t actually be approved for food stamps with just a name, an address and a signature.

The normal process worked like this: Once an application was received — whether delivered in person, online or via fax — and entered into the database, the CalFresh office in the applicant’s county would schedule an interview, to be held either over the phone or in person. At these sessions, eligibility workers, whose job is to determine whether clients qualify for social services, review documents like pay stubs, utility bills and identity cards. Eligibility is set at 200 percent of the poverty line, or roughly $41,000 in gross income for a family of three, but subject to a host of caveats; in granting exceptions to these caveats, eligibility workers exercise a great deal of discretion. They can choose to overlook missing documentation or demand additional receipts. They can verbally elicit information omitted from the application.

The Code for America team’s plan had always been to leave the scarier stuff off the website — questions like, “Have you ever traded food stamps for explosives?” or “Have you ever committed a felony?” Those questions could be answered during the live interview. The key was to settle on how much information to ask for at the start. Require too much, and users would be put off and give up; too little, and the eligibility workers, who preferred more details rather than fewer, would complain. In the end, the team settled on a compromise. After the user submitted a name and an address, two choices would present themselves: to continue filling out the rest of the application or to “Stop working and submit application now.” Clicking the second option would lead to another page and the warning: “Are you sure you want to submit right now? Since we only know your name and address, it will be hard to process your application. Instead of finishing it on the phone, we will have to send you paperwork in the mail.”

The main technical challenge confronting the team followed directly from Solomon’s initial flash of insight to create an independent site. Because GetCalFresh wasn’t actually replacing MyBenefits CalWin, but was instead just offering an alternative point of access, they still needed to work with its existing infrastructure, which lacked an A.P.I., or application programming interface. Modern websites consist of a front end, or web page (what a user sees on the computer screen); a back end (a database and a server that hosts it); and usually an A.P.I. that sends data between them. We all regularly rely on things that function like A.P.I.s in the physical world. Say, for instance, you want to get takeout from your favorite Chinese restaurant. In this analogy, the front end would be your phone, the back end is the kitchen and the A.P.I. is whichever restaurant employee relays your order to the cooks. She’s how you place an order of dumplings, cancel that order or modify it to include sweet-and-sour soup.

In software development, A.P.I.s allow coders to change front-end or back-end components easily, while leaving the core of a program intact. The lack of an A.P.I. for MyBenefits CalWin meant that GetCalFresh, however great it looked, couldn’t actually put any information into the earlier site’s database. The state would not officially know about any of the applications it received; it wouldn’t even know where to send a check. So the Code for America team’s members, when they received an application through GetCalFresh, needed to figure out a way to get that information into the MyBenefits CalWin system.



1 Restaurant Inspection Partnering with Yelp, the repository of crowdsourced reviews of local businesses, San Francisco and New York created a standard way for cities to add available restaurant-inspection data to Yelp’s restaurant pages.

2 CyclePhilly The Delaware Valley Regional Planning Commission partnered with Code for Philly to collect data from Philadelphia bicyclists’ daily riding habits, which were then used to help determine where to locate new bike routes.

3 Jail Conditions A dashboard created by Code for America and the city of Louisville lets judges and officials monitor jail conditions in real time and respond to overcrowding.

4 Vets.gov Ad Hoc, a start-up founded by people involved in the healthcare.gov rescue effort, is working with the Department of Veterans Affairs to create a simplified site for benefits.

5 Voteplz.org This nonprofit consolidates information about voting in all 50 states and Washington. A founder, Sam Altman, is president of Y Combinator, which invests in and supports start-up companies.

6 Go L.A. A mobile app that shows users the different ways — and costs — of getting from Point A to Point B in Los Angeles, it includes both public transportation and private options like Uber and Lyft.

7 Street Bump A mobile app built by the Boston mayor’s office that collects G.P.S. and accelerometer data from drivers’ phones, which is then used to determine whether a bump was a pothole that needed filling.

8 Outdoor Alabama To improve on mail-in surveys that had been in use for 30 years or more, this mobile app was created to, among other things, let users report their game harvests of deer and turkey to Alabama’s Department of Conservation and Natural Resources.

The first attempted solution — what they showed Leo O’Farrell at the demo — was a fax hack. Guarino’s program took an applicant’s information submitted through GetCalFresh and simply converted it to a fax that was sent to the CalFresh office. Clerical workers there would then manually re-enter the information into MyBenefits CalWin’s back end. That is, employees were the A.P.I. This reduced the complexity for users, but it increased commensurately the workload at CalFresh. (A resulting fax was often too blurry to read.) Another fix tried by the Code for America team was to take an application from GetCalFresh and send it to the CalFresh office as an encrypted email. This solved the legibility problem, but clerical workers were still needed to put the information into the old back end by hand. Both processes led to complaints about the manual labor.

In April 2015, Guarino, while on a trip to Utah with Solomon and Williams, finally came up with a workaround. If the problem they faced was relying on people to manually enter information into the database, why not just write some code to take care of that part? Guarino used a technology called Selenium WebDriver that mimicked a user’s activity on a website. Playing the role of the applicant, the webdriver would go to MyBenefits CalWin’s front end and fill in each question using the information collected through GetCalFresh, then click “next.” This was not exactly best practice when it came to coding: Webdrivers are used primarily in testing web applications, not in their actual operation. Because the webdriver couldn’t catch all errors, when someone mistakenly submitted an impossible birth date, for example, or a nonexistent ZIP code, that information would trigger an error when it was entered into the legacy system. A human being would then have to correct the information from that faulty entry by hand.

Williams worried, when giving demonstrations to county representatives, that the whole process would seem amateurish to them, the way it sometimes did to him. But he came to realize that the existing systems used by CalFresh staff members tended to be far more cumbersome and time-intensive than his inelegant webdriver. They didn’t see the absence of tests and logs, the redundant code, the inability to deal with errors like missing information gracefully. He recalled a presentation at which the projector was broken, so the audience gathered around his computer. When he ran the webdriver, a new browser window opened up straight away to the legacy website, and the applicant’s data automatically appeared, as if typed in by unseen fingers. Williams describes it as “a magical moment.” The genius of the webdriver was that it didn’t require clerical workers to do anything different: no encryptions, no new data entry or software systems to deal with. It did exactly what workers at food banks and community-based organizations already did — fill out the legacy application on behalf of clients — except faster. It reinforced technology’s most basic power: the ability of automation to eliminate boring and repetitive tasks.

By fall 2015, the GetCalFresh website had been running for about a year. The initial fellowships of Guarino, Williams and Solomon were long over, and they were now Code for America employees; the nonprofit was continuing to fund their work on GetCalFresh from general operating funds. But this arrangement couldn’t continue indefinitely. The team wanted not just to keep the site going but also to improve it and expand its reach, both of which would require hiring more engineers. Who would be willing to pay for that?

No one had a good answer, including the executives at Code for America. By many measures, GetCalFresh had surpassed all of the nonprofit’s previous projects, and Code for America now found itself in unfamiliar territory. It had typically presented its projects as proofs of concept, but many of them, as one of the organization’s officials later admitted in a blog post, lacked “consistent paths to sustainability.” By that fall, out of the many dozens of apps created by Code for America fellows, fewer than 10 had found enough support to justify being spun off into start-ups. Many of them had not been updated on Github, the website where most collaborative coding projects are hosted, in months.

As Solomon, Guarino and Williams saw it, a couple of obvious paths lay before them. The first was to solicit funds from traditional philanthropic sources. The second was to become a government I.T. vendor and sell to other counties and states. Neither path appealed to them. Donor funding, while probably necessary in the short term, seemed unsustainable in the long term — especially because, under the reigning Silicon Valley ethos, even philanthropic tech projects are expected to present a business model. Government I.T. vending work, on the other hand, was self-sufficient but uninspired. It was limited, by definition, to what was imagined under any given contract. “It abdicated responsibility for anything outside the software,” Williams says. And for all of Code for America’s beliefs that tech could serve as a lever for good, the bad code plaguing the public sector was rarely the only problem with a particular program; it would be a hollow improvement to give CalFresh a better application site without, say, making sure that reminder letters were sent out before an appointment or that the customer-support lines were adequately staffed.

As the months passed and the financing remained unresolved, the team submitted proposals to several organizations — including Molina Healthcare in Long Beach, Calif., from which they sought $3 million over three years, characterizing their project as a preventive-health measure. But their reluctance to work for the government seemed to come from some deeper motivating force. In the beginning, I wondered whether it had to do with prestige. Public employees can get stuck working in rooms with ugly linoleum floors writing memos that may never be read; I.T. vendors, meanwhile, are the equivalent of enterprise software sales. Perhaps either fate seemed at odds with the team’s self-image.

But in talking to them, I found that their worries seemed to revolve less around social standing than around effectiveness. Having been exposed to the way government operated, they saw a decision-making system in which the status quo always wins. The lengths to which the team would have had to go to modify the legacy site, MyBenefits CalWin, was one example. The process to amend a notice of action — a letter informing CalFresh clients of changes in their eligibility, for example — was another. “When you work for the government, ties go to the county, ties go to the state,” Solomon told me. At the moment, the Code for America team controlled almost every aspect of GetCalFresh: If they wanted to, say, experiment with live chat for customer support, they could. That freedom would be curbed if they began collecting paychecks from the state.

At the beginning of this year, I met up with Solomon at the San Francisco Health Plan Service Center in the financial district. The organization was holding an open-enrollment day, during which residents could sign up for a variety of social services in one stop. Solomon thought it would be a good chance for me to see GetCalFresh in action.

“You don’t speak Cantonese, do you?” he asked me as soon as I entered. I did not, alas. Many of the clients of the San Francisco-Marin Food Bank were non-English speakers, and among them Cantonese was the most common native tongue. But the Cantonese-speaking employee who was supposed to be on duty that morning had called in sick. Liliana Sandoval, the food bank’s senior program manager, was scrambling to find a replacement.

A half-hour later, Sandoval and the replacement arrived, dragging a large file folder between them. His name was Calvin Yan, he worked for the San Francisco-Marin Food Bank and, thankfully, he spoke Cantonese. They pulled out a pair of Microsoft Surface tablets. “Go to demo.GetCalFresh.org,” Solomon instructed. The landing page for GetCalFresh showed a glossy image of an Asian woman holding a toddler and standing in front of the produce aisle in an unidentifiable grocery store. At the top, it read: “Get extra money for groceries every month. Take the first step. Apply for CalFresh in 10 minutes.” In the footer: “GetCalFresh.org is a service delivered by Code for America on behalf of the people of California.” The favicon, the tiny image that appeared in the browser tab space when you navigated to the site, was a federal building with Corinthian columns and the symbol for Wi-Fi overlaid on the roof.

Yan flipped through the screens. “Oh, this is really short,” he said.

“Yup,” Solomon said, satisfied.

“It’s been a while since I’ve done this,” Yan said, before asking if eligibility was still at $1,900 per month.

“No,” Sandoval chided. She tossed him a San Francisco-Marin Food Bank resource guide. “You should be fine. The only thing might be sponsors.” Sponsors backed immigrants, making them financially responsible for the new arrivals, but in practice they could be difficult to track down. Sometimes food-stamp applicants said they hadn’t had contact with their official sponsors in years.

At 10 a.m., the doors opened, and the first clients arrived: an attractive young couple, the man blond and beefy, the woman dark and wide-eyed. Each wore a backpack. Sandoval began speaking to the woman in Spanish. What was her monthly income? How many people in her household did she regularly shop for groceries with? Were any of them students? The woman reached out and touched her boyfriend’s arm. Sandoval switched to English. How many classes was he taking at city college? Three, he said. Did he know how many credits that was? He didn’t. There was a meek, quiet pause. “Would it be helpful if I found out?” he asked.

The issue, Sandoval told him, was that full-time students were ineligible for CalFresh, although there was a long list of exceptions — he could be eligible, for instance, if he had kids. He shook his head. No kids. Then he should probably go to the registrar and confirm his status, Sandoval said. Meanwhile, she would submit a CalFresh application for his girlfriend and refer them to a food pantry in their neighborhood.

Sandoval turned to Yan. “Can you pull up the food-pantry locator?” she asked. Another in-house civic-tech team had put together a search tool for food pantries.

“Which neighborhood?” Yan replied, typing on the Surface.

“North Beach,” the woman answered.

Yan flashed her a smile. “My neighborhood. O.K., the bad news is that there aren’t too many options. But the good news is that there is a food bank just around the corner from your building. It’s not in the search tool.” He tapped his temple. “But I know it because it’s just down the street from me. I’ll write down the address for you.”

Sandoval continued: “Once a week, you can go and pick up a bag of groceries.”

“You can pick what you want?” the woman asked.

“Yes, it’s a 30-pound bag, more than 15 pounds of which is fresh produce, and then the rest, staples.” She said they would hear back about their application in a few weeks. The couple shrugged on their backpacks. They thanked Sandoval.

After the couple left, everyone waited. A good 45 minutes went by. No one else showed up. After noon, Solomon and I went to grab lunch. In all of our previous meetings, Solomon had projected an unrelenting positivity bordering on pretense. Today he seemed tired, less guarded. “Just think about if every person from all those organizations — their energy were redirected toward software development,” he said. I pointed out that not everyone had the skills for software development. And in any case, the event suggested the limits of technology. Sandoval’s Spanish skills, Yan’s local knowledge — these were the things that the technology, at least as of now, had yet to replace, and their softening effect called to a mind an earlier line from Solomon himself, that “stigma was created or eroded at the point of service delivery.”

As we waited for our sandwiches, Solomon got some bad news he’d begun to expect: The $3 million they were seeking from Molina Healthcare — which could have kept their effort to expand GetCalFresh going — had been rejected because of restrictions on what the company could support.

“What else do you have in the pipeline?” I asked.

“Right now, nothing,” Solomon said. “C.F.A. has been extremely generous, but they can’t just let us carry on without strategic funding and strategic partners.” He continued: “We need to figure out whether this model” — digital nonprofits in the social-services sector — “actually works or not.”

As in the private sector, the GetCalFresh team’s work would apparently be judged by people’s willingness to pay for it. To me, this seemed absurd: Wasn’t the whole purpose of government to fund collective projects that are irrational for individuals to take on alone? But Solomon and his team seemed to be caught between a public sector unwilling to finance them and a private philanthropic culture that didn’t see enough value in what they did.

The week after Easter, I messaged Jake Solomon. How were he and his colleagues doing? Did they want to grab lunch next week? He texted back, proposing a diner in SoMa called Citizen’s Band. The dot-dot-dot in the iMessage thread appeared, then disappeared. A few moments later: “Also I may as well mention so as not to totally surprise you — I decided to leave C.F.A.”

Williams and Jaime-Alexis Fowler, then director of marketing at Code for America, joined Solomon for lunch. The waiter who came up to take the orders greeted them like old regulars. “Hey! I thought one of you guys was done.”

“This is his new office,” Fowler quipped.

“My new H.Q.,” Solomon said.

Fowler told me that in the last couple of weeks, a few significant individuals and foundations in Silicon Valley had come forward as sources of funding for GetCalFresh. The money wasn’t in the bank yet, but things were looking promising, despite all the stresses and doubts of the previous months. Some people still believed in improving digital delivery by government — “people who are saying what you are doing is really important and it’s O.K. that you haven’t figured out all the ins and outs of it.”

After the kale salads arrived, I asked Solomon what he was going to do now. GetCalFresh was his brainchild, and this creation process, he had told me before, represented the best job he ever had.

His plan was to dream up similar projects, he said, but as a kind of social entrepreneur. “It just became increasingly apparent that moving forward we were going to be working for the government, which is great. There’s a lot that can be done there. But I think my interests are closer to advocacy work than enterprise software. I need to set up a situation where I’m working for my clients, my users.” He paused. “One of the first things I’m going to do is figure out whether there’s a market for an intermediary in food stamps, the way that people are willing to pay $50 not to deal with the I.R.S.” At the high end, these intermediaries were attorneys and financial advisers. In the middle, they were TurboTax, travel agencies, real-estate brokers. At the low end, of course, there was nothing.

If government interactions are so unpleasant that intercessors are necessary, I suggested, then perhaps we should reform government instead of creating another go-between.

“But I think intermediation is often —” Solomon began.

Williams threw up his hands. “Yes!” he said. “The answer is yes!”

“In many cases it is those intermediaries who are the strongest pressure for reform,” Solomon said.

“They’re also the strongest opponents of reform in some cases.”

“Sure,” Solomon admitted. “Intuit is a great example.” Several years ago, California proposed simplifying tax returns for some taxpayers, but it was opposed by Intuit lobbying.

Williams prodded his food with his fork. “So who’s the most powerful actor?” he asked. “It’s the intermediaries oftentimes. And that can be a force for good, or a force for self-serving interest.”

As lunch wound down, I asked where Dave Guarino was. I hadn’t seen him in a while. “Dave is coding,” Williams said.

Now that things on the funding side were looking up, feature development could begin again. The GetCalFresh team was replacing Solomon with an engineer, Andrew Hyder, who was a Code for America fellow with Solomon, Guarino and Williams in 2013. And once the money arrived, there would be resources for hiring more people too. Williams looked meaningfully at Solomon when he said that.

As it happened, the money would come in, and then some. In April, California declared its intent to award GetCalFresh a two-year “outreach” contract, federal money designed to reimburse nonprofits that helped clients through the application process for social services. It would be the first time California had made an award for web-based application assistance. “We see this as a major first piece of a client-based revenue model — since we will receive reimbursement based on the number of people we help,” Williams told me. He credited, above all, the support of people like Leo O’Farrell and Kim McCoy Wade, who became the state’s new head of CalFresh in 2015. “They’re the ones who really pulled for us,” Williams said. The team’s immediate financial future secured, its members — Williams, Guarino and Hyder (three new hires were planned) — steeled themselves for a long summer leading up to a Code for America summit meeting in Oakland, where they hoped to persuade the various CalFresh directors to try them out.

In my last conversations with Williams, the tone was one of cautious optimism. While the California contract kept GetCalFresh going for another two years and gave the team a sense of momentum, it hardly solved all their problems. A real A.P.I. needed to be built and additional county CalFresh directors won over. Above all, the team needed to show impact — in terms of numbers of users, applications and food-stamp approvals — on the scale that everyone had come to expect from tech ventures. Everything they had done until now — all the prototyping, hand-holding, cajoling, fund-raising — was just preparation. Now the work would really begin.

It’s hard to predict whether GetCalFresh will become the vanguard of a new movement in social services or a forlorn entry in the Internet Archive’s Wayback Machine. But GetCalFresh has made it further than the vast majority of civic-tech projects. It has overcome every kind of crisis — technical, financial, existential — while exposing the distance between the current fetishization of innovation and the reality of implementing even the best ideas within intransigent organizations. Perhaps most important, its team has demonstrated a commitment that goes beyond Silicon Valley opportunism.

“For the longest time, if someone asked me what I did at a party or something,” Williams told me, “I would say, ‘Oh, I’m a product designer,’ or ‘I work in tech.’ Now I say I work in social services.” Even Solomon, the prodigal son, hasn’t strayed far. Back at the lunch at Citizen’s Band, it occurred to me that despite his qualms, the public sector built so little of its own software that even so-called in-house projects were often procured from vendors. So in the end, you could either pay $30 to have someone outside the government handle the food-stamp application process for you, which is what Solomon wanted, or the government would pay a contractor $30 per successful food-stamp application, which is what Williams and the team wanted: a system in which government contracting outside the I.T. world could align with users’ interests. This seemed a distinction without a difference — maybe they’d all work together again at some point.

Solomon smiled at that. “I think over the next year, he’s going to continue to try to recruit me, and I’m going to continue to try to recruit him, and we’ll probably meet somewhere in the middle.” ♦

Yiren Lu is a writer and software engineer based in New York.