Skip to main content
Powered by the Principles for Digital Development

Adaptability

If your digital solution is to be sustainable, you need to be clear on how it performs for users across different contexts and times. A one-size-fits-all solution is probably not going to be sufficient in a development or humanitarian context. Therefore, it’s important to clarify which parts of the solution are the same everywhere (core), which components do you provide the user some choice over (modular), and which parts of the solution they can add to and change themselves (hackable).

As a rule of thumb, the more components your digital solution has that are core, the easier it is to replicate and scale. Alternatively, the more modular or hackable the digital solution is, the better it is for contextualization. For all decisions regarding what is core, modular, and hackable, it’s important to have clarity on who owns the various components of the product or service, either within a single organization or across multiple partners.

Core, Modular, and Hackable​

When developing a new digital solution, you will often develop a minimum viable product (MVP) first, and then continue to develop features and functions based on user requirements and feedback. A minimum viable product is an initial prototype designed with only the bare minimum features. Only after designers gather feedback from users of the MVP will they design a final product with complete features.1 At that time, you’ll need to make some critical decisions regarding how adaptable the solution is for different users and contexts. Development and humanitarian agencies often require some form of customization of solutions due to:

  1. Contextual specificities: There may be contextual factors, such as smartphone penetration or usage with the agency’s target impact segment; a requirement for local languages or images to be used; or a need to integrate with widely used local tools (e.g., mPesa in Kenya).

  2. Organizational specificities: Your solution may need to be able to integrate with other software packages that the agency is running for project management, monitoring, and evaluation, or even their accounting packages or enterprise resource planning (ERP) software. It might also need adapting to collect data or provide certain functionality based upon the sector (e.g., health, livelihoods, or education).

In order to address this, you’ll need to decide how much your solution can be adapted for the context and organization. You do this by deconstructing your entire solution into individual components (e.g., software elements, hardware requirements, training, and deployment methods), and then placing them into three categories.

Core​

Core components are those that members of the buyer, user, and target impact segments have no choice over whether they are part of the product or service they receive. These components of the solution will be exactly the same in every context, for every deployment, and for every user.

Case Study: Core

Core: SMAP FieldTask is proprietary software built on ODK providing data collection, analysis, and visualization. It’s an off-the-shelf system that users are not able to change. This example of a core system can only be customized by the SMAP team. SMAP has been deployed in countries all over the globe, but each instance was the same. Any changes are submitted as change requests to the company, which determines what changes to make and what to ignore.

Modular​

These are components that you develop but are optional for the user, or they provide different versions out of the box. Users can choose to have or not have the component, and/or they can choose between different components that you offer or may be able to customize but only along pre-set options that you have designed.

Case Study: Modular

Modular: Kobo Toolbox is a product suite built on ODK providing an out-of-the-box product experience, including a form builder, analytic tools, and visualizations. It’s an example of a modular application of the hackable ODK. The user can download Kobo and use all or only a part of the suite, and they can configure it to meet their needs. The user can even take parts of Kobo and integrate it with their own system.

Hackable​

This can be the coding itself or other components of the solution, such as deployment methodology, forms or scripts within the system, and training methods. Users can adapt these components, or they can develop and add new components themselves, potentially sharing with others. This is the aim of many free and open-source software (FOSS) solutions, although many still have core and modular components.

Case Study: Hackable

Hackable: A user of ODK can use the codebase in any way they want. They can add code to it or add parts of the ODK codebase to their project. The user can also use the code the way it is to collect data. ODK is an example of hackable. It’s a free and open source software that allows users to collect data offline and at scale. It’s free to be used however the user wants.

The more core your solution is, the more centralised control you have over quality assurance and the easier it is to deploy in new contexts. However, it also means the solution is less likely to be contextually optimized. This is the balance that needs to be struck when making decisions about the degree of modularity and hackability of the solution. To use a dining out analogy, core is having a set menu in a restaurant, modular is being able to choose from a restaurant’s a la carte menu, and hackable is bringing your own food to a picnic or party.

Interactive Tool: Core, Modular, and Hackable
  • Methodology: Group or individual exercise
  • Time estimate: 30-90 minutes

Use this interactive tool to establish the core, modular, and hackable components of your solution.

Go to the tool

Key Takeaways​

  1. While designing a final product with complete features, you’ll need to make some critical decisions regarding how adaptable the solution is for different users and contexts.

  2. Disaggregating the components of your solution and establishing what is core, what is modular, and what is hackable is key to ensuring that you develop the right level of contextualization and sustainability for your solution.

Complete the following in your Business Model Sustainability Canvas:
  • Outline the key strategy (dominant category of components) you are pursuing, e.g. modular and hackable for contextualization, or core for efficiency.
  1. Becker, R. “What Is a Minimum Viable Product (MVP)? - Definition from Techopedia.” Techopedia.com, August 14, 2020.↩