Once a Cat and a Fox were traveling together. As they went along, picking up provisions on the way—a stray mouse here, a fat chicken there—they began an argument to while away the time between bites. And, as usually happens when comrades argue, the talk began to get personal.

“You think you are extremely clever, don’t you?” said the Fox. “Do you pretend to know more than I? Why, I know a whole sackful of tricks!”

“Well,” retorted the Cat, “I admit I know one trick only, but that one, let me tell you, is worth a thousand of yours!”

Just then, close by, they heard a hunter’s horn and the yelping of a pack of hounds. In an instant the Cat was up a tree, hiding among the leaves.

“This is my trick,” he called to the Fox. “Now let me see what yours are worth.”

But the Fox had so many plans for escape he could not decide which one to try first. He dodged here and there with the hounds at his heels. He doubled on his tracks, he ran at top speed, he entered a dozen burrows—but all in vain. The hounds caught him, and soon put an end to the boaster and all his tricks.

Systems can be as complicated as the human mind can devise. And humans are very good at devising.

There is no shortage of moving pieces that can be introduced: queues, caches, distributed async systems, multi-stage transactions, service-oriented architecture, enterprise service buses, microservices, event sourcing. Each has its place. Most of these places are at Google or Facebook. If you’re not them, reaching for these tools often doesn’t solve the problem you have, and reliably introduces problems you didn’t.

The largest trucking companies in this country are mid-market businesses. The same is true of most regional banks, most distributors, most manufacturers. The systems that run these companies don’t need to scale to a billion users. They need to be reliable, maintainable, and small enough that the whole team can hold them in their heads. That’s a different design constraint, and it leads to different answers.

The boring answer is usually the right one. A solid relational database. A handful of application servers. Some glue code where you need to integrate with other systems. A UI built with whatever framework your team can hire for. None of this is exciting. None of it generates conference talks. But it’s what the systems that quietly work are built on.

I’ve seen sophisticated architectures die after years of heavy consultant spend, because the developers could never reliably sync multiple levels of data storage. I’ve seen unfashionable systems trudge along for a decade or more, because they used a bog standard architecture of screens talking to business logic talking to a relational database. The company never had to relearn its own infrastructure.

A system small enough to understand is also a system you can defend when something goes wrong.

When the hounds show up — a sudden traffic spike, a critical bug, a key engineer leaving, an acquisition — the company with one good trick climbs the tree. The company with a sackful of tricks is the Fox.

Which situation do you want to be in?