By Diego Almeida
I remember the first time I watched a colleague from California try to deploy a soil-moisture sensor network in the semi-arid interior of Pernambuco. He had a laptop, a brand-new LoRaWAN gateway, and a very firm belief that the hardest part would be calibrating the sensors. Five hours later, we were still hunting for a single reliable power outlet in the community school—and the gateway had already overheated at 38°C in the shade. This scene plays out constantly, and it reveals something deeper than a simple logistics failure. It exposes a set of assumptions baked into the design of so much technology from the Global North: the assumption that infrastructure is a given, not a variable.
In engineering circles, we talk a lot about constraints—weight, power draw, bandwidth, cost. But too often the conversation skips the most basic constraint of all: whether the ground beneath your project actually has running electricity, paved roads, or a cellular signal that stays up for more than three hours. When you work in Brazil, especially outside the capitals, you learn very quickly that infrastructure is not a background condition. It is the project. And if your tech design does not start from that reality, it is going to fail, no matter how elegant the algorithm.
The Invisible Baseline
Most Western technical education operates with an invisible baseline. The textbook examples, the standard dev kits, even the way we talk about “edge computing” or “IoT deployment”—all of it presumes a world where you can plug into a stable grid, trust the voltage, and assume that connectivity, while maybe slow, is present. This baseline is so deeply embedded that engineers often do not realize they are leaning on it. It’s like the assumption that air is breathable; you only notice it when you walk into a room full of smoke.
In Brazil, that smoke is everywhere once you leave the metropolitan cores. According to data from the Brazilian Institute of Geography and Statistics (IBGE), as recently as the 2010 census, around 730,000 households in rural areas still lacked access to electricity. While the Luz para Todos (Light for All) program has made massive strides since 2003, the reality on the ground is more complicated. A connection on paper does not mean a stable connection. Voltage fluctuations, single-phase supply, and blackouts that drag on for days during the rainy season are common. And the problem is not just electricity. Paved roads, reliable water supply, and consistent internet access—all are patchy in ways that a typical product requirements document never accounts for.
I have lost count of the number of times I have seen a field deployment plan crash against a road that turns to impassable mud after a single afternoon storm. The truck cannot reach the site. The sensor stays in its box. The data gap grows. And the project manager, sitting in an air-conditioned office in São Paulo or San Francisco, sends an email asking why the installation is behind schedule. The problem is not the technology. It is the assumption that the truck would always get there.
The Voltage Whisperers
To bridge the gap between these two worlds, you need a particular kind of engineering mindset. I call it being a “voltage whisperer.” It is not a formal discipline. You will not find a course on it at MIT or Poli-USP. It is the skill of looking at a piece of equipment and immediately thinking: what happens when the power here is 190 V instead of 220 V, or when it spikes to 260 V at 3 a.m. because the local transformer is overloaded? It is knowing that you need to spec power supplies with a wide input range—not just the nominal value—and that you should always, always include surge protection that can handle the particular brand of chaos that a Brazilian rural grid delivers.
This is not a matter of “hardening” a design. Hardening implies you are taking a standard design and making it tougher. The voltage whisperer approach starts from the other end. You assume the grid is hostile, intermittent, and noisy. You design for that from the first sketch. Batteries are not a backup; they are the primary power source, with the grid acting as an unreliable charger. Solar becomes not an eco-friendly add-on but the fundamental energy input, sized for the worst month of the year, not the average. And you pick components that can survive a zero-volt state without corrupting their firmware, because brownouts are a way of life.
I have worked with Brazilian technicians who can diagnose a failing microcontroller by the way the LED flickers during a voltage sag. They know the personality of the local grid the way a sailor knows the tides. This knowledge is rarely written down. It lives in the calloused hands and sunburned necks of the people who actually keep things running. And it is completely invisible to an engineering culture that sees power as something that comes out of a wall in a predictable, standardized form.
When Connectivity Is a Luxury Good
Then there is the internet problem. The standard IoT playbook assumes your device will phone home over cellular or Wi-Fi. In much of rural Brazil, cellular coverage exists on a map but vanishes when you hold a phone above your head and walk in circles hunting for one bar. Satellite is possible but expensive and power-hungry. Wi-Fi requires a backhaul that usually does not exist. So you are left with a device that can collect beautiful data and has no way to send it anywhere.
The Western solution is often to push intelligence to the edge. Do the processing locally, send only the insights. This is a good idea, but it still assumes you eventually need to get those insights out. If your only upload window is when a motorcycle courier rides within Bluetooth range once a week, your entire data architecture has to change. You need store-and-forward with compression, strong error checking, and a user interface that makes sense for a farmer who will never see a dashboard—because the dashboard is on a server that the device cannot reach.
I once worked on a water tank monitoring system for a municipality in the Vale do Jequitinhonha. The tanks were spread across 30 kilometers of dirt roads. Cellular signal? None. The final design used a store-and-forward LoRa mesh that dumped data to a single gateway at the town hall, which had a shaky DSL line. The gateway stored everything on an SD card as a primary copy because the DSL line went down so often that the cloud database was more of a nice-to-have cache. The system was not elegant in the way a Silicon Valley architect would draw it. But it worked for two years without losing a single data point. That is the kind of engineering I respect.
The Cultural Bridge in Engineering Teams
There is a cultural dimension here that goes beyond the technical. Brazilian engineering has a long tradition of jeitinho—not in the sense of cutting corners, but in the sense of finding the path that actually works when the official one is blocked. It is a creativity born of scarcity. When you cannot order a specialized part because it would take six weeks to clear customs and cost three times the project budget, you learn to repurpose. You raid a junkyard for a motor. You rewind a transformer by hand. You build a weatherproof enclosure out of a plastic water tank and a lot of silicone sealant.
Western engineering culture often mistakes this resourcefulness for a lack of rigor. It is the opposite. It is a deep rigor, applied to the real constraints of the environment. The problem arises when teams from different traditions try to work together without acknowledging these different baselines. The foreign engineer sees a chaotic, unprofessional mess. The local engineer sees an outsider who is obsessed with specifications that are irrelevant to the actual problem. Both are right from their own perspective, and both are missing the point.
The best collaborations I have seen happen when the foreign partner shows up with humility and a willingness to learn what they never had to think about. They stop asking “why don’t you just…” and start asking “what do you do when…”. And the local partner, in turn, gets access to tools and methodologies that can systematize their hard-won intuition into something scalable. That is when the real engineering happens. Not in the clean diagrams, but in the messy, sweaty, improvisational space where a design meets the world.
Redesigning the Design Process
So what does a better design process look like? It starts with an infrastructure audit that is as detailed as the technical specification. Before you choose a microcontroller, you spend a week measuring the voltage at the deployment site at different times of day. You map the cellular signal strength with a walk test, not a coverage map. You talk to the person who will actually interact with the device—not the project manager, but the field technician who will have to reset it during a thunderstorm. You ask about the rainy season. You ask about the nearest place to buy a fuse.
This kind of audit produces a list of constraints that will shape every subsequent decision. It tells you that your device needs to run for 72 hours without any external power. It tells you that your data packets need to be under 100 bytes because the only available link is a satellite messenger with metered airtime. It tells you that your enclosure needs to survive a curious cow rubbing against it, because the best sensor location is in a pasture. These are not edge cases. They are the central cases of a deployment that actually has to work.
I have started carrying a small notebook specifically for what I call “ground truth specs.” It is separate from the formal engineering notebook. It contains things like “Generator at school: runs Wed and Fri, 2–5 PM, voltage sags when the water pump kicks in” or “Cell signal: Movistar works on the hill behind the church, but only in the morning.” These notes are worthless for a publication or a patent. They are the most valuable engineering data I have.
The Cost of Ignoring Reality
The consequences of ignoring infrastructure reality are not abstract. I have seen pilot projects abandoned because every device fried within three months. I have seen research grants evaporate because the data collection was so spotty that no paper could be written. I have seen communities lose faith in technology altogether because yet another well-intentioned project left behind a pile of dead electronics that nobody knew how to fix. The waste is not just financial. It erodes the trust that makes future projects possible.
There is also a quieter cost: the reinforcement of a narrative that technology from the Global North is advanced, while local solutions are makeshift and inferior. This narrative is wrong, but it persists because the failures of imported tech are usually blamed on the environment rather than on the design. “The grid is too unstable,” they say, as if the grid were an external force like the weather, rather than a known condition that the design should have accounted for. Blaming the environment is a convenient way to avoid taking responsibility for a design that was inadequate to its context.
A truly appropriate technology is one that treats the environment—physical, infrastructural, cultural—as a set of requirements, not as a set of obstacles to be overcome. This is not a new idea. It was central to the appropriate technology movement of the 1970s, associated with thinkers like E.F. Schumacher. But it is an idea that gets lost every time a new generation of engineers is trained on idealized lab setups and never exposed to a field site where the power comes from a car battery and the internet comes from a motorcycle.
Practical Principles for Infrastructure-Aware Design
Over the years, I have distilled a few principles that I try to apply to any project that will leave the asphalt. They are not rocket science. They are more like a checklist for sanity.
1. Power is never a given; design for energy autonomy
Assume the grid is a bonus, not a foundation. Calculate your energy budget for the worst solar month, not the average. Batteries degrade, so plan for 80% of rated capacity after two years. Solar panels get dusty; derate by another 20% if nobody will clean them weekly. If your device cannot survive a week of rain with zero sun, it is not ready.
2. Connectivity budgets are real budgets
Do not treat data transmission as free or infinite. In many rural areas, you are paying per megabyte over a satellite link, or relying on a gateway that syncs once a day. Compress your payloads. Use binary protocols instead of JSON if you can. Batch your transmissions. And always have a local storage fallback that can hold weeks of data. The cloud is a luxury; local is the reality.
3. Physical access is a design constraint
If a device requires a technician visit more than twice a year, you have probably failed. Design for remote diagnostics: a simple LED blink pattern that a farmer can describe over a crackly phone call is better than a fancy web dashboard that nobody can reach. Make the reset procedure obvious and physical—a button you can press with a stick if the enclosure is mounted high. Label ports in Portuguese, with symbols, because the person doing the troubleshooting may not read English.
4. Enclosures are not just boxes
An IP65 rating is a starting point, not the finish line. Your enclosure has to handle UV degradation that will turn plastic brittle in two years. It has to keep out ants, which will find their way into anything warm and dry and short out your PCB. It has to survive a curious child with a stick. It has to be mountable on a crooked wooden post with the hardware that is available at the local hardware store. These are not trivial details.
5. The user is part of the system
The most reliable piece of infrastructure in many rural areas is the person who lives there. They know the land, the weather, the rhythms of the day. Design your system to work with them, not in spite of them. A simple indicator that shows “everything OK” or “something wrong” in a way that is visible from 20 meters away is worth a thousand log files. Give them ownership: a way to do basic resets, a contact number that actually gets answered, and a reason to care about keeping the thing alive.
FAQ: Infrastructure Reality in Tech Projects
Why do so many imported tech projects fail in rural Brazil?
The most common reason is that the technology was designed for a stable electrical grid and reliable internet, which are not the norm in many rural areas. Voltage fluctuations, power outages, and lack of cellular coverage are frequent, and devices that cannot handle these conditions will fail quickly. The design did not account for the actual infrastructure environment, treating it as an afterthought rather than a primary requirement.
What is the biggest misconception foreign engineers have about deploying tech in Brazil?
The biggest misconception is that infrastructure challenges are temporary or can be fixed with a quick workaround. In reality, the variability of power, roads, and connectivity is a permanent design condition. Engineers often assume they can just add a surge protector or a bigger battery, but the real solution is to redesign the system from the ground up to treat the grid as hostile and intermittent, not as a reliable utility.
How can a project team build more infrastructure-aware designs?
Start with a detailed infrastructure audit before any hardware is chosen. Measure voltage stability, map actual signal coverage, and talk to the local people who will interact with the device. Design for the worst-case scenario—extended power loss, zero connectivity, difficult physical access—rather than the average. And involve local technicians and engineers from the beginning; they have practical knowledge that no datasheet can provide.
Is it more expensive to design for unreliable infrastructure?
It can be slightly more expensive upfront, especially if you add solar panels, larger batteries, and sturdy enclosures. But it is far cheaper than deploying a fleet of devices that die within a year and need to be replaced. The real expense is the cost of failure: lost data, damaged reputation, and communities that become skeptical of future technology initiatives. A design that works in the real environment is the most cost-effective approach over the lifetime of the project.
In the end, engineering is not about making things that work in a lab. It is about making things that work in the world. And the world is a lot messier, a lot less predictable, and a lot more interesting than any textbook will tell you. When we start treating infrastructure not as a backdrop but as the main character in our design stories, we will build technology that actually serves the people who need it most—not the people who already have everything they need.
Diego Almeida is an engineer and writer based in Brazil, focused on the intersection of hardware, field deployment, and the realities of infrastructure in Latin America.