Hello! I'm Travis 👋🏻

We built a water reuse storage optimization tool for a network that is genuinely hard to reason about: pipelines with constraints on disposal, storage, and movement, plus an intake of water that varies over time. The goal was to optimize how water flows through that system, not against a single cost number but against a custom penalty system encoding our real costs and business strategy. Some destinations are cheap but strategically bad. Some movements are expensive but unlock capacity later. The penalties made those trade-offs explicit.

The prototype earned its keep

One of our engineers built the first version in Python with hardcoded values for everything: every constraint, every penalty, every node in the system, written straight into the script. It took about 4.5 minutes to run a single scenario.

This is not a criticism. The prototype did the most valuable thing software can do: it proved the model was right before we spent a dime on engineering. Hardcoding everything was the correct move. Abstraction before validation is how you end up with a beautifully architected system that computes the wrong thing.

Then he handed it to us to make it real.

Abstraction, then reformulation

The productization had two parts. The first was the obvious one: we abstracted the problem so the system of disposal and movement constraints became modular input instead of code. New pipeline segment, new storage rules, changed penalties: that’s data now, not a code change.

The second part is where the speed came from. The prototype’s logic could be re-expressed as a linear program: flows as decision variables, the disposal/storage/movement rules as linear constraints, and the penalty system as the objective function. Once the problem is in that shape, you don’t iterate toward an answer. You hand it to a solver that’s had decades of optimization research poured into it.

We used HiGHS, driven from Rust. Scenario processing went from 4.5 minutes to sub-second, roughly a 300× speedup, and honestly the solver deserves most of the credit. Rust made the surrounding machinery (parsing the modular constraint definitions, building the matrix, streaming results) fast and predictable, but the win was formulating the problem so a real solver could eat it.

Why sub-second actually matters

The difference between 4.5 minutes and under a second isn’t just impatience. It changes what the tool is. At 4.5 minutes, you queue a scenario, context-switch, and come back. It’s a batch report. At sub-second, commercial folks sit in front of it and riff: what if we take this contract, what if that disposal well caps out, what if we add storage here? The tool became a real-time thinking surface for what-if scenarios, and that’s when it started earning its keep commercially.

It worked extremely well.

The takeaway

Two lessons travel beyond water. First: judge prototypes by what they prove, not how they’re built. A hardcoded script that validates the model is worth more than a clean architecture that doesn’t. Second: before you optimize your algorithm, check whether your problem is secretly a linear program. If it is, forty years of solver research is sitting there, free, waiting to make you look good.

The work-history timeline on this page used to be rendered by ApexCharts. It’s a great library, but the bundle it shipped was 610 KB of JavaScript (169 KB gzipped) to draw six colored rectangles on a year axis. That was 92% of this site’s total JavaScript, on a page that is otherwise static HTML.

How it got there

Nobody picks a 600 KB dependency to draw six rectangles. It happens gradually: the chart starts as a real chart, with zoom, tooltips, animations, and a data series that might grow. Then the design tightens. Zoom gets disabled. The built-in tooltip gets replaced with a custom one that follows the cursor. Hover animations get turned off because they fight the design system. One day you look up and the library is doing exactly one thing: converting {start, end} pairs into absolutely positioned rectangles.

That conversion is arithmetic. It doesn’t need a runtime.

The replacement

Each job is a date range. The chart maps years to horizontal percentages, so a bar’s geometry is two numbers:

const left = ((X_MAX - job.end) / SPAN) * 100;   // % from the left edge
const width = ((job.end - job.start) / SPAN) * 100;

Astro runs this at build time and emits plain HTML: a relatively positioned plot area, absolutely positioned <button> elements for bars, and divs for gridlines. The bars are real buttons, so keyboard focus and click handling come free, something the SVG chart never gave me.

What survived as client-side JavaScript is the part that actually needs a browser: the cursor-following tooltip, the crosshair, and a label-fitting pass that shrinks a bar’s text until it fits inside the bar. About 100 lines, inlined into the page.

What it cost

Honestly? The bar entrance animation. The library animated bars growing on first render, and the static version just… exists. The card it lives in has its own entrance animation, so nothing feels broken, but it’s gone.

Everything else was even or better:

