Why I write the AI tools the buying floor uses every morning.
The first tool was an Excel macro. It saved me about three hours a week.
I was a category buyer at the time, four years in, doing the work most category buyers were doing. Reconciling vendor delivery schedules with planned launches. Cross-checking colour mix against last season's sell-through. Writing an open-to-buy that had to round-trip with planning twice before anyone agreed on a number. Pulling reports out of a system that took ninety seconds to load each query.
The macro did one of those things, the vendor reconciliation, without me. It read the schedule, matched it against the launch calendar, surfaced the mismatches, and put them in an email to me on Monday morning. I wrote it on a Saturday because the Monday meeting had become a place I dreaded, and because writing the macro felt better than spending one more Saturday staring at four spreadsheets.
The macro worked. Then I wrote a second one. Then I wrote one for the assistant buyer two desks down. Then their manager asked if I could write one for them too. Then somebody in planning asked if the colour-mix one could read from the planning database directly, and that was the moment I had to learn what a database actually was.
That was twelve years ago. The current count is twelve AI tools in production. Six of them run inside the company. Six of them are mine, public-facing or quietly running on my own servers. The macros are long gone; the muscle is the same.
This essay is for the buyers and merchandisers who are wondering whether they should start. The short answer is yes. The long answer is the rest of this letter.
Why a buyer should write the tools
The standard career advice for a buyer who is also good with computers is: pick a side. Either go deeper into merchandising and rely on the data team, or move to the analytics side and stop being a buyer. The implication is that the two disciplines are too distinct to hold in one head.
This is wrong, in a way that has cost the retail industry a generation of operators who should have been writing systems and instead spent their careers describing requirements to people who didn't understand the floor.
A category buyer's job is to be the person who knows what the customer is about to want, and to translate that into a buying calendar that ships the answer on time. A category buyer's main constraint is not knowledge of the customer. The constraint is the bandwidth to act on that knowledge while reconciling vendor schedules, planning open-to-buy, watching sell-through, reviewing fits, attending line meetings, and writing emails to nineteen people who all have an opinion on the silhouette.
A tool is the thing that removes one of those bandwidth taxes. A tool you write yourself is the thing that removes the tax in exactly the shape your category needs. A tool somebody else writes for you arrives six months late, costs a quarter of the team's annual planning, and solves seventy percent of your problem because the person who wrote it doesn't know the seventy-first percent.
I started writing the tools because waiting was more expensive than learning.
The "buyer who codes" spine
Inside the company, this is a small joke. I am the buyer who codes. The CEO uses the phrase. The team uses the phrase. It is a useful phrase because it shortcuts a longer conversation about what kind of operator I am.
I am not a buyer who picked up a coding hobby. I am not a buyer who hired a developer. I am not a buyer who learned to read SQL well enough to argue with the data team. I am a buyer who writes the spec, writes the tool, ships the tool, watches it fail, fixes it, watches it succeed, and then writes the next one. The development happens in a notebook on a Saturday. The QA happens on the buying floor on Monday.
The shape of "buyer who codes" matters because it isn't two jobs. It is one job, done with a wider toolkit than the role usually carries.
There is a useful comparison here. A surgeon who also reads radiology scans isn't doing two jobs. They have a wider toolkit for the same job. A teacher who also writes curriculum isn't doing two jobs. They have a deeper grip on their own craft. The buyer who writes the tools is the same kind of operator: someone who refuses the artificial line between figure out what to do and figure out how to do it.
The first tool was an Excel macro. The next tool I write will probably be an embedding-space search over a wholesale catalogue I have not yet been given. The instinct is the same. This work shouldn't be this slow. Let me see if I can fix it.
What the tools actually do
I will not name the tools or their internal codenames here. They live inside a company that pays me to be careful with what is internal-only. The shape of what they do is fine to describe because it is the shape any retailer would build, and any operator who has been in the room has seen the work.
There are six of them inside the company. They are, in roughly the order I wrote them:
A vendor decision engine that scores incoming vendor proposals against price band, fabric story, delivery confidence, and a private quality history. It surfaces the call. The buyer still makes the call. The tool just compresses what used to be a four-day review into thirty minutes.
A store-DNA reader that clusters stores by what their customers actually buy, not by metro versus non-metro. The clusters look unlike the official segmentation in two-thirds of cases, and the trial-drop machinery now reads from this clustering instead of the metro labels. Sell-through on the hero panels improved across the categories that adopted it. I do not have permission to share the number.
A lead-time forecaster that looks at a vendor's last forty deliveries, weighs the variance, weighs the dye-route and the fabric base, and gives a forecast that has been more honest than the vendor's own commitment for three years running.
A markdown predictor that watches sell-through curves and surfaces the moment a SKU is going to need a price cut before the buyer notices the curve has bent. The tool isn't allowed to take the call. The buyer still takes the call. The tool just shortens the time between "the curve has bent" and "we have decided what to do about it."
A catalogue mapper that reads the entire vendor universe by fabric, silhouette, and price band, and tells me which vendors are over-represented in my open-to-buy and which categories are starving for breadth. The map is updated every quarter.
A trend-signal aggregator that ingests public trend signals (search volume, social mentions, runway commentary) and produces a short list of silhouettes to watch. The list is not a buying recommendation. It is a thing to argue with at line review.
Six tools. None of them replace the buyer. All of them remove one of the bandwidth taxes that was costing the buyer the energy to do the part of the job a tool can't do. Which is: make the call.
The six on the other side
The other six tools are mine, written outside work hours, on weekends, on the train, on holidays I haven't entirely taken. Most of them I built because I wanted to learn something new. A couple of them got useful enough to be small public products. They are not employer IP. They are what I do when I am sitting in front of a problem that the company doesn't pay me to solve.
One of them is the polymath wiki you may have come from. Three hundred pages on whatever pulls my attention, written by me and an AI curator I built to keep the wiki growing on the days I am not at my desk. The wiki is the closest of the personal tools to the work tools, because the same instinct is at the bottom of both. There is a thing I want to know. The current way of finding out is slow. Let me see if I can fix it.
Another is an astrology engine that produces nothing of professional consequence and is also the second-most-used personal project I have ever written. People want to understand their lives. The data exists. Reading it carefully is a craft. The engine compresses the reading; the human still has to live the life. The pattern matches the buying tools more closely than anyone would expect: data and taste, system and choice, machine and human.
Listing the rest is unnecessary. They live in their own repositories. The reason I list them at all is to say: writing the tools is not a moonlighting habit and it is not a portfolio play. It is what I do when I sit in front of a slow problem.
What this practice teaches
Twelve years of this gives you a small number of habits that are hard to teach in a classroom.
One. You learn that most workflow questions are tooling questions in disguise. A team that complains about an opaque process usually has a missing dashboard. A team that complains about decision lag usually has a missing pipeline. The complaint is the symptom. The tool is the answer.
Two. You learn that the right tool is built to make the human's call faster, not to replace the human's call. The tools I trust are the ones that bring a buyer to the decision point in thirty seconds instead of three days. The tools I don't trust are the ones that try to make the decision themselves. Those tools fail in the same way every time: they are right on average and wrong in the exact moments that matter.
Three. You learn that the spec is the hard part. Anyone can build a button. The hard part is knowing which button the floor will press at 9:30 on a Monday. Spec-writing is a buyer's craft, not an engineer's craft. The buyer who can write the spec has cut out the most expensive person in the build: the one who translates the floor to the engineer.
Four. You learn that adoption is a slow lift. A tool that nobody on the floor uses is a failed tool, regardless of how clean the code is. You learn to ship the smallest useful version, watch it get used or not, and iterate from there. The tools that survive on the floor are the ones that earned their place. The tools that did not survive are the ones I am most embarrassed by, and they were teaching too.
Five. You learn that the floor will tell you what is wrong with the tool faster than any usability test. A buyer who hates the tool will work around it within a week. A buyer who likes it will write a Slack message at 7 AM the morning a bug bites them. Both are signal. Listen to both.
Six. You learn that the company that gives a buyer permission to write the tools is rare, and you learn to be grateful for it. Most retailers think the floor and the systems team are different rooms with different vocabularies. The ones that are good at this think they are the same room.
A note on what the work is becoming
The retailers who are working out how AI fits inside a buying organisation are starting to realise that the buyer with computational fluency is more useful than either a buyer or a computational specialist alone. The labels haven't quite settled. Some retailers are inventing new titles. Some are bolting the work into existing seats. Some haven't named it yet.
The shape doesn't depend on the title. The shape is: one operator who can hold the customer in one hand and the system in the other. That operator is more useful than two specialists because the two specialists have to meet in a room to do the work the one operator does at their desk in fifteen minutes.
The people doing this today are doing it because they couldn't help themselves. I started because waiting was more expensive than learning. The buyers I respect most are the ones who did the same. The job description will catch up at its own pace.
Closing
Whenever someone asks me how to start, I say the same thing. Find one workflow in your category that is slow, and that the data team has not gotten to. Write the simplest possible tool that removes one of its taxes. Ship it to one person on the floor. Iterate.
That is the whole craft. It compounds in a way that nothing else in the buying job compounds. After a year you have one tool you can rely on. After three years you have a small toolkit and a reputation. After ten years you have written the work the floor runs on, and you can also pick the colour.
I am still doing both. Always up for a conversation about that, or about a workflow that has been bothering you, or about anything else on the floor.