Build, Buy, or Build Together?

The Moment of Decision

Legal help organizations across the country are making consequential decisions about how they will use AI right now. Vendors are pitching AI-powered tools for intake, legal research, document drafting, case management and client communication. Funders and boards are asking programs to explore if AI can make their work more efficient or impactful. Staff are experimenting with Claude, ChatGPT, Copilot, and specialized legal tools on their own. Organizations’ leaders are trying to figure out how to be strategic about all of it.

Many organizations feel like they have two options when it comes to getting started with an AI pilot: either buy an AI tool from a vendor or build one in-house. This article argues that both the ‘buy’ and the ‘build’ path, taken alone, carry serious risks for legal help organizations (including both legal aid and court providers). A third model of ‘building together,’ proven in another domain of legal technology, offers a more sustainable path forward, and one that many stakeholders are interested in exploring. To understand how the field is actually thinking about these choices, the Stanford Legal Design Lab conducted a needs assessment survey of 74 justice professionals in April through June 2026, including executive directors, technology directors, managing attorneys, court administrators, and others involved in AI adoption decisions.² The findings reveal that the legal help field is interested in the potential of AI tools, deeply uneasy about both dominant ‘build’ and ‘buy’ adoption paths, and open to an alternative way of deploying technology safely and strategically.

Where the Field Stands

AI adoption in legal aid, as of 2026, is slowly growing. Across the broader legal industry, including more corporate work, AI usage has nearly doubled year over year, with a growing number of firms integrating AI into their workflows and more individual professionals trying AI out in their work.³ Legal aid and court organizations are following, but at a different pace and with different concerns. Our survey found that the most common AI use cases being explored by justice organizations are staff-facing legal research and writing assistance, consumer-facing legal Q&A, intake triage and referral routing, and document extraction and Optical Character Recognition (OCR). Many respondents are actively exploring how to use AI for these tasks.

But when asked in our survey how they are approaching AI adoption, there are strong indications that this early exploration does not currently have a durable strategy for AI deployment and sustainability. Twenty-three percent of respondents said they are still evaluating and have not committed to a ‘build’ or ‘buy’ approach. An equal 23% are contracting with vendors. Many are mixing approaches (22%). The rest are split between building in-house (15%) and using open-source tools (11%). No single approach dominates how legal help organizations will get AI for their organizations and users.

This current fragmentation in AI development presents a key opportunity for strategy. The field is at an inflection point, and the choices that individual organizations make now will shape the infrastructure of legal aid technology for years to come. The question is whether those choices will be made in isolation, or whether the field can learn from both the failures and successes of other technology adoption waves.

The Buy Problem

For many legal help organizations, contracting with a vendor feels like the responsible choice, delegating this technical work to others who specialize in technology. Vendors offer a finished product, a support team, and the promise of sustainability. The organization does not need to hire developers or manage infrastructure, instead, it can stay focused on legal work.

But our respondents identified serious concerns with this vendor-centric path. When asked what worried them most about relying on vendors for AI tools, the top responses were striking:

Seventy percent of respondents cited data privacy and security as their top concern about working with AI vendors, reflecting the sensitive nature of legal work and the concern that vendors may have data handling practices that are difficult to understand. Fifty-seven percent flagged cost and long-term affordability worries about working with vendors, and well over half worried about quality and accuracy of AI outputs. Vendor lock-in, once you commit to a vendor’s system, switching is painful and expensive, was flagged by 36% of respondents.

These concerns are not unique to legal aid and court groups. A Stanford CodeX analysis of AI vendor contracts found that many favor vendors by limiting liability and shifting compliance burdens onto customers³, a pattern that is particularly consequential for under-resourced legal help organizations that lack the bargaining power or legal expertise to negotiate favorable terms.

