A little while ago I was asked to help a large international humanitarian organisation think through some of its data architecture. I'm going to be deliberately vague about the who and the what, because that's the respectful thing to do, but I can talk about what I learned — and what I learned surprised me, because it reshaped how I think about architecture generally, not just for non-profits.
Here's the short version, up front: constraints make you a better architect, and a mission-driven organisation with almost none of the usual resources imposes exactly the constraints that force good decisions. Everything I'd learned building well-funded corporate systems got usefully interrogated the moment none of the usual assumptions held.
The assumptions that quietly evaporate
When you architect for a corporate client, a set of assumptions sits underneath your decisions so reliably that you stop noticing them. Advising here, one by one, they fell away.
- "We can hire specialists to run this." In a corporate build you can design something sophisticated because you assume a team will be hired or contracted to operate it. Here, the people who'd inherit whatever I designed were a tiny, stretched, mission-focused team who would never have a dedicated data engineer. That single fact rules out a whole class of clever-but-fragile designs. If they can't run it, it doesn't matter how good it is — it's already failed.
- "Budget is a constraint we optimise, not a wall we hit." Corporate cost conversations are about optimisation. Here, cost was a hard wall with real human stakes on the other side of it — every euro spent on infrastructure was a euro not spent on the mission. That reframes "is this worth it" from an efficiency question into something close to an ethical one.
- "Connectivity is a given." So much of what we build assumes reliable, always-on connectivity. A lot of this organisation's actual work happened in places where connectivity was intermittent at best. A design that assumes the network is always there isn't just suboptimal in that context — it's useless exactly when it's needed most.
None of these are exotic. They're just the assumptions a comfortable budget lets you never examine — and examining them made me better.
What good architecture actually meant here
Strip those assumptions away and "good architecture" stops meaning "sophisticated" and starts meaning something much harder: appropriate. The best design was the one that matched the actual capacity of the people who'd live with it, not the one that showed off what was technically possible.
Concretely, that pushed me toward decisions I'd rarely make in a corporate setting:
- Boring, managed, and simple beat clever every time. Anything that reduced the operational burden — managed services over self-hosted, simple over flexible, fewer moving parts over more — was worth more than any feature. The goal was a system that kept working when nobody was watching it, because nobody would be watching it.
- The total cost of ownership included the humans. The real cost wasn't the monthly Azure bill. It was the attention the system demanded from a team that had none to spare. A design that saved money but demanded expertise they didn't have was more expensive, in the currency that mattered, than a slightly pricier one that just ran.
- Sustainability meant "survivable without me." The measure of success was whether the thing would still be working in two years, run by people who weren't there when it was built and couldn't call me. That meant documentation a non-specialist could follow, and deliberately choosing the well-trodden path over the elegant one, because the well-trodden path is the one they could get help with.
The part that was pure communication
There was another thread running through all of it, and it's the one that connects this to everything else I care about: most of the value I added wasn't technical. It was translation.
The organisation had genuine data needs and a team who understood their mission deeply but weren't data people. My job, more than drawing architecture diagrams, was to sit in the gap between "what the technology can do" and "what you actually need," and translate honestly in both directions — including, crucially, translating away from the impressive thing they'd half-heard they should want, toward the modest thing that would actually serve them. Talking a stretched team out of a data lake they didn't need was worth more than any pipeline I could have built.
The hardest and most valuable architectural decision is usually subtraction — the sophisticated thing you talk someone out of, because you can see they'll never be able to run it and you care more about them than about the design.
The decision I'm proudest of
Let me make this concrete with the decision I'm most pleased with, because it was a subtraction. Somewhere in the early conversations, the phrase "data lake" came up — someone senior had heard it was what a modern data organisation ought to have, and there was a genuine, well-meant enthusiasm to build one. And they didn't need it. Not "didn't need it yet" — didn't need it. Their data was modest in volume, reasonably structured, and asked a small, predictable set of questions. A data lake would have been a large, sophisticated, perpetually-operated answer to a question they simply weren't asking.
So a good chunk of my actual contribution was, gently and with evidence, talking them out of it — and toward something that would answer their real questions on infrastructure they could afford and, crucially, keep running. That's an uncomfortable thing to do, because "you need less than you think" is not what people expect from someone they've brought in to help, and it can read as under-delivering. But the alternative — letting a stretched team build something impressive they'd be quietly crushed by within a year — would have been a failure dressed up as a deliverable.
Designing for a network that isn't there
The connectivity constraint deserves its own note, because it inverted a habit. In corporate work you design for the network and treat outages as exceptions to recover from. Here, intermittent connectivity was the normal condition — which meant the design had to treat "no network right now" as an ordinary state to keep functioning through, not an error state to survive.
Practically, that pushed everything toward capturing and holding data locally, near where it was produced, and syncing opportunistically when a connection appeared — rather than assuming a live pipe to the cloud that wasn't reliably there. It's a different posture: offline-first, where the system does its job disconnected and treats connectivity as the bonus that lets it catch up, not a prerequisite it collapses without. Building that way is more effort up front, and it's the only thing that actually works in the field. And — like nearly everything this project taught me — it turned out to be an idea I've wanted in plenty of comfortably-connected contexts since.
The handover was the deliverable
There's one more thing that reframed the whole engagement for me, and it's about what "finished" meant. On a corporate project, you deliver a system and, often, you or someone like you stays close to run it. Here, from the first day, I knew the measure of success was whether the thing kept working after I was completely gone — run by people who weren't there when it was designed and couldn't ring me when it broke.
That inverts what the actual deliverable is. It wasn't the architecture. It was the handover — the documentation a non-specialist could genuinely follow, the deliberate choice of well-trodden technologies precisely because they're the ones you can find help for, the ruthless simplicity that meant there was less to understand and less to go wrong. I spent more care on "will this be legible to a stranger in two years" than on any single technical decision, because that legibility was the product.
And it changed how I judged every choice along the way. A slightly more elegant design that only I would ever fully understand was, by this measure, a worse design than a plainer one the team could own. Cleverness that concentrates knowledge in the builder is a liability when the builder is leaving. So I kept choosing the boring, documented, survivable option — and kept having to resist the engineer's instinct to show what I could do, in favour of building what they could keep. The best thing I left them wasn't a platform. It was the ability to run one without me.
What I took away
I went in thinking I was there to lend expertise to an under-resourced team. I came away having had my own assumptions usefully dismantled. Because good architecture in a resource-rich environment can hide behind sophistication — you can throw people and money at a fragile design and keep it alive. In a resource-poor environment, there's nowhere to hide. The design has to actually be right — appropriate, survivable, matched to the humans — or it dies, quickly and visibly.
That's a clarifying place to design from, and I've carried it back into my well-funded work ever since. Now, even when there's budget to spare, I try to ask the question the non-profit forced on me every time: not "what's the best system I could build here?" but "what's the best system the people who'll actually live with this could run?" Those are different questions, and the second one is almost always the one that matters. It took an organisation with nothing to spare to teach me that the constraint wasn't the problem. The constraint was the point.