Principal engineer · architect · builder

Make the important parts clear.

I design and build software that people can understand, operate, and change safely. My interests sit at the intersection of architecture, developer experience, and the practical details that make systems work in the real world.

See selected work ↓Connect on LinkedIn ↗

Software architectureDeveloper experienceKotlin & JVMSystems that last

Selected work

Projects with a point of view.

I use side projects to make ideas concrete: build the thing, expose the tradeoffs, and leave behind something another engineer can learn from.

Architecture · Kotlin01

Vanilla Kotlin

A reference implementation of Kotlin microservices without an application framework.

Dependencies are wired explicitly through composition roots and function injection, on top of http4k, JDBI, Kafka, PostgreSQL, RocksDB, and OpenTelemetry. The value is not minimalism for its own sake; it is visibility. Routes, configuration, lifecycle, and boundaries stay available for inspection.

Kotlinhttp4kKafkaJDBIOpenTelemetry

Read the repository ↗

Infrastructure · Fedora02

A MacBook with a job to do.

A reproducible homelab built around a rescued MacBook: Docker Compose, Tailscale-only services, a 3D-print library, monitoring, and operational recovery.

The project is deliberately small and observable. It is a place to practice the boring, valuable parts of infrastructure: startup ordering, health checks, storage boundaries, logs, and failure recovery.

Follow the notes ↓

Product experiments03

Tools for real life.

From tabletop tools to small household and hobby projects, I like software that earns its place by removing friction from something people actually do.

That means starting with the workflow, keeping the surface area honest, and accepting that a useful tool is often more valuable than an impressive platform.

Browse the projects ↗

How I work

Clarity is a feature.

Good engineering is not just making software function. It is reducing the amount of mystery the next person has to carry.

Make boundaries visible.

Names, interfaces, composition roots, and operational seams should explain the system instead of hiding it.

Prefer recoverable decisions.

Choose designs that can be inspected, tested, rolled back, and understood under pressure.

Optimize for the whole lifecycle.

Deployment, observability, documentation, and maintenance are part of the product—not chores after the “real” work.

Writing & notes

Things I want to think out loud about.

Architecture

What frameworkless Kotlin makes visible

Composition roots, explicit dependencies, functional injection, and the tradeoff between convenience and comprehension.

Planned note

Infrastructure

Reviving a 2015 MacBook as a homelab

What happens when a personal server is treated like a small production system: reproducibility, storage, health, and graceful failure.

In progress

Practice

Systems should teach you how they work

Notes on developer experience, architecture communication, and building software that helps its operators form a correct mental model.

Planned note

A little context

Serious about software. Not precious about it.

I’m Jake Luby. I’m a principal engineer who enjoys the space where technical decisions meet human context: how teams reason about a system, how developers experience a codebase, and how a product survives contact with its users.

Outside of work, I paint miniatures, play tabletop and strategy games, build tools for family life, and keep finding excuses to learn another corner of the stack.