The movie Coyote vs. Acme flips an old joke around: what if Wile E. Coyote, who we've spent decades dismissing as hopelessly incompetent, was actually an ambitious engineer working with terrible tools? The story behind the name Coyotiv begins, more or less, with that question.

Looking back over Wile E. Coyote's long career, engineering is probably not the first thing that comes to mind. Bad decisions, high explosives, and a vast desert apparently beyond the reach of workplace-safety regulations are more obvious.

And yet, what he has been doing all these years looks remarkably like engineering.

He has one persistent problem: the Road Runner is much faster than he is. Rather than accept this as an immutable fact of life, Coyote tries to solve it. He designs rockets, rigs pulleys, deploys magnets, paints roads, and builds elaborate mechanical systems. A fair number of these experiments end "slightly" differently from what the manufacturer had in mind. The next day, though, Coyote is back at work.

New plan, new machine, new box from Acme.

That is essentially the idea at the heart of Coyote vs. Acme. After years of ordering products that explode, malfunction, or somehow end up falling on his own head, Coyote finally takes Acme to court.

It's a wonderful premise because it reverses an assumption most of us have carried since childhood: what if Coyote isn't actually that incompetent? Or, at the very least, what if incompetence isn't the whole story?

Look a little closer and you have to admit that his working conditions are not exactly ideal. His competitor is faster. His equipment is unreliable. His entire supply chain depends on a single company. The environment is hostile. Even gravity appears to have developed a personal grievance against him.

Still, every time, Coyote approaches the problem from another angle.

Maybe what makes him interesting is not that he never gives up. From an engineer's point of view, something else stands out: he does not confuse a failed solution with an impossible problem.

If the rocket explodes, that does not mean the Road Runner cannot be caught.

It means the rocket exploded.

That distinction was part of what drew us to Coyote when we chose the name Coyotiv.

What would you order from Acme?

There are parts of Coyote's engineering practice that are hard to defend. His supplier choices, for one.

You buy a rocket from a company. The rocket blows you up. The next week, you order a giant magnet from the same company. It sticks you to a mountain instead of your intended target. So you open the catalog again and see what else they sell.

In software today, we would call that a serious vendor lock-in problem.

Our catalog has fewer rockets. Instead, we have frameworks, cloud services, open-source libraries, APIs, AI models, coding agents, and new platforms appearing every week. Almost all of them promise to make something faster, easier, or smarter.

We've never had this many tools at our fingertips. Strangely enough, software still has plenty of problems.

Just because a tool exists doesn't mean you should use it. New doesn't mean right. Popular doesn't mean useful for your problem. And by now, putting "AI" on the box should not count as evidence of much at all.

At Coyotiv, we try to work the other way around. First, understand what we are actually trying to solve. Then identify the real constraints. Then look at the options. Tool selection comes later.

AI has made that distinction even more important. Things that were impossible a short while ago are becoming possible at extraordinary speed. But the job of engineering is not to do everything that can be done. Deciding which possibilities are worth pursuing is part of the job too.

Coyote, we should admit, is more extreme on this point: If there is a rocket, the rocket must be used.

Why coyotes don't go it alone

Wile E. Coyote is only half the story behind our name. Real coyotes are part of the story too. They can move alone when they need to, but in difficult conditions they form small packs, look out for one another, and work together. When we started Coyotiv School, that reminded us of something we already knew about how engineering is learned.

From the outside, software development can look like a very lonely job: one person, one screen, and one thing that has refused to work for the last few hours.

In reality, a good engineer carries a whole pack of other engineers in their head. You learn debugging from one person, system design from another. Someone else made a mistake years ago, so you don't have to. Another person asks one question and suddenly a problem you've been staring at for days looks completely different.

Coyotiv School was built around that idea: not just teaching tools, but creating a place where engineering experience could pass from one person to another.

Then the idea grew beyond the school.

Today we build our own technologies and products, develop software and AI products with companies, and work alongside engineering teams. What we do has changed, but the original instinct is still the same: we rarely assume that the solution in front of us is the only possible one.

Before asking, "Which one should we use?" we sometimes prefer to ask, "Why do we need this at all?"

The world is not a finished design

Wile E. Coyote is usually remembered for his persistence. But persistence by itself is not that interesting. Doing the same thing a hundred times and getting the same result is not much of an achievement.

Coyote's real skill is something else. He redesigns the system every time.

If the Road Runner is faster, Coyote looks for a way to become faster. If the distance is too great, he turns distance into a mechanical problem. If there is an obstacle in the way, he may deal with it using a machine that is far more complicated than necessary, but he does not simply accept that the obstacle has to stay there.

Coyote does not regard the world as a finished design.

The fact that something works a certain way today does not mean it has to work that way tomorrow. When he hits a limit, his first instinct is not to accept it. It is to test whether it is really a limit. A lot of good engineering questions begin with exactly that kind of restlessness.

Why do we do it this way? Is this genuinely a technical constraint, or simply a decision nobody has revisited in years? Why is a person still doing this task? Why are we asking a machine to do that one? Does all this complexity belong to the problem itself, or did we introduce it with the solution?

Of course, not every old assumption is wrong. Sometimes people do something the same way for a very good reason. Sometimes the wall really is a wall.

But every so often, you find out that the mountain everyone has been walking around for years can actually be moved.

That is where things get fun.

Back to the drawing board

There is a simple reason Wile E. Coyote never catches the Road Runner: if he did, the cartoon would be over.

In the real world, we need things to work. We need systems to stay up, products to earn their place, and the engineering teams we work with to eventually do great work without us.

But there is one reflex we've borrowed from Coyote. When something does not work, we do not immediately call it impossible.

Sometimes the code is wrong. Sometimes the architecture is wrong. Sometimes it is the tool. And sometimes you have been asking the wrong question from the start.

Years later, the two ideas behind the Coyotiv name still fit together: Wile E. Coyote, alone in the desert, endlessly willing to take a problem apart, and real coyotes, forming small packs when things get difficult.

One reminds us to question the limits. The other reminds us that nobody has to do it alone.

The tech world already has enough people saying, "That's just how it's done."

We still like asking, every now and then, "Are we sure?"

Wile E. Coyote would probably ask that question and then open the Acme catalog.

Luckily, our methods are a little less explosive.