Ship the Feature Without the AI First

Last year a client asked me to build an AI-powered support ticket categorisation system. They wanted incoming tickets automatically sorted into categories, assigned priority levels, and routed to the right team. They had a model in mind. They'd seen demos. They wanted the AI version yesterday.

I told them we should build a dropdown first.

They looked at me like I'd suggested we communicate by carrier pigeon. This was supposed to be an AI project. They were paying for AI. And my proposal was a dropdown menu.

I built the dropdown. A simple select field — agents would manually categorise each ticket as it came in. Category, priority, team. Three dropdowns. No intelligence whatsoever.

They used it for two months. In that time, 247 support agents categorised roughly 4,000 tickets. And those 4,000 labelled tickets became the foundation of everything that came after.

When we finally trained the classifier, it was 94% accurate on day one. Not after weeks of prompt engineering. Not after expensive fine-tuning. Day one. Because we had 4,000 real-world examples of exactly how their team thought about categorisation, with all the messy edge cases and overlapping categories and subjective priority judgments baked in.

The dropdown taught me more about their problem than any requirements document ever could have.

The three things you get for free

When you build the non-AI version first, you get three things that are extraordinarily expensive to acquire any other way.

A fallback system. The day your AI model goes down — and it will go down, during a usage spike, on a holiday, at the worst possible moment — you have a working system to fall back to. Not a "sorry, try again later" screen. An actual functioning feature that humans can operate manually. I cannot overstate how valuable this is. I've watched AI features with no fallback take down entire workflows when the API had an outage. Users weren't just unable to use the AI — they were unable to do their jobs at all because nobody had built the non-AI path.

Labelled training data. Every interaction with the manual version generates labelled data. Every time a human makes a decision, they're creating a training example. And it's better training data than anything you could create synthetically, because it reflects how real users with real context actually think about the problem. The 4,000 labelled tickets from that dropdown weren't just numerous — they were high-quality. They captured the nuances that no requirements doc would have mentioned, like the fact that "billing" tickets about enterprise accounts should go to a different team than "billing" tickets about individual plans.

Realistic user expectations. This is the one nobody talks about. When users have lived with the manual version, they have concrete expectations about what the automated version should do. They're not imagining some magical AI that reads their mind. They're thinking "I want it to do what I do, but faster." That's a dramatically more tractable problem than "build something that handles support tickets." You've turned an open-ended AI challenge into a specific automation task with clear success criteria.

I've done this exact thing before, without AI

Here's what kills me about the AI discourse: this pattern is ancient. Product designers have known about it forever, just under different names.

In the early 2000s I built a recommendation engine for an e-commerce site. But before the engine, we built a "staff picks" section. Humans curated the recommendations manually for six months. We learned which products people actually clicked on, which combinations made sense, which recommendations felt creepy and which felt helpful. When we finally automated it, we had six months of data on what "good" looked like.

In 2012 I built a lead scoring system for a marketing platform. Before the algorithm, we had sales reps manually scoring leads on a 1-10 scale for a quarter. Their scores were inconsistent and sometimes baffling — a rep would score a Fortune 500 company as a 3 and a two-person startup as an 8. But in those inconsistencies was signal. The reps knew things about lead quality that weren't in the CRM data. The manual scoring exposed those hidden variables so we could find data proxies for them.

The pattern is always the same. Humans first. Watch what they do. Encode what you learn. Automate the pattern.

AI didn't invent this. AI just made people forget it.

The real architecture

Here's how I structure every AI feature now, and I'm not being precious about this — it's genuinely how I build.

Each phase has clear exit criteria based on real metrics. Not "the model seems good" — specific numbers. Approval rate above 92%. Confidence calibration within 5%. No category with accuracy below 85%.

The temptation to skip ahead

I understand the pressure to go straight to AI. The client is excited. The stakeholders have seen ChatGPT and they want their own version. The timeline doesn't seem to accommodate a months-long manual phase.

But I've shipped products for twenty-five years and the story is always the same. The team that skips the research phase and goes straight to building ends up rebuilding. The designer who doesn't talk to users ends up redesigning. The marketer who doesn't test the offer ends up relaunching.

Skipping the manual phase of an AI feature is the same mistake wearing new clothes. You're not saving time. You're borrowing it, with interest.

The team that shipped the dropdown and waited two months launched their AI categorisation system in one week once they started. One week. Because they knew exactly what to build. They had the data to train it. They had a fallback for when it failed. They had metrics to evaluate it against. All the hard questions were already answered.

Compare that to the teams I've seen that jumped straight to AI: months of prompt engineering against synthetic data, model outputs that don't match how the business actually works, no fallback when things go wrong, and a vague sense that it's "not quite right" with no concrete data to explain why.

AI is an optimisation layer

This is the mental model I keep coming back to: AI is an optimisation layer, not a foundation. You don't build a house starting with the solar panels. You build the house, make sure it works, make sure people can live in it, and then you add the solar panels to make it more efficient.

The non-AI version of your feature is the house. It's where the value lives. The AI makes it faster, cheaper, more scalable — but the core value proposition has to work without it.

If your feature only works when the AI works, you don't have a product. You have a demo.

Build the dropdown first. You'll be amazed what it teaches you.