Workflow First, Model Second

I want to write about an ordering mistake that happens so often inside small businesses that I now look for it in the first five minutes of any AI conversation. The mistake is starting with the model — which one, which provider, what features, which pricing — instead of starting with the workflow.

It is the equivalent of buying a power drill before deciding whether you needed a shelf, a wardrobe, or a hole through the wall. You can do it. The drill is impressive. You may even drill some holes. But you have made the most important decisions of the project in the wrong order, and you will pay for it.

Workflow first. Model second. Always.

The reversed sequence — model first — happens because the model is the visible part of the work. It is the thing the founder has read about. It is the thing the vendor wants to talk about. It has a logo, a price, and a marketing campaign behind it. The workflow, by contrast, is invisible. It lives inside the team. Nobody is selling it to you. There is no demo of it on YouTube.

So the conversation starts with: should we use GPT or Claude, should we be on the Enterprise tier, should we get a separate vector database. Three months later, the team has a tool stack and a budget and a vendor relationship, and they have still not answered the only question that matters: what is the workflow this is meant to support, and what does success look like for that workflow?

The work is then back-fitted to the tools. Which is the worst way to do anything, in technology or otherwise.

Workflow first means you spend the early hours of an AI project on questions that have nothing to do with AI.

What is the actual sequence of steps a person takes today? Who does each step? How long does it take? What's the input? What's the output? What constitutes a good version of the output? What are the edge cases? What does a bad version look like? Where does it go after the workflow ends? Who relies on it?

These are deeply unsexy questions. They produce flowcharts and spreadsheets, not demos. The team that asks them feels, for the first week, like they have made no progress. Then, in the second week, the actual project comes into focus, and the model decision — which felt momentous a fortnight ago — becomes obvious. It is almost always: use whatever the team is already using, at the cheapest tier that does the job, and stop optimising. Because the model is no longer the bottleneck. The workflow is.

Workflow-first projects ship things. Model-first projects produce capability that is never used.

When the workflow is clear, the build is fast — usually a fraction of what the team estimated, because most of the work was understanding the workflow, not configuring the model. When the workflow is unclear, the build drags on indefinitely. The team blames the model. They switch providers. They add tools. None of it helps, because the problem was never on the tool side.

I have watched teams spend a quarter and tens of thousands of pounds optimising a model for a workflow that, when finally written down, turned out to be three steps that did not need a model at all. They needed a form, a database query, and a notification. The team had got so far into the tool decisions that they had stopped asking whether the tool was the right answer.

Once a team has run two or three workflow-first projects, the ordering becomes instinct. Someone says we should use AI for X and the first response is no longer let's evaluate vendors. It's show me the workflow. The conversation shifts. Vendor evaluation becomes a two-hour decision rather than a two-month project.

This is one of those rare ordering rules that costs nothing to apply and saves enormously. There is no software to buy. No course to take. Just a discipline to enforce, every time, until the team would feel weird doing it any other way.

Workflow first. Model second. And the savings — in time, in money, in clarity — will surprise you.