Tool Guideline

Don’t Build It: A Guide For Practitioners In Civic Tech / Tech For Development

Uploaded by RRI Tools on 12 May 2022

Grassroot (South Africa) and MIT Governance Lab (United States).

(*) Luke Jordan, Founder and CEO/CTO of Grassroot and the 2021 practitioner-in-residence at MIT GOV/LAB.

This guide aims to help you avoid bad projects, structure the team right, ship and learn quicker, and mature longer.


Preface by Luke Jordan

This guide is for teams or managers involved in considering or building “civic technology”, i.e., technology that helps people engage government more effectively. It is the distillation of my four years spent building Grassroot, a civic tech platform in South Africa.

The guide is focused on the practical. I have chosen the topics by reflecting on what people have asked for advice on over the years; on what I wish I knew when I started, or on what early advice to me was most valuable; and on some of the things that went wrong along the way.

Since software provides in itself no guardrails against building what should not be built, an organization or leadership team needs to develop its own precautions. But that is very hard when all around you people are pretending to build cool new apps and one article after another is talking breathlessly about supposed “technology for good”. As proof of these forces, we can observe that for half a decade, one research report after another has pointed to the limited effect (if any) of well-intentioned but insufficiently rigorous technology projects (“let’s build an app!”). And despite all of that research, the apps keep being built.

That brings you to my motivation for writing this guide. I believe that technology can help ordinary people build power and make the state more accountable and responsive. I believe that, when targeted at the right problem at the right time, it can make an enormous difference. I’ve also seen close-up how the forces of contemporary thought, funding and status will push you towards building what should not be built, with teams who don’t know how to build it. You’ll notice the tone isn’t typical of academic how-to guides—my approach is to describe the process honestly and realistically, with hopes that it will give people a better sense of what “building an app” entails, and how they can do it well, or (better yet) not do it in the first place. 



Structure of the guide

The guide starts with project selection, including why the best project to select is no project at all. It moves on to team structure, and the extreme importance of a full-time senior tech lead (or chief technology officer (CTO), understood as an excellent engineering manager). It then covers timelines, emphasizing shipping early but having enormous patience getting to maturity, above all in finding product-use-fit, and avoiding vanity metrics. The guide then goes into some detail on hiring, covering the CTO role, senior contractors, designers and young engineers.

The longest section, by some distance, is that on hiring. Hiring is the one thing considered critical in every piece of the lore, by founders and investors and managers alike, across all sectors. It is also the field in which I think I got it mostly right, and for reasons I can explain in ways that I believe will be helpful.


The guide is also available in spanish


Related Resources