Beyond the contract terms, there is also the structural effect of choosing the ‘buy from a vendor’ option. When a legal organization signs a vendor contract, it is not just purchasing software. It is outsourcing institutional knowledge and building a deep dependency on another single organization. If the vendor is unresponsive, raises prices, pivots its product strategy, or goes out of business, the legal help organization is left without the tool it has come to depend on, or without the internal capacity to replace it or even to modify and update it as inevitable technical or legal changes occur over the years. The promise of sustainability that drew the organization to the vendor in the first place can prove to be fragile in precisely the ways that matter most over the next five or twenty years.

The Build Problem

The alternative to buying from a vendor, building AI tools in-house, appeals to many legal help organizations that want to control their technology stack and build the custom solutions that their teams need. Some legal aid programs have talented technologists, designers, and lawyers on staff who are eager to build AI solutions themselves.

But this ‘build’ path has its own failure modes, as our respondents expressed in their survey responses to our questions about concerns with ‘building AI in-house’:

Around three-quarters of respondents said their organization does not have the internal team members necessary to build AI tools. Just under half said they cannot keep up with the pace of AI development, and a similar percentage flagged that they are concerned about maintaining the home-built AI team over time. Thirty-six percent cited the single-point-of-failure problem: when the one person who understands the system leaves, the tool becomes unmaintainable and then unusable.

These fragility concerns deserve emphasis. In many non-profit legal help organizations, technology staff are scarce and paid less than in the private sector. The in-house developer who builds a custom intake tool or document extraction pipeline often holds irreplaceable knowledge about how it works. When that person leaves the organization, often the tool becomes ‘legacy software’: it still runs, but no one can fix it, extend it, or adapt it as laws or workflows change. The ‘build in-house’ organic innovation that drove the project can become a liability.

There is also an isolation problem among the various legal aid and court teams. When each organization builds its own tools independently, the result is dozens of bespoke systems that solve similar problems in incompatible ways. The housing intake tool in one county does not interoperate with the housing intake tool in a neighboring county or state. Each organization may go through a very similar research and development journey, of the tech development, design decisions, and legal analyses, but they do so without learning from each other and with tools that are just different enough that they can’t be maintained or updated together.

The Third Path: A Commons Model

There is a third option for AI development, apart from ‘build’ or ‘buy’, that most legal leaders have not seriously considered, though it has promise and some examples of success. The model is commons-based peer production, a term coined by scholars Yochai Benkler and Helen Nissenbaum to describe collaborative, open-source development driven by communities rather than firms or governments.⁴

The commons-driven, ‘build together’ idea draws on Nobel laureate Elinor Ostrom’s research demonstrating that communities can effectively steward shared resources without privatization or centralized control in order to realize their impact goals.¹ Ostrom identified design principles for successful commons governance to help communities work together: clearly defined boundaries, collective decision-making, monitoring, graduated sanctions, and accessible conflict resolution. These principles have been translated to digital infrastructure by scholars and practitioners.² Several scholars have previously encouraged legal aid organizations to explore open-source collaboration and interoperable work to realize this third way of building and maintaining technology.⁵

In legal aid technology this model already exists in software ‘built and maintained together’ by communities of lawyers and technologists. The Document Assembly Line project, maintained by the Suffolk University Law School Legal Innovation and Technology (LIT) Lab, is built on Docassemble, a free open-source software originally created by Pennsylvania legal aid attorney Jonathan Pyle. The Document Assembly Line combines the Docassemble software tools (free court form automation tools that walk users through guided interviews and generate court-ready filings) with community activities to support local deployments and refinement. The code is MIT-licensed and maintained by a community of developers across legal aid organizations, courts, and law school clinics. Suffolk provides coordination, hosting, and maintenance support, funded by grants from the State Justice Institute and service contracts with courts and legal aid organizations.⁵

What makes this ‘build together’ model work is not just the open-source code of Docassemble. It is a specific combination of elements:

