What Digital Projects Need to Succeed in Emerging Contexts

The phrase "emerging context" is often used as if it described a slightly more difficult version of a familiar project: same scope, longer timeline, a few extra training sessions. In practice, it describes a planning environment with different constraints, not a tougher version of the same one. Procurement happens on a different rhythm. Connectivity is intermittent in ways that look fine from headquarters but break user flows in the field. Skilled people rotate every two or three years for reasons no project plan controls. Funding is granted in cycles whose start and end dates rarely match the technical roadmap.

A project that works in this environment is almost always a project that was designed against those constraints, not a project that was designed in a comfortable office and then asked to perform somewhere else. The first cost of misunderstanding this point is invisible at design time and very visible eighteen months later, when the platform that launched well stops being maintained and quietly stops being used. This article collects the conditions that, in my experience, separate the projects that survive from the ones that do not.

The single most underweighted constraint in emerging-context projects is the calendar of the funder, the ministry or the national accounting cycle. A platform that requires a hosting renewal in March will fail if the budget rhythm only releases operational funds in June, regardless of how well the platform itself is engineered. The same is true of licence renewals, certificate rotations, paid integrations and any recurring cloud cost denominated in foreign currency.

Designing for the rhythm means making the architectural choices that match it. It often means preferring solutions whose recurring cost can be paid annually rather than monthly, choosing vendors with billing currencies the local finance team can actually pay without manual workarounds, and writing contracts that survive a six-month gap in disbursement without disabling the service. None of this is glamorous; all of it is decisive. A project that ignores it ships a beautiful platform that is, in year two, formally functioning and informally abandoned.

The second underweighted constraint is the actual connectivity profile of the people who will use the platform. Field offices in francophone Africa frequently have intermittent bandwidth that is fine for short sessions and breaks long ones, mobile connections that work but cost the user real money per megabyte, and shared devices passed between several staff members during the same week. A platform designed against the assumption of stable broadband on a personal laptop will not break visibly; it will be used poorly, and the team will quietly fall back to spreadsheets and WhatsApp.

Design choices here are not exotic. Server-rendered pages over heavy single-page apps, aggressive payload trimming, offline-tolerant flows for the few critical actions, and explicit handling of slow image loads do most of the work. The discipline is to make these choices early, when they are cheap, rather than retrofit them under pressure once the analytics tell a story the proposal did not.

A platform built on a stack that requires a senior specialist to maintain it is a platform that will need that specialist for as long as it lives. In a context where skilled engineers rotate to better-funded projects every two or three years, that is a structural risk, not a hiring problem. The strongest projects I have seen are designed against the team that will exist in year three, not the team that exists at launch.

Concretely, that often means choosing technologies that are widely understood by mid-career developers in the region, documenting decisions in a way that survives staff turnover (a clear architecture note, a runnable local environment, a short operational runbook), and resisting the temptation to introduce a fifth tool when four would do. It also means designing the platform so that a competent generalist developer can take over maintenance after a brief handover, instead of needing the original architect on speed dial. None of this prevents the project from using modern tools; it simply forbids the project from depending on irreplaceable people.

Most proposals price the build and treat maintenance as a footnote, often a small recurring number with no scope attached. After eighteen months, the platform has accumulated database growth, schema drift, deprecated dependencies, broken third-party integrations and a backlog of small but real bugs that no one has the budget to fix. The platform is not "broken"; it is decaying, and decay is the failure mode emerging-context projects suffer most often.

A useful rule is that the first year of maintenance, scoped honestly, costs roughly twenty to thirty percent of the build, and that figure should sit in the budget conversation from the start, not in a later annex. The maintenance scope itself should be specific: dependency updates on a fixed cadence, a clear backup and restore drill, a small monthly bug fix budget, an annual security review, and a named maintainer on the partner side. A project that ships without this is not a project that costs less; it is a project that has decided to absorb the cost as silent decline.

Adoption in emerging contexts is rarely a training problem. It is usually a fit problem. A platform that asks users to do twelve clicks where the previous workflow took three will lose to the previous workflow, regardless of how thorough the training session was. A platform that is bilingual but renders the English version as the default in a francophone field office will be used reluctantly, and the data quality will reflect that reluctance.

The pragmatic move is to invest design time in the workflow before the visual interface, and to ship the language version that matches the actual working language of the team, not the funder. Where the project genuinely needs both languages, the bilingual experience should be a first-class part of the design (not a flag flipped late in the build), with content models that carry both versions cleanly. Where it does not, choosing one and committing to it produces better adoption than half-resourcing two.

The most consequential planning mistake is to treat the launch event as the success milestone. The launch is the point at which the project is most fragile, not most complete: the team is exhausted, the bugs are concentrated, the data is sparse, the workflows are not yet habits. Funders and steering committees who celebrate the launch and then redirect attention elsewhere are setting the project up for the slow decline of year two.

A more honest milestone is the second-anniversary review: is the platform still in active use, by the original team or its successors; is the data still being entered cleanly; are the integrations still working; is the maintenance contract still funded; has the platform absorbed at least one significant change without breaking. Projects that survive that review are projects that were designed against the right constraints in the first year, and maintained as a system rather than as a deliverable in the second. For more on what those choices look like at platform-design time, the digital platform article goes into the trade-offs in more detail, and the wider Madagascar and Africa digital insights cluster collects the related analyses.

A digital project in an emerging context succeeds when its design absorbs the real constraints (procurement rhythm, connectivity profile, staff rotation, maintenance economics, language fit, post-launch trajectory) rather than treating them as risks to be managed later. Most of the difference between projects that compound and projects that decay is decided in the first three months of design, in conversations that are usually not technical at all.

That conversation, and the implementation that follows, is where my digital transformation and technology solutions practice and my digital platforms practice for NGOs and institutions tend to add the most value. If the question has moved from "we need to build a platform" to "we need a platform that still works in three years, after the team has rotated and the grant has closed", that is the conversation worth opening.