Building for the web since the rules were still being written.

Before the web

Self-taught from the start. My friends played computer games; I was the nerdy kid writing them. By the time the web arrived, I'd spent fifteen years learning how computers think — and the web gave all of it somewhere to go.

First systems

Custom websites and the CMS that let clients publish for themselves — maintained by hand, lessons learned the hard way. Content management didn't have a name yet, but a client who could update their own pages as easily as typing a letter was a big deal — for some of them, the first time the website really belonged to them.

So was the other thing I kept building: software that lived entirely in the browser. For one customer — an industrial supply company, not unlike the one I'd join years later — I built an inventory and sales management system that ran completely on the web, back when "the cloud" wasn't vocabulary yet. We didn't call it SaaS. We called it the website that ran the business.

Twenty years as the whole software practice

From the late 1990s until 2015, dierker.us was my business — and most of the time, I was the entire technical practice: understanding the problem, designing the system, building the pieces, and making them work together. Architecture, code, hosting, servers, support — the occasional project alongside other developers, but usually just me and the client’s problem.

The vocabulary often lagged behind the work. I built content-management systems, shopping carts, order processing, inventory functions, customer portals, and administrative tools before those labels were familiar to the small and midsized businesses using them. ASP gave way to PHP in 2003; the work — turning business problems into working systems — never changed.

From outside builder to inside operator

In 2015, I went in-house with a national industrial supplier — decades of history, half a million SKUs. I inherited a storefront written in classic ASP, running against a custom Oracle system built to the owner’s specifications in the early 2000s. I’ve often said it’s the kind of system I would have recommended for the company.

The company later migrated onto an off-the-shelf ERP stack — a migration I argued against at the time — and I spent years operating the systems that decision produced. Today I’m leading the migration off it and onto Odoo. Few things sharpen ERP judgment like living with a system from the inside: first as the operator who inherited the decision, now as the architect responsible for its replacement.

Along the way, I built the company’s Amazon Marketplace business from nothing and led it past $30 million a year in marketplace sales.

That included the content the channel ran on: for more than a decade I’ve shot the product photography for everything the company sells — single shots for the industrial site, full photo series for the marketplaces — and produced the product videos myself before later overseeing their production. And when the owner’s other venture — a nationally ranked disc golf destination — needed websites, ticketing, and tee-time systems, I built those too.

A decade-plus of deployment, volume, employees, customers, and the P&L: the half of the education you can’t get from outside.

The next chapter

I know what it is to sit across from a business owner and turn an unclear operational problem into working software. I also know what it is to depend on that software every day from inside the business. The next chapter brings both perspectives together — with modern AI expanding what one experienced person can research, build, test, and automate. I’ve approached every major tool shift in my career the same way: early and critically. AI is the current one. It changes the pace and breadth of the work, but not the need for judgment.