• 625 KB → 15 KB total page JavaScript (the remaining 15 KB is Astro’s view-transitions router)
• The chart renders before JavaScript executes, so no layout shift and no skeleton state
• The company names in the bars are in the HTML, so crawlers see the timeline now
• One less dependency to update forever

The takeaway

The interesting question isn’t “is the library good.” It’s “how much of it am I still using.” Config options you set to false are a decent proxy: my ApexCharts config had eleven of them. At some point disabling features costs more than owning the twenty lines that do the real work.

This site is a static Astro build served from a CDN. There is no React, no client framework, no hydration step. The total JavaScript budget is about 15 KB, and most of that is Astro’s view-transitions router. Everything else is HTML and CSS generated at build time.

The stack

• Astro renders .astro components to plain HTML at build time. Content that changes (work history, the tech stack, these takes) lives in data structures and markdown files, not in markup.
• Content collections hold the writing. Each spicy take is a markdown file with typed frontmatter; Astro validates the schema at build and renders the body to HTML. Publishing means committing a new file.
• UnoCSS provides atomic utility classes, purged to only what’s used.
• Netlify builds on push and serves static files. There is no server, which is most of the security and ops story.

Modals without a library

Every popup on this page, from the tech cards to these articles, is a native <dialog> element. The platform provides focus trapping, Escape-to-close, and backdrop rendering for free; the entire modal system is one component and one delegated click listener. The articles are server-rendered into the page, so search engines index the full text even though you see it in a modal.

The chart is divs

The work-history timeline is absolutely positioned HTML computed at build time. Each bar is a <button> whose left edge and width are percentages derived from start and end dates. It used to be a 600 KB charting library. That story has its own take.

Theming is two mechanisms

The color schemes are inline styles applied to cards from a curated palette array, with a random mode after the curated ones run out. Dark mode is a single .dark class on <html> driving CSS overrides, saved to localStorage and applied by an inline script before first paint so there’s no flash.

The point

None of this is clever, and that’s the argument. A personal site is mostly static content; the default architecture should be static files. Reaching for a framework runtime here would mean shipping megabytes to render what a build step can produce once. Boring technology, aggressively applied, is what fast feels like.

I manage our team's Kubernetes infrastructure, handling deployments, scaling, and observability. Experienced with helm charts, custom operators, ingress configuration, and maintaining production clusters. I ensure our applications run reliably at scale.

spicy take 🔥

Most teams reach for Kubernetes two years too early. But once you're past a handful of services and two environments, the alternative is reinventing it badly with shell scripts and hope.

My primary backend runtime environment. I leverage Node.js to build high-performance APIs, microservices, and real-time applications. Experience with Express, streaming data processing, and managing production Node deployments at scale.

spicy take 🔥

The event loop is still the best mental model for I/O-bound work. TypeScript is what made Node a serious backend, and most Node performance problems are actually JSON.parse in a hot path.

Used for performance-critical systems and tooling. I appreciate Rust's memory safety guarantees and use it for building fast, reliable backend services and CLI tools. Experience with ownership concepts, async Rust, and systems programming.

spicy take 🔥

The borrow checker is the best pair programmer I've ever had: pedantic, always right, and never tired. Slow to write, fast forever, and the right trade for anything on a hot path.

My go-to framework for building complex user interfaces. I have deep experience with React hooks, state management patterns, component architecture, and performance optimization. I build maintainable, scalable frontend applications that prioritize user experience.

spicy take 🔥

Hooks were a net win, but the state-management churn is self-inflicted. Most apps need a fetch cache and some local state, not a philosophy.

Essential for containerization and development workflows. I create optimized Docker images, manage multi-stage builds, and maintain our container registry. Docker is fundamental to our CI/CD pipelines and local development environments.

spicy take 🔥

Containers won because dev machines lie. If your Dockerfile is 200 lines, you have a config problem, not a Docker problem.

The backbone of modern web development. I use JavaScript extensively for both frontend and backend development, building interactive user interfaces and scalable server applications. My expertise spans ES6+ features, async programming, and performance optimization.

spicy take 🔥

Everyone's favorite language to dunk on still ships more working UI than anything else. The platform got genuinely good. Half of what frameworks sell is already in the browser.