Why the environment should shape the engineering before the first line of code is written.
It is easy to think deployment starts after the product is built.
Build the application. Get the model working. Connect the database. Test everything. Then take it to the users.
I don't think it works that way, especially in healthcare.
When you're building for a resource-constrained environment, the environment is already part of the engineering problem. Internet access, affordability, digital literacy, infrastructure, trust, clinical workflow and even the devices people own can determine whether a technically sound system is useful at all.
I learned this while developing and evaluating a digital-health platform for students at the University of Abuja Teaching Hospital in Nigeria.
The platform combined AI-assisted triage, teleconsultation, appointment scheduling and medical-record access. On the technical side, it worked. Our pilot showed that the platform was feasible to deploy, usable by participants and capable of producing triage classifications with substantial agreement against independent clinicians.
But the more interesting lesson was what happened when the technology met the environment it was supposed to serve.
The assumptions underneath the software
A lot of technology is built on assumptions we barely notice.
You assume the user has reliable internet.
You assume their phone can comfortably run the application.
You assume they understand the interface.
You assume they know what an AI health assistant is supposed to do.
You assume they will read the instructions.
You assume the institution adopting the product has the infrastructure and staff required to support it.
Then you deploy somewhere those assumptions don't consistently hold.
Apparently, adding AI does not make poor infrastructure disappear.
This is why I find the phrase resource-constrained environment more useful when we stop treating it as another way of saying "not enough money."
The constraint is usually a system of constraints.
In Nigeria, healthcare access is already shaped by uneven workforce distribution, limited insurance coverage and mistrust of the health system. Research on telemedicine adoption in the country has also found education and training to be a major facilitator, not technology alone.
That changes what good engineering looks like.
Sometimes the infrastructure should change the architecture
In our platform, MedGemma did not run through a commercial cloud AI API. We deployed the model locally on infrastructure at the teaching hospital.
There was a practical reason for that. Medical information is sensitive, and sending patient data through external AI infrastructure raises questions about where that information goes and who controls it.
Running the model locally gave us greater control over patient data.
Connectivity created another design constraint. Patient records were cached on the device so they could still be reviewed offline. AI-assisted triage, which needed to communicate with the institutional server, still required connectivity.
That distinction matters.
"Works offline" and "works online" are not binary descriptions of an entire product. Different parts of the same system can have different requirements. The useful question is what absolutely needs the network and what does not.
This is systems thinking before it is software engineering.
If unreliable connectivity is part of the environment, network behaviour is not something to optimise later. It should influence the architecture from the beginning.
The same applies to cost. In the pilot, AI-assisted triage, scheduling and medical-record access were free. Video consultation was the paid component.
That is not a small product decision.
Affordability affects access.
A working model is not the same thing as a working health system
The AI results from the pilot were encouraging.
Across 61 triage sessions included in the primary analysis, MedGemma agreed with one independent clinician on 90.2% of urgency classifications and with the other on 93.4%. Weighted agreement was also substantial.
Interestingly, agreement was stronger in longer conversations.
That matters because a patient does not arrive as one symptom in one prompt.
Healthcare conversations develop. More information becomes available. Previous health information matters. Sometimes the first answer simply isn't enough to make a sensible decision.
Our triage system therefore used multi-turn conversations and incorporated the patient's recorded medical history as context. Emergency classifications were not routed into another AI conversation either. They directed the patient toward in-person care.
But strong triage agreement does not automatically mean the healthcare-access problem has been solved.
That is where the pilot became more interesting.
We measured healthcare access across availability, accessibility, accommodation, affordability and acceptability. Four of the five moved in a positive direction. But the effects were small, and after correcting for multiple statistical comparisons, none of the improvements could be confidently established as statistically significant.
That distinction is important.
It would have been easy to look at strong AI-clinician agreement, a usability score above the standard benchmark and a functioning local deployment, then conclude that we had demonstrated improved healthcare access.
The data did not allow us to say that.
What we demonstrated much more clearly was feasibility.
The system could run.
People could use it.
The AI could produce urgency classifications with encouraging agreement against independent clinicians.
Those are useful findings. They are just not the same thing as proving that the system improved healthcare access across a population.
I think digital-health engineering needs more of that distinction.
Access is more than making an app available
A health application being available does not mean healthcare has suddenly become accessible.
Can the patient afford the service?
Can they understand how to use it?
Does it work under the network conditions they actually experience?
Can their phone run it comfortably?
What happens to their medical information?
Can they understand what the AI can and cannot do?
If the system identifies something serious, is there a real pathway to a human clinician?
And if people start depending on the service, will the service still exist next year?
Those questions are not outside the product.
They are part of the product.
One thing I learned from building software even before this study was how dangerous it is to design around your own level of digital familiarity.
I have watched users struggle with interactions I considered completely obvious.
My first reaction as an engineer can easily be: the instruction is right there.
Well, yes. It is obvious to the person who designed it.
Users have a very efficient way of informing you that your assumptions are not universal.
That is one reason structured onboarding became part of the telemedicine pilot. Participants were introduced to how the triage system worked, its limitations and when escalation to in-person care was necessary.
The technology was only one layer.
Design for the person with the fewest assumptions working in their favour
For me, one of the harder tests of technology is what happens when you move away from the ideal user.
Not the person with the newest phone, unlimited data, high digital literacy and easy access to a hospital.
What happens to the person with a cheaper device?
What happens when the connection becomes unstable?
What happens when paying for another service competes with more immediate expenses?
What happens when the user does not understand the language or interaction pattern the system was designed around?
Our study did not answer all of those questions.
In fact, some of its limitations point directly at them.
The study took place at one institution. The sample was small. We did not evaluate MedGemma in Nigerian languages or code-switched English. Participants with known physical disabilities were not represented, which meant some of the accessibility assumptions behind the platform remained untested.
Those are not small footnotes.
They tell us where the next version of the system needs to become better.
If I were approaching the problem again, I would spend even more time before implementation studying the clinical workflow itself.
How do practitioners handle common presentations?
Where are decisions delayed?
Which information actually changes the next action?
What makes someone seek care immediately, while another person waits until the symptoms become serious?
Then I would design around those realities.
Not around what I think the workflow should look like.
Deployment is part of engineering
There is a temptation in AI to optimise what is easiest to measure.
Model accuracy. Response time. Benchmark performance.
Those numbers matter. I am a data person. I want to know them.
But I also want to know what produced those numbers and what happens after them.
Suppose an AI system performs extremely well on a medical benchmark but needs infrastructure the target hospital cannot reliably provide. What exactly have we solved?
Suppose the model works but users cannot afford the surrounding service.
Suppose it is accurate but patients don't understand when to trust it and when to seek human care.
Suppose a pilot succeeds and disappears six months later because nobody planned for sustainability.
These are not arguments against AI in healthcare.
Quite the opposite.
I think we are still near the beginning of what AI can do for healthcare.
But if that transformation is going to reach environments where resources are already stretched, we cannot build the sophisticated part first and treat everything else as deployment details.
The environment should shape the system from the beginning.
That means designing for connectivity rather than discovering poor connectivity later. Designing around affordability rather than assuming people will pay. Building escalation into clinical AI rather than treating the model as the final authority. Thinking about privacy before patient data starts moving around. And testing with the people who will actually use the system.
The goal is not to build the most impressive digital-health product in the room.
It is to solve the healthcare problem.
Sometimes those are two very different things.
This article draws partly from my research, “Artificial Intelligence and Mobile Health Technologies for Improved Healthcare Access: Design and Pilot Evaluation of an Integrated Digital Health Platform for a Nigerian Teaching Hospital,” published as a medRxiv preprint in September 2026. The study was designed as a feasibility pilot and has not yet been peer reviewed. DOI: 10.64898/2026.09.02.26361014.