I’m Landry.

I started as a mechanical engineer. Spent years thinking about how physical systems work: forces, tolerances, failure modes. Everything connected to everything else. Change one variable, watch the ripple effects cascade through the system. That way of thinking never left me.

Then I moved into technical product management. Different domain, same principles. Instead of translating between physics and manufacturing, I was translating between business needs and technical teams. Requirements became architectures. Problems became roadmaps. I learned that the best solutions come from understanding both sides deeply: what people need and what systems can actually deliver.

The Startup Years

In 2019, I founded TicketsPlug, an event management platform. Two years of late nights, endless iterations, and hard lessons about building products people actually want. In 2022, I started Katikaa, a sports engagement platform. Neither company got where I wanted them to be.

But I architected both end-to-end. Backend systems, frontend interfaces, cloud infrastructure, deployment pipelines. All of it. Those experiences taught me more about building real systems than any course or certification ever could. Failure is expensive education, but it sticks.

Why I Build My Own Infrastructure

Somewhere along the way, I got tired of renting my digital life.

Every month: cloud storage fees, subscription apps, AI services that might disappear tomorrow. Thousands of dollars a year flowing to companies running software I don’t control, on servers I can’t see, governed by terms that change without notice. My data scattered across dozens of platforms, each one a potential point of failure.

So I started building my own.

I built a data center in my home. Rack-mounted servers humming in a closet. A 6-node Kubernetes cluster running everything from document management to workflow automation. Dedicated GPU machines with RTX cards for AI inference. Mac Ultras and Mac Minis running local LLMs, completely offline. The network runs on UniFi gear: managed switches, access points in every room, VLANs separating work from home from IoT devices. Security cameras recording 24/7 because with four kids, you need eyes everywhere.

Everything stays local. Everything stays private. No cloud dependencies for the things that matter most.

This isn’t cheaper than subscriptions. The hardware costs real money. The time investment is significant. But ownership matters. When I record a voice memo, it stays on my network, gets transcribed by my own Whisper instance, summarized by my own LLM, and lands in my own knowledge base. My thoughts don’t train someone else’s model. When a service shuts down, my data doesn’t vanish with it.

The Tinkerer’s Life

I can’t leave things alone. If it has a chip and I can program it, I’ll find a use for it.

Arduinos controlling sensors around the house. Raspberry Pis running home automation tasks. ESP32s scattered everywhere doing odd jobs: monitoring temperatures, triggering alerts, bridging protocols. I’ve lost count of how many single-board computers are running in this house at any given moment.

The homelab grew organically. What started as “let me try self-hosting one thing” became a full infrastructure practice. GitOps for managing deployments. Every change goes through Git, gets reviewed, deploys automatically. MLOps for model lifecycle management. AI pipelines automating the boring stuff so I can focus on interesting problems.

The Six-Person Household

My wife and I have four children. Six people under one roof. Beautiful chaos, every single day.

Kids are like microservices. Each one has its own personality, its own failure modes, its own scaling challenges. Unlike Kubernetes, they don’t come with a --help flag. There’s no rollback when someone flushes a toy down the toilet.

This is why I automate relentlessly. Not because I love automation for its own sake, but because a six-person household generates infinite small tasks. If something can be scripted, scheduled, or systematized, it should be. The goal is simple: spend less time on logistics, more time on what actually matters.

The infrastructure serves the family, not the other way around. Cameras keep kids safe. Automation handles the repeatable. Documentation means I’m not debugging the same problem twice. Everything I build at home is in service of making this distributed system (work, marriage, parenting, side projects) a little more manageable.

How I Think

Automate the repeatable. If I do something twice, I write a script. If I do it three times, it becomes a CronJob. Machines should handle the boring stuff.

Learn by building. I don’t read documentation for fun. I spin up the thing, break it, fix it, and write about what I learned. Every post on this blog started as me debugging something at 2 AM.

Document everything. Future me has the memory of a goldfish. If I don’t write it down, it didn’t happen. This site is my external memory: searchable, linkable, version-controlled.

Ship ugly, iterate fast. Perfect is the enemy of deployed. I’d rather have something running in production today than a beautiful architecture diagram that never ships.

This Blog

Every post here is a snapshot of me figuring something out. Some are polished. Most are “here’s what I learned the hard way.” All are honest.

If my debugging sessions help one person solve their problem faster, it was worth writing.

The infrastructure behind all of this is open source: fako-cluster. Take what’s useful.

“The best way to predict the future is to invent it.” - Alan Kay

That’s the plan.