Skip to content

CONCEPT Cited by 1 source

Appropriate Technology

Appropriate technology is Werner Vogels' framing for choosing the stack that fits the customer's actual constraints, not the stack that is most advanced. The design process starts from what the customer has — the phone in their pocket, the network available to them, the dollars they can spend — and works backward. Sophistication is hidden in the backend where it is cheap; the user-facing surface is whatever is suitable, not whatever is shiny.

"This isn't a story of technology limitations causing hardship. It's about builders who are focused on technology that is suitable, not shiny." (Source: sources/2025-10-29-allthingsdistributed-what-is-ussd-and-who-cares)

"The limitations of materials are honesty in design. What you can't do is as important as what you choose to do." — Santiago Calatrava, quoted by Werner.

The specification trick

Constraints aren't obstacles to engineer around — constraints are the specification. Once you internalize that, the design question flips:

Shiny-first framing Appropriate-tech framing
"How do we ship smartphones to them?" "What can we build with the phones they have?"
"When will 4G reach them?" "What works on 2G today?"
"How do we reduce the price of X?" "What fits the $20 hardware they already own?"

The shiny-first path waits for the customer's world to change. The appropriate-tech path ships value today and profits today. Werner's point: hundreds of millions of people cannot wait for technology to catch up to their everyday needs.

Canonical instance: USSD-frontend payments

The Sub-Saharan Africa payment platforms — systems/mpesa, Moniepoint, Mukuru, OPay — reuse systems/ussd, a 1990s GSM signalling protocol, as their primary user interface. Behind it sit modern cloud payment platforms with ML fraud detection and 4K TPS throughput. M-Pesa alone processed >$100B in 2024.

The USSD menu is "primitive" only if sophistication is measured by how much of the stack the user touches. Measured by volume, cost to operate, and customer reach, it is the right frontend.

See patterns/feature-phone-frontend for the architectural shape.

Canonical instance: KOKO Networks

systems/koko-networks operates 700+ bioethanol vending stations across Africa — each an IoT endpoint streaming real-time inventory to a cloud platform for demand forecasting. The customer tops up cooking fuel from a feature phone. The IoT mesh behind is state-of-the-art. The user's experience is unchanged from the pay-a- bill-by-feature-phone workflow they already know.

Relationship to simplicity-vs-velocity

concepts/simplicity-vs-velocity (Warfield's S3 framing) is the builder-side statement: ship velocity and then pay down the simplification debt. Appropriate technology is the customer-side statement: simplicity is measured in the customer's world, not the builder's world. The two combine into Werner's closing line in the USSD post:

"The best engineering blends into the background of everyday life. You don't think about driving your car or paying for groceries. No one writes headlines when someone sends money from Lagos to Kigali or uploads a file to S3. When technology works so well that it's practically invisible — that's probably the best compliment you can get."

Invisibility and appropriateness are the same doctrine read from two sides.

Failure modes

  • Projection bias — assuming the customer's world is a delayed version of the builder's world. ("They'll have smartphones eventually / we can wait.") The GSMA forecast that ~1/3 of Sub-Saharan Africa connections will still be 3G in 2030 is the cautionary data point.
  • Shiny substitution — building the backend appropriately but insisting on a smartphone-only frontend, excluding the customer.
  • Engineering-for-engineering — "the temptation to engineer for the sake of engineering" (Werner). The fix: always work backward from real customer needs (patterns/pr-faq-writing, patterns/customer-driven-prioritization).
  • Underestimating the backend — reading "USSD" as primitive and assuming the whole system is primitive. M-Pesa runs 4K TPS with real-time ML fraud detection on AWS. The frontend is simple; the system is not.

Broader principle

Werner frames Sub-Saharan Africa as a blueprint — not a special case:

"That's why what's happening in Sub-Saharan Africa isn't just impressive in a regional context, it's a blueprint to build more resilient, efficient, cost-aware systems anywhere in the world."

Every system has constraints (latency budget, cost envelope, operational reach). Appropriate technology generalizes the Sub-Saharan-Africa lesson: honest reading of the constraints is the starting point of good system design anywhere.

Seen in

Last updated · 200 distilled / 1,178 read