About me

Building Under Constraint: My Engineering Philosophy, Distilled

I never set out to design an engineering philosophy.

There was no whiteboard session, no manifesto-writing moment, and no grand declaration of how I’d build things. What happened was simpler: I spent years building systems alone, under tight constraints, and a pattern quietly emerged.

At first it was just survival—no racks of GPUs, no institutional safety net, no budget to burn. Just me, an idea, and a machine that had to do far more than it reasonably should. But over time, that survival instinct hardened into something bigger: a way of thinking about engineering.

Constraint Is the Forge

If you’ve ever worked under real constraint, you know it changes how you build.

Every line of code, every architecture decision, and every library import has to justify itself.

It’s not minimalism for the sake of aesthetics—it’s minimalism because waste is not feasible. If I want to ship anything.

Example 1: Writing a Compiler Toolchain

One of the hardest things I ever did was write my own compiler toolchain from first principles. Not because I wanted to show off—but because I needed to.

I was optimizing memory for ML pipelines, and while frameworks like TVM and XLA exist, I wanted to understand how they worked under the hood. I wanted intuition, not just abstraction.

Sometimes the only way forward is to dig to bedrock, even if there’s an easier-looking trail on the surface.

That project was painful, but it gave me deep insight that I couldn’t have gained from docs alone.

Example 2: Building an Inference Engine

On the other hand, when I needed to spin up an inference application, I didn’t touch the bedrock at all.

Done.

Why? Because serving APIs and containerization are solved problems. Reinventing them wouldn’t have made the application better—it would’ve slowed it down.

This was the flip side of the compiler lesson:

You don’t get extra credit for re-solving what’s already been solved a thousand times.

The only thing that matters is delivering the value unique to your system.

The Balance

So what emerged is a simple balancing act:

  1. If the goal is deep insight or a hyper-specific problem, go to first principles.
  2. If the goal is delivery and practicality, stand on existing frameworks.

Think of frameworks as scaffolding and scratch work as a scalpel. The art is knowing when to use which.

Why This Matters (Even If You Have Resources)

For me, this approach was born out of necessity. When you’re solo, you don’t get to waste compute or time. You learn to be ruthlessly efficient, or you don’t ship at all.

But here’s the twist: even if you’re inside a company with racks of GPUs and a budget to burn, the same philosophy applies.

Constraint can be self-imposed. And in many cases, it should be.

Constraint forces clarity. It makes systems leaner, faster, and easier to maintain. It forces you to ask, “What actually matters here?”*

Closing

I never sat down to invent this philosophy. It emerged on its own. But looking back, it’s become a compass:

Build when you must. Reuse when you can. Always stay lean.

That’s how I survived as an independent engineer with nothing but an idea and a machine. And maybe—whether you’re solo or working inside a big company—it’s a principle that can help you cut through complexity too.