• An open-source core that anyone can inspect, modify, and deploy, with all diagrams, decisions, and codebases available in a public repository.
• A community of practice of implementers who share what works and what does not, contribute improvements back to the shared codebase, and meet regularly to solve problems together.
• Funded stewardship, not dependent on a single volunteer, to maintain the platform, apply security updates, and keep the technology current.
• Local customization with shared infrastructure: each organization can adapt the tools to its own jurisdiction and workflows while benefiting from the collective development of the core platform.

This model avoids both the ‘buy’ concerns and the ‘build alone’ ones. Organizations retain control and transparency. Knowledge stays within the community, not locked behind a contract or with a single organization or staff member. A vendor cannot suddenly raise prices beyond what the organizations can afford. No single organization bears the full burden of development and maintenance. When one person leaves an organization, the shared community holds the institutional knowledge.

What Practitioners Think

When we described this commons model to our survey respondents and asked about their interest, the response showed interest in this ‘build together’ approach to AI development:

Taken together, three-quarters of respondents expressed some degree of openness to the model, with over half saying they were “very interested” or “interested.” Only three respondents (4%) said they were not interested at all. This suggests latent demand for a collaborative ‘build together’ approach that most organizations have not yet had the opportunity to pursue.

That said, interest is not the same as commitment. When asked what it would take for them to actually participate, respondents highlighted things they would need to see from a ‘build together’ approach:

The respondents signaled that before they would engage with a ‘build together’ model, they want to see that it is real, that it is funded, and that it is compliant with key standards. These are practical, solvable conditions, not fundamental objections to the model. The top ask, compliance and security assurance (66%), reflects the same data privacy concern that drives skepticism about vendors. Organizations want to know that shared infrastructure meets the same standards they would demand of a commercial product. The respondents also need to see this third way in action, which many are currently unfamiliar with, to be able to understand how it operates.

Divergent Profiles

The survey data reveal important differences by organization type and size that should inform how the field approaches this transition.

• Legal aid organizations are the natural core constituency for a commons model. Among Legal Services Corporation (LSC)-funded legal aid organizations (n=18), 89% expressed positive interest; among non-LSC-funded legal aid (n=21), there was 90% positive interest. Among mid-size organizations (51–150 staff) (n=18), 83% were positive, and among those with 10–50 staff (n=20), 80%. These organizations are large enough to have real AI needs, but too small to build alone. It seems they feel the cost and lock-in pressures of vendor relationships most acutely.
• Courts are warming but cautious. Fifty-seven percent of court respondents (n=7) expressed positive interest in the commons model. As one court administrator noted: “Judges are still skeptical and wary of AI and would be more so about a community-driven approach.” Courts face different institutional constraints, judicial independence concerns, IT governance structures, and risk aversion around new technology, that may make the commons model a harder sell in the near term.
• Libraries remain cautious. Only 20% of library respondents (n=5) expressed positive interest, suggesting that this constituency needs a different engagement strategy, or that the commons model may simply not match how libraries approach technology adoption.
• Larger organizations (500+ staff) are pragmatic. Eighty-six percent (n=7) expressed positive interest, and many are already mixing approaches, using vendors for some tools and building in-house for others. The commons model may be most valuable to them as a third ingredient in their existing mix.

What This Looks Like for AI in Legal Help

The Docassemble ecosystem shows how a ‘build together’ commons model works for document assembly. The question is whether it can work for AI workflows, which are more complex, more expensive to run, and evolving faster than any previous generation of legal technology.

When we asked respondents which AI use cases they would most want a commons to address first, the top priorities were:

Several of these use cases are already being explored by communities of legal help organizations, working together to scope out agendas, evaluation standards, technical blueprints, and other shared resources. The Legal Help Commons, an initiative of the Stanford Legal Design Lab, is building shared infrastructure for AI workflows in legal help. Early priority areas include:

