Good Tools Are Built Backwards

When someone who made ads and gave presentations for a living said he was going to build an AI tool, the reactions were some version of: how would you build that? what for? people already do that work.

I'm not a developer or an AI expert, so I knew next to nothing — but I was sure of one thing. The work I and a lot of other ad people had done for years, building the front end of a pitch strategy, was work AI could take on. It wasn't new technology. It just seemed like it would be worth making.

You don't build the product first

I found out later that the clumsy, trial-and-error way I'd gone about it already had a name.

To my surprise, it was the model Palantir made famous: the Forward Deployed Engineer, or FDE. The idea, as described in an a16z talk, goes roughly like this — start from the premise that there is no finished product, fix on the one result you absolutely have to produce, and build the product backward from there. (Forward-deployed job titles, a16z)

The normal path is to build a product and then take it to market. This one goes into the field first, locks onto the single result that field has to produce, and assembles the tool in reverse so that result comes out.

FDE is a verb, not a noun

Watching that talk, I started to think FDE isn't really a job title for a kind of person — it's a way of working. Closer to a verb than a noun.

I only see that now; when I started last December I knew nothing about FDE or anything else. I just had the conviction that it could be built and should be. My field was the 25+ years I'd spent in advertising, and the one result I had to produce, from a director's chair, was the strategic direction that goes into a new-business pitch. I imagined the finished output first, then started backward from there.

The only way out was through

Working backward turned out to be the grind. On a pitch you climb toward the idea; here I had to climb down from the finished output and rebuild every step that led to it.

The output I needed was vivid in my head; getting an AI to produce it was another dimension entirely. The AI's tics were the least of it — bizarre word choices, holes in the logic, problems everywhere I looked. Around the fourth month I wondered whether I'd picked up something I shouldn't have touched.

The fix was close to brute force. What works, what doesn't; this is like this, that's like that; better to do it this way than that way. From where a comma sits to how a conjunction gets used, I turned it into rules and forced the AI to follow them.

A product that's the residue of pain

There are a couple of phrases people associate with how Palantir works:

> absorb pain, excrete product.

> pain is a moat.

Looking back, I get it. You keep hitting new problems, and the process and method you build to solve each one *become* the content of the tool. In my case that meant: every time a pitch logic fell apart, the patch I wrote to hold it together became a rule the engine now runs on. A tool built without that process just has similar specs on paper.

A tool built backward

What 25+ years in advertising leaves you with isn't a highlight reel of wins. The real asset is the tacit knowledge: what worked, what didn't, what still looks sharp on a second look and what turned out ordinary, what lost but was good, what won but was junk — all of it stacked up in your head. The hard part was turning that into a productive heuristic, and about a hundred source materials plus the dozen or so books behind the original idea helped a lot.

I'm no FDE, and I don't need to be. But looking back, it's interesting that Synapsis got built that way: from the result, backward.

Read more

Frequently asked questions

What does "built backwards" mean for a software tool?

It means starting from the one result the tool must produce and assembling it in reverse, instead of building a general product first and looking for uses. It's the logic behind Palantir's forward-deployed model: go into the real work, fix on the result that matters, and build toward it.

Can someone who isn't an engineer build an AI tool?

It's not about writing the model — anyone can build on an existing one. It's about knowing, in a specific field, what a good result looks like and what a bad one does, in enough detail to turn that judgment into rules the AI has to follow. The domain knowledge is the hard part, not the code.

What makes Synapsis different from a general AI tool?

It was built backward from one result: the strategic direction that goes into a pitch. The tacit knowledge of 25+ years in advertising — what works and what doesn't — is structured into rules the engine follows, which is what a general-purpose model, built for everything, doesn't have.