Design for Scale vs. Bootstrapping: Reflections on Digital Development Principal #3 (Design for Scale)

We are eagerly anticipating the first time that Code Innovation receives the funding to design a technological tool that is optimized for scale from the moment of its official launch. Building for scale, as a fantasy, in my head, sounds something like this: We could incorporate a customized content management system that enables us to add new activities and modify our material painlessly in real time across a variety of languages. We could incorporate an unobtrusive yet unavoidable monitoring and evaluation protocol that feeds data into a back end that is easy to sort and clean, one that produces donor and media-relevant reports at the click of a button. We could bake in critical APKs for our social media strategy and optimize our design for the ten most common screen dimensions and the thirty most used Android devices—incorporating modular design elements to enable seamless re-branding that sweetens the deal for donors and partners hungry for visibility. We could have a big team, content gardeners, bug support in local languages . . .

Most of the innovations that we hear about in the ICT4D space do not enjoy circumstances like this. Instead, we are often bootstrapping minimum viable products through multiple too-brief program cycles each called a “pilot” phase—kicking down the road the choices about when to spend real money and hoping to transform our hacked together little tool into something robust and versatile enough to be picked up and used by the development community at large . . . and hoping, lastly, that this makes our code stylish and widespread enough to be maintained by the open source community out of love.

The Constraints of Scale with Limited Resources