• Voice-based intake and triage, building on the open-source voice intake AI systems in development and common evaluation standards.⁶ Rather than each organization that wants voice intake signing a separate vendor contract, the goal is to create a shared, open-source core that a community of practice can maintain, customize, and improve together.
• Knowledge base and content safety wrappers, reusable guardrails and retrieval-augmented generation (RAG) infrastructure that any organization can use to build a legal Q&A system grounded in verified legal content, with appropriate safety protections.
• Document data extraction pipelines, shared tools and reference architectures for pulling structured data from court filings, government forms, and case records, addressing the OCR and data extraction needs that multiple organizations face independently.

The Legal Help Commons (where agendas and standards are set) is complemented by the sister platform JusticeBench (justicebench.org), which maps the full task taxonomy of legal help workflows, catalogs existing AI projects and datasets, and hosts evaluation benchmarks and results of tool testing. Together, these create the infrastructure for a field that can learn collectively rather than experiment in isolation.

The Hard Questions

A commons, ‘build together’ model for legal AI development may have serious challenges. The survey responses and open-text comments surfaced several that deserve honest engagement.

• Can distributed teams actually build useful AI products? One respondent, himself a major contributor to open-source ecosystems, was supportive of community-building but skeptical of national-scale collaborative development: he noted the enormous value of peer exchange at conferences like LSC’s annual Innovations in Technology Conference (ITC), but questioned whether geographically dispersed teams can collaborate effectively enough to build a useful product. AI development may require more specialized expertise and computing resources than document assembly. A legal help AI commons will need funded core development capacity, not just volunteer contributors. The model is closer to a more formal, supported organization with staff than to a weekend hackathon with well-meaning volunteers.
• What about the “saintly pioneer” problem? Many open-source projects in the legal aid space have been sustained by one or two dedicated individuals who do enormous amounts of maintenance out of public-spiritedness.⁶ This is inspiring but fragile, just as the ‘build in-house’ by one employee is. A sustainable commons needs institutional backing, grant funding, and a business model that does not depend on any single person’s continued goodwill.
• What about organizations that are already happy with their vendor? The commons model is not an argument against buying technology from vendors. Vendor groups may be excellent, driving forward innovation and supporting organizations with delivering effective, secure services. The argument is that legal aid and court organizations should have a real choice and robust alternatives about what is best for their organization and the field. They should also have the standards and support to change vendors, to evaluate vendors, and to maintain a project on their own if the vendor changes their business. Right now, many groups do not have clear or robust choices about how to implement AI in their work. They default to vendors not because vendors are the best option, but because they do not know an alternative exists or do not trust it to be best for their clients, staff, or organization. As one executive director told us: “We discussed a potential build-together approach, but then were informed the tech may already exist and so now are working on accessing the existing tech and testing it for accuracy.” This is exactly the kind of discovery that a well-connected commons enables: surfacing what already exists before anyone spends money rebuilding it.
• What about staff resistance? A technology director at an LSC-funded organization noted: “There is a lot of hesitancy from legal staff. Many are not technical or computer savvy. So, seeing what AI can do for them in real world context is paramount.” Another respondent emphasized the change management dimension: “There is a decent amount of distrust and angst around use of AI at all among some in legal aid, so I don’t think we can take it for granted that AI-based tools are going to be welcomed with open arms. I don’t have any silver bullets, but I just think we need to name that, and perhaps talking about it as a community will help us innovate more responsibly.” Any ‘build together’ commons model must prioritize accessible onboarding and concrete demonstrations. It must also create space for honest conversation about the tensions AI introduces, and reflect those concerns and strategies in the solutions the community build together.
• What about organizations that do not want AI at all? One managing attorney wrote bluntly: “We are actively trying to turn off the AI that Google and other platforms force on us. Too many concerns about client data privacy, destruction of the environment, support of the billionaire overlords—let’s shut down AI.” This participant’s point of view matters. Not every organization is ready for AI adoption or will ever want to integrate AI into their services, and a commons model must respect that some programs have principled objections. The commons would be an option, not a mandate about required AI deployment. That said, the commons might also implement evaluation standards around privacy, energy and compute usage, and other ethical standards for tools to comply with to address these concerns head-on.
• What about quality and safety? As one court administrator warned: “Having a wrong answer is much more dangerous than not having an answer. We remain cautious and skeptical, and we are only considering options that allow human confirmation of correctness.” This perspective on actual harm is quite valuable, and it is why a commons model that includes shared evaluation infrastructure, benchmarks, testing protocols, quality standards, is more likely to produce safe AI tools than dozens of isolated programs each evaluating tools on their own. This also points to the importance of having frontline, practicing experts guiding the definition of ‘what is good’ and ‘what is safe’, rather than those outside the domain making these choices.

