Building Things That Last

I started building websites in 2007. I was in middle school, hunched over a Core 2 Duo PC, tweaking Friendster layouts with Notepad++ and Photoshop slices. Back then we called ourselves “Web Masters.” It felt like a superpower.

I didn’t stop. Through high school, college, and into my career, I kept building things. Websites, apps, internal tools, dashboards. Some of them are still running today. Some of them I’d be embarrassed to look at now.

The thing nobody tells you early on

When you’re starting out, you optimize for getting it to work. That’s the right instinct - shipping something is better than perfecting nothing. But there’s a trap that comes after: you start optimizing for looking smart.

I fell into it. I’d reach for the more complex solution because it felt more “professional.” Microservices when a monolith would do. Custom abstractions when the standard library was fine. Architecture diagrams for a project with three users.

The wake-up call came in 2016. I was running a startup, and we hit a sales peak that exposed every shortcut we’d taken. The system didn’t crash dramatically - it just got slow, unreliable, and expensive to fix. Revenue was there, but the software was fighting us instead of helping us.

That’s when I started thinking differently about what “good” code actually means.

What I care about now

The question I ask before building anything is: what happens when this breaks at the worst possible time?

Not if it breaks. When.

A system that goes down during a sales peak isn’t a technical problem - it’s a business problem. The code is supposed to be the most dependable part of the operation, not the thing everyone’s holding their breath about.

This doesn’t mean over-engineering for reliability. It means being honest about what the system actually needs. Sometimes that’s a simple WordPress site with some custom logic. Sometimes it’s a proper backend with queues and retries. The skill is knowing which one fits.

I’ve also learned to be suspicious of complexity that doesn’t pay for itself. Every abstraction is a bet that the flexibility will be worth the overhead. Most of the time, it isn’t.

The tools don’t matter as much as you think

I’ve worked with Node.js, Laravel, React, Astro, plain PHP, and a lot of things in between. They’re all fine. The projects that went well weren’t because of the stack - they went well because the requirements were clear, the scope was controlled, and someone was paying attention to what actually mattered.

The projects that went badly usually had the opposite problem. Interesting technology, unclear goals.

Seventeen years in

I’m still building things. The problems are more interesting now - legacy systems that need to keep running while being modernized, workflows that live in Excel spreadsheets that need to become actual software, small teams that need tools that won’t fall apart when they’re not looking.

The work is less glamorous than it sounds. A lot of it is reading old code, understanding why decisions were made, and figuring out how to improve things without breaking what’s already working.

But that’s the job. And I still find it interesting.