Code Innovation is hitting an inflection point with one of our favorite projects that is forcing us to consider how to optimize our code for scale, but with highly limited resources. The project: an Android application that supports the facilitation of small groups that come together on a weekly basis, saving tiny sums of money, learning about businesses, starting businesses and then loaning to one another, thereby lifting one another out of poverty (take a peek at our free and open source Self-Help Group app here. Early versions of this application needed to function in Amharic and English. They needed to digitize about 70 pages of existing facilitator guides and meeting curricula and they needed to present these materials in an orderly, device-optimized way that technological novices could grasp after, at most, one quick training. Other requests piled on: social media component (sigh), interoperability with a pre-existing, ODK-based M&E app (gulp), report generating back end for funders and partners and so on and so forth.

But, at the beginning we had at most 30% of the money that it would cost to build a sufficiently rugged content app and it would mean contributing weeks of pro bono time to get our alpha version into the hands of vulnerable populations in Ethiopia. It didn’t feel like building for scale. It felt like proof of concept.

Then the usual thing happened: new partners came along with just enough money to add exactly what they want the most (a new language, perhaps, or some modules about disaster risk reduction); but not enough money to conduct a proper build. Not enough for us to build for scale. And sure, we apply a few times for large pots of Gates Foundation-type money, hoping to up-level our technology, to bring on new countries and hit our stride; but our reality continues to be bootstrapping from one version to the next, giving exceptional weight to the feature and content requests that come from whichever funder is willing to support our development next. There’s often a gentle tension between the requests of a short-term donor and the interests of our imagined, global, future customer base.

But suppose we have some promising leads? Suppose we allow ourselves to imagine building for scale just as a thought experiment? What would that look like? Or, more interestingly, what it would it look like if it were done in hefty stages rather than all at once? What if we had to prioritize the that would bring us to scale and scalability?

We admire all of the RapidSMS-based systems that our colleagues and friends have built and rolled-out through national ministries or with the paid-support of well-distributed program officers and we’re entirely aware of the benefits of short codes, dumb phones and standards. But our content and use case has driven us onto a more troublesome format (smartphones) and into an arena that is not as cut and dry or hierarchical and organized as Ministries of Health. In fact, the different partners who are most likely to adopt and scale our product do not agree about content or program models—quite apart from the fact that they often speak different languages.

So how do we articulate and prioritize the different investments into our content and technology that would help transform a narrow, bespoke application into a robust open source tool that is best in class?

Our primary considerations for taking an open source Android app to scale:

* Connectivity Management:

This isn’t a feature. It’s a constant high level development consideration until free Internet rains down from the heavens. Whenever we forget this variable, we open ourselves up to unnecessary failure. We need to ensure that our app respects the hyper-low and infrequent connectivity of our users by refusing to incorporate any commands or experiences that rely upon wifi or data signals. We must also anticipate database-device conflicts that result from infrequent connectivity, for instance groups naming themselves identically when offline that might become confused when they first connect. Building for low to zero connectivity is our primary constraint; it means we can’t rely on user logins or passwords, it complicates things and it makes it harder to use out-of-the-box chunks of open source code.

* Inbuilt Monitoring and Evaluation with administrative back end:

In early phases, it’s feasible to conduct monitoring and evaluation personally and to rely on Skype calls or emails as a fallback in case user information from the App is sparse or unreliable. But as we scale, our technology must gather and sort this information for us more dependably and we need to ensure that this information is visible and actionable for backend administrators who are not also our coders and developers.

* Support more Devices:

We will need to optimize our code for a growing number of devices and screen sizes. At first we could control what hardware was used with our product. But going to scale will mean the loss of this control and a bunch of design work will be required to keep content legible and navigation pathways obvious. We also have to set funds aside for keeping up with changes to the Android operating system. (For others operating in Africa, we’ve found that Tecno tablets are good for our purposes. They are widely available, robust and not big targets for theft. There are some quirks that make them a bit difficult to code for; but they’ve been hassle free in the field.) Sometimes affluent allies to our project bemoan the unavailability of our app on the Apple Store. The only justification we can see for coding this for iOS is that it might be useful for fundraising and visibility at some point when money is not an object.

* Social & Sharing:

Because we have partners who are committed to creating a social media component: we need to build out a way for groups to “share stories.” This will ultimately require an interface for reviewing, moderating and even editing the content that is uploaded to our system. (We also need to build out trainings for our end-users about the privacy considerations of sharing stories about themselves and their businesses.) We anticipate eventual requests for APKs with locally relevant social networks for cross-promoting stories and insights and can see the utility of this when begin to pursue unstructured growth amongst individual users.

* Solid Content Management System:

We will need a better content management system. Our current system was the cheapest and most familiar thing our developers could find; but it isn’t suitable for the use of our program officers because the interface requires use of html and is tiny and hard to search. Adding new languages and changing content should be easy enough in the future that relatively low-skilled, non-technical team members can do it. Our future CMS should also make it easy to change pop-ups, buttons and navigation prompts.

* Inbuilt bug Tracking:

Crash reports are great; but we need to adopt and move onto a formal issue-tracking system like Redmine and incorporate into the app some way for our users to let this system know when they encounter inclarities with content or problems with usability.

* Branching Curriculum:

Because we want to create one application that is sufficiently useful for a number of similar but different program models, we need to invest considerable time (and consensus building) into the maintenance of a one-size-fits all curriculum that will probably soon require a new user interface feature for when content branches. So, for example, the activities about supplying loans would have to branch to accommodate Islam’s prohibition of interest-charging or an activity about group milestones would have to split to address Volunteer Savings and Loans Association (VSLA) program models that pay-out from the communal kitty. The Self-Help Group model that inspired our work seems the most impactful of these initiatives and has drawn the attention and support of Melinda Gates. But it isn’t the most widespread model—in order to increase its reach, we’ll want to accommodate the needs and interests of closely aligned programs.

* New Content & Content Architecture:

We need to expand the scope and functionalities of our resources and supplementary materials. At the beginning it was fine to create a little directory of hard-to-see pdfs to satisfy an unanticipated partner request. But the quantity of high-quality material that we are now hosting deserves a whole ecosystem, complete with loads of new instructional language and the option for users to email themselves forms and templates that they find helpful.

* Finance Tracking:

Hovering in the future is the expectation that the app itself start to track the savings and money-usage of the groups, perhaps synching up with mobile money or sources of external capital. We’ve had good reason to postpone this so far; but it will be requested or required of us sooner or later. Here also we anticipate some healthy tension between a digital development principle six, which encourages us to use Open Data and principle eight which reminds us to address privacy and security concerns.

* Inbuilt Trainings:

To move away from conducting trainings during field visits, we should create some digital tutorials that help tech novices understand how to use the app—and these will have to be in a variety of languages, with a directory of audio files (optimally). From our point of view, the chief rationale for digitizing a successful development work initiative is to remove the cost of scale created by field visits, workshops and trainings. Where these Self-Help Groups are growing traditionally, organizations strain to raise funds for facilitators who require transport, accommodation, connectivity, benefits and so forth. So even though building dynamic trainings into an app can feel like an extravagance, it pales in comparison to the cost of field visits—especially from senior staff who command hefty day rates.

What We Have So Far

There’s more. But these represent some considerable investments of time and money. In an ideal scenario, we get a war chest and we build the seventh wonder of ICT4D in the next three months, our product wows our implementing partners who want it in the hands of ten thousand facilitators ASAP and program officers around the world begin inviting us to collaborate with their field workers.

But I suspect we’ll be juggling this list of priorities and I suspect we’ll be juggling them along with heavily-weighted surprise requests from partners that we can’t anticipate. For example, we’ll probably have to persuade a new partner that instead of paying us to adapt and incorporate new modules about their favorite Sustainable Development Goal, they should pay us to update our content management system. Or we’ll learn that they’re only interested in the possibility of upgrading our underlying code after they field-test a version of that has been slightly modified to include their urgent priorities. In such cases, the implementing organization may be building our app for scale within their ecosystem, even as, from a technical standpoint, they are encouraging us to make it less appropriate or robust for a wider, general scale up.

There are heuristics to help us make sensible decisions about what to develop when funds for tech improvement are scarce. Investing in structural or systemic modifications that facilitate additions of content and upgrades is better than making ad hoc additions and upgrades. From a programmatic standpoint, we need to prioritize helping our users with their primary duties before we create new ones for them (such as becoming story-tellers or youth journalists). We also must do what we can to assist with data gathering and monitoring and evaluation so as to capture, quantitatively, the results of our tinkering.

There’s often a slight tension with the Digital Development Principles, too, in the area of being collaborative. Because making the decisions that truly build a technology for scale can mean behaving inflexibly in the face of stakeholder and beneficiary requests. If we figure out any magic tricks, we’ll definitely let you know. Stay-tuned to our blog at Codeinnovation.com to follow the noble struggle between bootstrapping and building for scale!