Low-Tech

Low-Tech Begins Before the Technology

With technical tasks, the discussion often begins with a possible solution:

Which software do we use?
Which server do we need?
Which platform do we use?
What can we automate?

A Low-Tech approach starts one step earlier:

What do we actually need?

Only when the actual need is sufficiently understood can it be assessed which technical solution is appropriate for it.

This turns:

Problem
   ↓
select technology

more into:

understand need
      ↓
determine necessary function
      ↓
examine constraints
      ↓
compare possible solutions
      ↓
appropriate technical solution

Technology is therefore a means of solving a problem and not the starting point of the analysis.

Appropriate Is More Important Than Minimal

Low-Tech does not mean:

as little technology as somehow possible

A solution must reliably fulfill its purpose.
If a system requires encryption, redundancy, or a more complex database, for example, doing without them can be the worse solution.

The relevant question is therefore not:

“What is the simplest conceivable solution?”

But:

“What is the simplest solution that sufficiently meets our actual requirements?”

The small word sufficiently is decisive here.

Complexity Has Costs

Technical complexity is not free.

Every additional component can bring new properties:

configuration
dependencies
updates
security vulnerabilities
failure states
interfaces
monitoring
backups
documentation
specialist knowledge

This does not mean that additional components should generally be avoided.
However, they should provide sufficient benefit to justify their additional costs and dependencies.
A component that solves a relevant problem can be useful.
A component that is mainly needed to manage the complexity of other unnecessary components deserves at least a second look.

Understandability Is a Technical Property

A system can work excellently from a technical perspective and still be difficult to manage.
If changes are only possible after several specialists have examined different parts of the system, the complexity has practical effects.

A more understandable system, by contrast, can more easily be:

• examined
• modified
• repaired
• tested
• documented
• migrated
• restored

Understandability is therefore not merely a matter of good documentation.
It can be a property of the architecture itself.

Repairability

Low-Tech often considers not only the creation or introduction of a solution.
Its further life cycle is also relevant.

This includes the question:

“What happens when something breaks?”

A repairable system makes it possible, for example, to:

detect fault
      ↓
identify affected component
      ↓
repair or replace component
      ↓
continue operating system

A system that has to be replaced completely because of a small defect can, by contrast, require considerable additional resources.
With software, repairability does not correspond directly to replacing a mechanical component.

Similar questions nevertheless exist there as well:

• Can faults be localized?
• Are components separated from one another?
• Can individual parts be replaced?
• Is data accessible independently of the application?
• Is the system sufficiently documented?
• Can an older functioning version be restored?

Maintainability and Durability

A technical solution is not built only for the moment of its introduction.

During its operation, the following may become necessary:

updates
repairs
adaptations
migrations
extensions

A Low-Tech approach therefore considers whether a system can be operated sustainably with reasonable effort.
A technically impressive solution can be excellently suited to a short-term prototype.
For a service intended to operate for twenty years, other properties may be more important.

Continuing to Use What Already Exists

A new technical solution does not automatically have to begin with a new system.

Often, there are already:

• functioning hardware
• software
• data
• processes
• interfaces
• specialist knowledge

A Low-Tech approach therefore also examines whether what already exists can continue to be used, repaired, or adapted.
This does not mean preserving Legacy Systems as a matter of principle.
If an existing system no longer meets its requirements or its dependencies become unmanageable, modernization may be necessary.

The first question is simply:

“What do we actually have to replace?”

and not:

“What can we rebuild from scratch?”

Low-Tech Can Include Modern Technology

A Low-Tech system does not have to consist of old technology.
A modern microcontroller can, for example, enable a much simpler and more resource-efficient solution than a complex mechanical control system.
A small modern server can replace numerous older devices.
Current software can considerably simplify a previously complicated process chain.
The age of a technology is therefore not decisive.
What matters is its role within the overall solution.
High-Tech components can be part of a Low-Tech architecture.

Low-Tech Is Relative to the Problem

The same technical solution can be assessed differently for two problems.

Suppose an application requires:

20 users
a few thousand records
one internal interface
one location

A distributed platform with numerous independent services could be unnecessarily complex for this.

Another application has:

several million users
locations worldwide
independent development teams
high load
different availability requirements

There, the same technical mechanisms can fulfill an actual need.
Technologies are therefore not inherently Low-Tech or High-Tech.
Their appropriateness depends on the respective system.

Low-Tech Is Not a Return to the Past

The term is sometimes associated with old or pre-industrial technologies.
Historical solutions can be interesting because they were often developed under different resource constraints.
That does not automatically make them the better solution.

Low-Tech does not ask:

“How would this have been done in the past?”

But:

“Which solution meets our current need with appropriate technical effort?”

The answer can be a hundred years old.
It can have been developed yesterday.
Or consist of a combination of both.

Resource Conservation

An important part of many Low-Tech approaches is the conscious use of resources.

These can include:

• energy
• raw materials
• hardware
• storage
• computing power
• network traffic
• working time
• specialist knowledge

