I like maintaining things.

Oiling, sharpening, cleaning, replacing parts, sewing repairs. Trying to keep something as close to mint condition as possible, or helping it wear in and develop its own patina and character.

I’m not especially good at it.

As a kid I regularly took things apart and failed to get them back together. While I’m better at getting them back together, that’s still never a given.

Nor am I skilled, as a generalist, with wood stain or soldering or a needle and thread. Actual craftspeople are, but I don’t confuse myself with them.

I recently replaced a leather boot’s pull tab—or whatever you call the loop on the back you use to slip the shoe over your heel—and while I was successful, there was cursing and blood and the result is nothing that should be viewed up close.

But I can pull the boot onto my foot with the smug satisfaction of near-craftsmanship.

There’s a thrifty value in maintaining things, and a tiny environmental win, but that’s not why I like it.

I like being part of the story. Someone else cared to design and create something, and I participate in that act by using the result of their work, appreciating it, and caring for it myself. The object is a formal expression of human ingenuity and craft. By caring for it, I add to whatever story it has. The more care something has received, the more I want to continue caring for it.

A web project is not a boot, but it can be cared for too.

It’s built with a dizzying number of complex ingredients created by an also-dizzying number of people, so it seems rather unthinkable to not care for it indefinitely.

This seems like an obvious thing to say, but my experience with client-centric web work has been that a minority of agencies plan for the maintenance of whatever they deliver.

That doesn’t necessarily mean taking an active role in monitoring, software updates, and server upgrades. It might mean identifying internal engineering or IT people that can take over and making sure they’re comfortable with the setup. (Getting them involved from the beginning is the most humane way to ensure that!)

I learned this by delivering projects that were designed and shipped, only to feel awful for clients whose sites fell into disrepair because of stagnant software or “user error.”

You can usually get away with “LOL CLIENTS AMIRITE?” and scoff at how they used it wrong, but did you build it well enough that it’s hard to use wrong? Who was the more technical person more likely to anticipate and solve for problems? Who was specifically paid to do that?

I’d spend nights and weekends updating my own client projects without charging for it, hoping that some later work would roughly justify the cost. That sort of worked out until I had enough projects that I was forced to discuss maintenance from every project outset and offer packages for it that reflected its actual value and perpetual importance. It was not an easy thing to do, or to make a case for when I’d secretly been maintaining things for free because it felt wrong not to.

While I suspect there are kinds of work this may not apply to, it seems generally irresponsible to deliver a system for people and not plan for a future where it can thrive.

It doesn’t matter how brilliant the work is if it’s going to fall apart without your constant involvement.

Maintenance can be a dull enough subject that few clients want to think about it, let alone pay for it. The fun part is building things, growing things, rebuilding things! Designing with a clean slate. Not replacing npm dependencies or adapting a system to gracefully accommodate new needs.

It doesn’t help that it’s so easy, in seemingly any product category, to find an inexpensive new replacement and toss out the old thing.

There’s nothing to maintain if you don’t own it. Sometimes it’s tough to know if that’s a bug or a feature.