One engineer, generalist by choice.

Penumbra Tech is the single-engineer consulting and software practice of Wesley Weaver Jr. I started programming because something was broken and nobody else was going to fix it. That mindset still drives the work I take on.

I'm a deliberate generalist. Most useful software doesn't live cleanly inside “front-end,” “back-end,” “cloud,” “database,” or “operations.” It lives in the seams between them: a customer clicks something, a request moves through infrastructure, business logic runs, data changes, the interface responds, and someone has to understand the whole chain well enough to make it reliable. A generalist optimises the seam. That's where I work best.

Before Penumbra Tech, I built and ran Penumbra Group, Penumbra PC, and Penumbra Productions: years of hands-on technical work with real customers, real deadlines, and real consequences. Before that, I spent more than a decade in the U.S. Navy nuclear pipeline and related technical roles: power plant operations, radiological controls, analytical chemistry, LAN administration, maintenance, documentation, watchstanding, and systems where “probably fine” was never an acceptable engineering standard.

That background shaped how I build software. I like systems that are observable, explainable, maintainable, and boring in the right places. I like code that survives contact with users. I like infrastructure that can be rebuilt from notes instead of mythology. I like finding the actual constraint instead of throwing libraries at symptoms.

The work I take on tends to fall into four buckets: full-stack web applications, AWS infrastructure, Unreal Engine systems, and performance / reliability work. The projects section includes live, exercisable examples, including a traditional EC2 stack benchmarked head-to-head against the same idea built serverlessly on Lambda + DynamoDB + S3.

Outside of consulting I build game prototypes, work in Unreal Engine C++, do photography, restore and maintain physical spaces, and write up what I learn. Different domains, same engineering instincts: define the system, find the failure points, improve the loop.

Engineer

I write production code, not slides about code. SQL through React. Linux through user interface. AWS through deployment. I care about whether the thing works after someone else has to use it.

Problem solver

When a system is broken, the useful question is rarely "which library should we add?" It's "what constraint are we actually fighting?" I'm comfortable in unfamiliar codebases, half-documented systems, and projects where the problem is spread across software, infrastructure, people, and process.

Maker

Software, photography, game systems, hardware tinkering, documentation, physical builds: they all train the same muscle, turning vague intent into working structure. The cross-pollination is part of the point.