Senior systems engineering · Singapore ↔ Europe

Hard systems problems.
Solved while Europe sleeps.

Compiler, platform, build and infrastructure work delivered in reviewable increments from Singapore. Hand off the hard part and start the next European workday with code, tests, findings or a decision.

Direct senior attention · Public evidence · Upstream-minded

  • Compilers & toolchains
  • Platform bring-up
  • Build & release
  • Systems R&D
10+ years of public work.

GHC, cross-compilation, linker behaviour, platform engineering and build systems. Inspect the record.

Direct senior attention.

The technical owner stays close to the problem and the result.

Singapore · UTC+8.

Live overlap for decisions and asynchronous execution for progress.

What we solve

Engineering below the framework layer.

We work where compilers, runtimes, operating systems, build systems and deployment constraints meet. GHC, Haskell and Nix are part of the public record—not the boundary of the work.

Compilers & language tooling

Compiler internals, backends, linkers, runtimes, source maps, cross-compilation and toolchain bring-up.

Platform enablement

ARM64, Apple Silicon, Linux, mobile, virtualisation and compatibility layers—from first execution to production behaviour.

Build, CI & release

Nix, Hydra, heterogeneous runners, binary caches, reproducible builds, release engineering and difficult failure diagnosis.

Focused systems R&D

Prototype difficult technical ideas, reduce uncertainty with working evidence and turn viable experiments into maintainable systems.

Fit is determined by the systems boundary, not by the application language.

Selected public evidence

Credibility you can inspect.

Public code, issue history, releases and technical writing let engineers inspect the work before a conversation starts.

Active flagship · reviewed August 2026

Selected Linux user-space binaries on macOS—without Docker or a full guest operating system.

hyper-linux

Problem

Linux executables are normally brought to macOS through containers or full virtual machines, adding weight and operational distance.

Work

hyper-linux uses Apple’s Hypervisor.framework, ELF loading and Linux-to-macOS syscall translation to run AArch64 Linux binaries—and x86_64 Linux binaries through Rosetta—inside lightweight per-process virtual machines.

What it demonstrates

Virtualisation, ABI translation, executable loading, syscall semantics, platform integration and systems debugging.

Inspect hyper-linux (opens in a new tab)
Active · CI and release infrastructure

Event-driven CI around Hydra, GitHub and Attic.

hydra-tools

Problem

Poll-driven integration creates delayed feedback, API pressure and awkward pull-request status handling.

Work

hydra-tools provides event-driven bridges for GitHub webhooks and checks, Hydra jobsets and build events, and automatic Attic cache population.

What it demonstrates

CI architecture, Nix/Hydra integration, event-driven systems, production-oriented tooling and operational failure handling.

Inspect hydra-tools (opens in a new tab)
Public record · reviewed August 2026

A decade of compiler, linker and cross-compilation work.

GHC and cross-platform engineering

Problem

Bring GHC and Haskell workloads to ARM, Android, iOS and Darwin targets while addressing the compiler, linker, Template Haskell, toolchain and build-system constraints exposed by those platforms.

Work

Public cross-compilers, target-prefixed toolchains, linker diagnosis, build-system changes, upstream discussions and a substantial engineering archive.

What it demonstrates

Compiler internals, platform bring-up, cross-compilation, linker behaviour, build systems, upstream stewardship and long-term technical continuity.

How we work

The handoff is only useful when the work is inspectable.

Live overlap resolves ambiguity. Everything else is organised so another engineer can reproduce, review, reverse and continue the work.

Work in the client’s system.

Use the real repository, build and failure context. Record access boundaries before work starts.

Make evidence durable.

Keep reproductions, traces, benchmarks, decisions and known dead ends with the change—not in a meeting transcript.

Escalate decisions early.

Surface missing access, conflicting constraints and architectural trade-offs while live overlap is available.

Upstream deliberately.

Coordinate with maintainers when public changes are practical; document the private integration when they are not.

Engagements

Start with the smallest useful commitment.

Most engagements begin with a bounded problem, a concrete decision or a reviewable milestone.

Describe the hard problem

A good fit when…

  • The failure crosses compiler, runtime, operating-system, build, CI, release, or deployment boundaries.
  • The team is losing time to uncertainty, reproduction failure, or specialist bottlenecks.
  • A technical owner can provide access and make—or escalate—the necessary decisions.

Probably not the right fit when…

  • The requirement is generic application development or the lowest possible hourly rate.
  • The request is undifferentiated staff augmentation with no bounded technical responsibility.
  • The requirement is 24/7 operations or on-call support that has not been separately agreed.

Who does the work

Direct senior attention.

Moritz AngermannPrincipal Systems Engineer

Moritz has more than a decade of public work around GHC, Haskell, cross-compilation, linker behaviour, ARM64, build systems and open source. zw3rk applies that depth more broadly to compiler, platform and infrastructure problems where continuity and technical ownership matter more than headcount.

The person discussing the problem remains accountable for the technical result. Any additional contributors should be identified before they access client work.

The original zw3rk dwarf-head logo

The name blends Zwerg, the German word for dwarf, with Werk, meaning work or craft. The original dwarf head remains the company mark.

“Hard systems problems” is not a euphemism for complexity theatre. It means reducing an uncertain technical problem to reproducible evidence, a reviewable change and a decision the team can act on.

Start with the hard part

Bring the problem everyone else calls “too niche.”

Share the environment, failure mode, constraints and outcome you need. We will first determine whether the problem is a fit, what evidence is missing and the smallest useful next step.