What Legal Help Leaders Should Do

If you are an executive director, technology director, or board member at a legal aid group, court self-help center, or other legal help organization, there are some deliberate ways to approach the ‘build together’ way of working:

• Before you sign the next vendor contract, ask: is there an open-source alternative? For document assembly, the answer is already yes. For AI use cases, the ecosystem is emerging gradually. Check with colleagues and professional networks about whether a shared solution exists before committing to proprietary lock-in. Even if there is not an open-source software alternative, there are likely peers that can share their development journey, their evaluation standards, their checklist of what to prepare and how best to carry out the project. All of those materials can make your organization’s choices, development work, and evaluation more strategic over the long-term.
• If you have a developer building AI tools in-house, ask: is this work being shared with a community? The impulse to build local, custom tools is valuable. But if the work is trapped inside one organization or one staff member, it can be fragile or duplicative. Encourage your technology staff to contribute to shared repositories, participate in communities of practice, and build in ways that others can adopt. Putting the code on Github or another shared platform is one step. What is more valuable is to share the context, diagrams, policy choices, training data, guardrails, staff onboarding sessions, and other detailed R&D materials that go along with the code. This can be a blueprint of materials for other organizations to build from.
• Advocate for funding models that support shared infrastructure. The LSC Technology Initiative Grant program has been a critical driver of legal aid innovation for over two decades, awarding more than 955 grants totaling over $95 million.⁸ But much of this funding supports individual organizations building individual projects. Funders, including LSC, state Interest on Lawyers’ Trust Accounts programs, State Justice Institute, and private foundations, can consider directing more resources toward shared infrastructure, community coordination, and the maintenance of open-source platforms and collections of reference architecture, shared evaluation metrics and protocols, and other common resources that multiple organizations can use.
• Join the conversation. The Legal Help Commons (legalhelpcommons.org) is actively fostering commons work in AI and Access to Justice, with working groups around voice AI intake, data extraction, and knowledge base infrastructure. JusticeBench (justicebench.org) provides a shared map of what is being built and evaluated. These are open communities that welcome participants at all levels of technical sophistication.

Conclusion

Legal organizations have gone through new waves of technology advancement before, and we can learn important lessons to guide us during this current wave. When document assembly emerged as a transformative technology, some groups bought proprietary tools, some built their own, and some joined an open-source community. One lesson learned is that organizations who built and joined an open-source, ‘build together’ community can get more sustainable, adaptable, affordable tools over time, and those tools can be maintained by people who understand the work.

AI developments pose a similar ‘build’ or ‘buy’ or ‘build together’ choice, though it feels like it’s happening with higher stakes and faster speed. The technology is more complex, the risks are greater, and the cost of getting it wrong, for clients and for organizations, is higher. But the structural logic is the same. The question is not whether legal aid should adopt AI. It is whether the field will adopt it together, in responsible, high-accuracy, sustainable ways.

The large majority of the practitioners we surveyed are open to trying a third way, ‘building together’ in a commons. Our team at Stanford, working together with many community partners, is standing up the infrastructure for that commons, third-way work. The question now is whether legal aid leaders, court executives, funders, frontline staff, and technology professionals will commit to a shared path, or whether each organization will continue to face the future alone.