Resource consumption should not be considered only during normal operation.
Manufacturing, maintenance, replacement, updates, and disposal can also be relevant.
A system that requires little energy in operation but has to be replaced completely every two years has a different life cycle from a system that can be repaired over the long term.

Automation Is Not an End in Itself

Not every manual process has to be automated.

Automation can:

• reduce errors
• avoid repetitive work
• increase speed
• improve reproducibility

However, it also creates:

• software
• rules
• dependencies
• maintenance
• possible failure states

For a process that takes five minutes once a year, complex automation can create more effort than it saves.
For a process that is performed a thousand times a day, the same automation can be indispensable.

The relevant question is therefore:

“What form of automation makes sense for this process?”

Low-Tech and Digitalization

From this perspective, digitalization is also not an end in itself.
An existing analog process can be inefficient or error-prone.
In that case, digitalization can create substantial benefits.

But an analog process can also be:

simple
understandable
fast
reliable
cost-effective

Its digitalization does not then automatically create added value.

Before the question:

“How do we digitalize this process?”

there is therefore:

“What problem do we want to solve with it?”

Low-Tech and Resilience

A manageable system can be more resilient because its dependencies can be understood more easily.
In the event of a disruption, it may be possible to identify more quickly:

What has failed?
Which function is affected?
What alternative exists?
How can operation continue?

Lower complexity does not, however, guarantee Resilience.
A single simple component with no replacement option can represent a critical single point of failure.
Resilience and Low-Tech can therefore support each other, but they are not identical.

Low-Tech and Digital Sovereignty

Digital Sovereignty can also benefit from a Low-Tech approach.
An understandable and manageable system makes it easier to recognize dependencies and evaluate alternatives.
If an organization no longer sufficiently understands its own infrastructure, formal technical control can produce little practical ability to act.
Low-Tech can therefore help keep systems at a scale and level of complexity that match the capabilities and resources actually available.

Low-Tech and Self-Hosting

Self-Hosting can be Low-Tech.
But it does not have to be.
A small self-hosted service with a few understandable components can fit a Low-Tech approach very well.
A self-hosted platform consisting of dozens of services that remains functional only with considerable specialist knowledge is not a Low-Tech solution merely because it is self-hosted.
Conversely, an external service can be the more appropriate solution if it reliably performs a non-critical task and thereby avoids substantial infrastructure of one’s own.
The actual need remains decisive.

Low-Tech Is Not Hostility to Technology

A Low-Tech approach does not reject technology as a matter of principle.
It merely asks an additional question:

“Do we really need this technology here?”

If the answer is:

yes

and there are comprehensible requirements for it, the Low-Tech approach does not argue against its use.
The criticism is directed less against technical capability than against unnecessary technical complexity and inappropriate use of resources.

Why Low-Tech Has Practical Effects

• The need comes before the technology: First, it is examined which function is actually required.
• Additional complexity must be justifiable: Additional components can create further costs and dependencies.
• Understandability is taken into account: Manageability can be a relevant system property.
• Existing systems are not automatically replaced: Maintenance and continued use can make more sense than rebuilding.
• Automation is weighed up: Not every possible process has to be automated.
• Digitalization is questioned: A functioning analog process does not need software merely because software is available.
• Modern technology remains possible: Low-Tech does not mean old technology.
• Resources are considered across the life cycle: Operation is only one part of the technical effort.
• The solution remains context-dependent: What is unnecessarily complex for one system can be necessary for another.

Typical Example

An organization wants to transfer a small file between two internal systems once a day.

Option A uses:

multiple containers
Message Broker
Workflow Engine
database
monitoring platform
orchestration

Option B uses:

a small program
an existing scheduler
a log file
an error notification

If Option B meets all actual requirements, it can be the more appropriate solution.

If the requirements later change:

thousands of transfers per minute
multiple independent systems
complex retry logic
distributed processing
high availability requirements

Option A or a comparable, more complex architecture can become appropriate.

Low-Tech therefore does not prescribe:

Choose Option B.

Rather, the approach requires:

Justify why you need Option A.

Distinction

• Low-Tech refers to a design approach that starts from the actual need and aims for an appropriate, understandable, durable, and manageable technical solution.
• High-Tech refers to technologies based on a high level of technical development or specialized technical methods. High-Tech and Low-Tech do not have to be opposites; High-Tech components can be part of an appropriate Low-Tech solution.
• Simplicity is one possible property of a Low-Tech solution. However, the technically simplest solution is not automatically the most suitable.
• Resilience describes the ability of a system to maintain, restore, or adaptively continue essential functions under disruptions and changes. Low-Tech can support Resilience.
• Digital Sovereignty describes the ability to remain capable of making decisions and taking action in the presence of digital dependencies. Understandable and manageable systems can support this ability.
• Self-Hosting refers to operating a service under one’s own technical and organizational responsibility. It can be part of a Low-Tech strategy, but is not identical to it.

Further Reading

Related Concepts

→ Systems Analysis
→ System Architecture
→ Resilience
→ Fault Tolerance
→ Observability
→ Digital Sovereignty
→ Self-Hosting
→ Legacy System