Engineering

Design and build are not separate phases. An architecture that cannot be implemented, and code written without understanding the system it inhabits, both produce the same result: something that works until the pressure of real use reveals what was never thought through.

We design systems and write the software that runs them — treating every architectural decision and every line of code as part of the same continuous work. Whether the engagement starts with a greenfield design, a codebase that needs structure, or an infrastructure platform that needs custom tooling, the work begins from first principles and ends with something you can hand to the next person.

System Design

The first question is rarely "which technology?" — it is "where do the boundaries go?" Service decomposition decisions made early are expensive to undo. We approach system design starting from the operational model: how will this be deployed, monitored, updated, and recovered from failure, before committing to any component topology.

• Service decomposition — identifying the right boundaries, avoiding premature splitting and problematic coupling
• Container vs VM trade-offs — when LXC suffices, when KVM is needed, when Podman on a VPS is the right answer
• Storage architecture — choosing between relational, object, and block storage; backup and replication strategies from day one
• Failure mode analysis — identifying single points of failure, designing for graceful degradation rather than hard outages

Network and Identity Design

Network topology decisions compound over time. A flat network that grows to twenty hosts becomes a management problem; retrofitting VLAN segmentation onto an established environment is painful. Identity built as an afterthought produces a fragmented set of credentials — one per application, no central revocation, no audit trail. We design both as first-class concerns from the start.

• Network segmentation — VLAN design, inter-VLAN routing policies, DNS architecture, VPN topology
• Reverse proxy design — NGINX as TLS termination and routing layer; upstream health checks and failover
• Identity architecture — federated SSO design anchored on a central directory with OIDC/OAuth2 federation for modern applications
• Zero-trust access patterns — per-application authentication policies, VPN-gated access to internal services, minimal lateral reach

Software Development

Custom software for real operational problems — the kind of work where off-the-shelf tools do not quite fit, and the problem is specific enough to warrant something built properly. We write production code in Rust, Python, and shell, choosing the right tool for each job and making sure what we build can be read, tested, and maintained by whoever comes next.

This site is a working example: a self-hosted multilingual web server written in Rust, serving requests with zero runtime file I/O, deployed as a Podman container and built by a self-hosted Forgejo CI pipeline. Every architectural choice is visible, auditable, and replaceable.

Rust — for services where performance, binary size, and correctness matter. No garbage collector, no hidden allocations, starts in milliseconds. HTTP services built on Axum and Tokio's async runtime.

Python — for automation, data pipelines, glue code, and any context where iteration speed matters more than throughput. The ecosystem for infrastructure automation — REST clients, SSH orchestration, cloud SDKs — is mature and practical.

Shell scripting — for deployment automation, init scripts, and anything that composes existing Unix tools. A well-structured, well-tested Bash script is often the correct answer and the easiest one for an operator to debug at 2am.

Infrastructure Tooling

Much of the most valuable development work at the infrastructure layer is automation that removes the need for humans to repeat the same steps. We build tools that talk to the Proxmox API, generate configuration from templates, verify system state, and wire CI pipelines together end to end.

• Proxmox automation — creating, configuring, and managing VMs and containers via the Proxmox REST API
• Configuration generators — tools that produce valid NGINX, WireGuard, or other configuration from a higher-level description, eliminating hand-editing
• Forgejo CI pipelines — pipeline definitions for build, lint, test, and deploy; staging and production promotion workflows
• Practices — feature branches, reviewed merges, self-hosted CI with a dedicated runner, reproducible builds, pinned dependencies

Review and Guidance

Not every engagement starts with greenfield design. We also take on systems that have already been built — producing architecture reviews, identifying risks, and writing Architecture Decision Records to capture context that currently exists only in people's heads.

• Architecture reviews — systematic review of existing systems against stated goals, constraints, and operational reality
• Architecture Decision Records — documenting why decisions were made, not just what was decided, so future engineers inherit the reasoning
• Risk identification — finding the gaps between design intent and what the system actually does under load or failure
• Technical mentoring — working alongside teams to build judgment and operational instinct, not just deliverables

Who this is for

Engineering teams that have outgrown their initial setup and need to make deliberate choices about where to go next. Infrastructure teams who need automation they can trust — tools that behave predictably and can be handed to the next person without a verbal briefing. Anyone who has inherited a system and needs to understand it clearly before changing it.