Every Project Starts With a Feeling

Before a project has a budget, a brief, or a single line of code, it has a feeling. Someone reads about a competitor using AI and feels behind. A founder watches their team drown in repetitive work and feels frustrated. A board member feels the pressure to "have an AI story" by the next quarter. If you are wondering how to start an AI project, the honest answer is that you start exactly here — by naming the feeling underneath it — because that feeling is the most reliable map you have to the problem actually worth solving. Get it named, and the technology choices become almost easy. Skip it, and you can build something impressive that no one needed.

Every project I have ever worked on started as an emotion long before it became a requirement. The good ones simply got honest about that emotion early.

This is the part of consulting nobody puts on a slide. We talk about architectures, models and ROI, and all of that matters. But the first real conversation is rarely technical. It is someone telling you, often a little apologetically, how they actually feel about where their business is — and that feeling, taken seriously, is where a good AI project is born.

How to start an AI project: name the feeling before the technology

When people ask how to start an AI project, they usually expect a checklist: pick a use case, gather data, choose a model, ship. That sequence is fine on paper and misleading in practice, because it skips the only step that reliably prevents waste. The first move is to articulate, in plain language, what is bothering you. Not "we want to use AI" — that is a solution wearing the costume of a problem. The real starting point sounds like "I am terrified we are falling behind," or "I am exhausted by how much manual rework my team does," or "I am excited that we finally have the data to do something clever, and I do not know where to point it."

Each of those sentences points at a different project. The fear points at strategy and positioning. The exhaustion points at automation of a specific, measurable workflow. The excitement points at exploration and a proof of concept. Same person, same company, three completely different first steps. The feeling is not noise to get past on the way to the "real" requirements — it is the requirement, just not yet translated. Our whole job in the first hour is that translation, and we treat it as the foundation of any AI implementation, not a warm-up.

The four feelings that bring people to AI

After enough of these conversations, the same handful of feelings show up again and again. Recognising which one is driving you is genuinely useful, because each one has a characteristic trap.

Uncertainty — "Are we falling behind?"

This is the most common and the most dangerous, because it pushes people to buy activity rather than outcomes. Fear of being behind makes a flashy demo feel like progress, even when it solves nothing. The antidote is not a bigger model; it is clarity about where you actually stand. A sober AI readiness assessment turns a vague dread into a concrete picture: what your data can support, which workflows are ripe, and what would genuinely move a number. Uncertainty handled well becomes direction. Handled badly it becomes a drawer full of pilots that went nowhere.

Frustration — "We waste so much time on this"

Frustration is the best feeling to start from, frankly, because it comes pre-attached to a specific, painful, measurable problem. The person already knows exactly which task they hate. That is gold. It means the use case is real, the value is countable, and success will be obvious. The trap here is under-ambition — automating the annoying task badly, or only halfway, so the team ends up babysitting the tool. Frustration deserves a properly scoped fix, not a sticking plaster.

Ambition — "We could do something genuinely new"

Ambition is exhilarating and needs the firmest hand. The danger is building the cathedral before the chapel — a sprawling platform to do everything, which takes a year and ships nothing. Ambition is best served by a tightly scoped proof of concept that proves the riskiest assumption first. Prove the hard part works on real data, then expand. Ambition with a narrow first target is unstoppable; ambition with no edges is a budget bonfire.

Hope — "Maybe this finally fixes it"

Hope is tender and worth protecting. It usually shows up after a previous tool or vendor disappointed someone. The job here is honesty: to say clearly what AI can and cannot do for their situation, even when a more reassuring answer would close the deal faster. Hope repaid with realism becomes trust. Hope met with hype becomes the next disappointment, and we would rather lose the project than be that.

Why the feeling matters more than the technology

It is tempting to think the technology is the hard part. It rarely is. The models, the pipelines, the deployment — these are difficult but well-understood problems with known solutions. The genuinely hard part is pointing all that capability at the right target, and the right target is hidden inside the feeling. A team that builds a technically flawless system for the wrong problem has failed more completely than one that builds a rough system for the right one, because the second can be improved and the first has to be thrown away.

This is also why the same technology produces wildly different results in different companies. The difference is almost never the model. It is whether someone took the founding feeling seriously enough to translate it into a problem worth solving. We are deliberately vendor-neutral about the tools precisely because the tool is the least decisive variable — choosing between providers matters far less than choosing the right problem, and we would rather spend the first conversations on the latter.

Turning a feeling into a first concrete step

None of this is an argument for endless soul-searching. The feeling is the start, not the destination. The point of naming it is to convert it quickly into something you can act on and measure. In practice that means a deliberately small first move, sized to the feeling:

• An audit (from around €2,500) when the dominant feeling is uncertainty — to map where you stand and which use case is worth the first euro.
• A proof of concept (from around €20,000) when the feeling is ambition or frustration with a clear target — to prove the risky part works on your real data before you commit further.
• A production build (from around €50,000) once a proof of concept has earned it — to scale the thing that already works.

The sequence matters more than the numbers. You should usually have a working prototype to react to by the second conversation, not a forty-page strategy document to approve. Something real you can touch tells you more about whether a project deserves to continue than any amount of planning. If you want to see how we scope that first step, we wrote it up in how to scope an AI proof of concept, and you can see the shape of finished work on our case studies.

What good looks like in the first two weeks

A healthy AI project feels different from a stalled one almost immediately, and the early signs are easy to read. In the first fortnight you should be looking at a real artefact — a prototype, a narrow working flow, a model running on a slice of your actual data — rather than a roadmap. The conversations should be getting more concrete, not more abstract. You should hear what will not work as clearly as what will. And the cost of finding out you are on the wrong track should be small, because the first step was deliberately small.

If instead the project is producing decks, committees and ever-grander ambitions while nothing tangible appears, the founding feeling has been buried under process. That is the moment to stop and re-name it. Choosing a partner who insists on early, tangible proof is half the battle; we set out what to look for in how to choose an AI consultant.

The mistakes that come from skipping the feeling

When teams jump straight to technology, the failures are predictable. They buy a platform because a competitor did, then struggle to find anything to run on it. They automate a process that should have been deleted rather than automated. They build a chatbot because chatbots are visible, when the real pain was in a back-office workflow nobody outside the team could see. Every one of these traces back to the same root: nobody asked what was actually bothering them, so the project optimised for looking like AI rather than fixing the problem.

There is a quieter failure too — solving a real problem so timidly that the result is not worth the change-management cost. That usually comes from frustration handled without ambition: the team fixes ten percent of the pain, the tool sits unloved, and AI gets blamed for a scoping decision. Naming the feeling honestly, and sizing the response to it, is what prevents both the over-build and the under-build.

Risk and trust are part of the feeling too

For most decision-makers, the hope and ambition come bundled with a real, rational worry: what happens if this goes wrong, leaks data, or quietly makes biased decisions at scale. That worry deserves a straight answer, not reassurance. Treating it seriously from the first conversation is what separates a partner from a vendor. Established frameworks help here — the NIST AI Risk Management Framework gives a practical structure for governing AI risk through its govern, map, measure and manage functions, and for anyone operating in Europe the obligations under the EU AI Act are phasing in through 2026 and beyond, with most rules applying from August 2026. (This is general information, not legal advice — check your specific obligations with a qualified adviser.) Naming the worry early, and building governance in from the start, turns a source of anxiety into a source of confidence.

The same feeling, three different companies

Abstract advice is easy to nod along to and hard to use, so here is what this looks like in the wild. Three companies we recognise from real engagements, each driven by one of the feelings above, each landing on a completely different first project.

A clinic running on frustration

A healthcare practice was losing whole afternoons to admin: appointment reminders, intake forms, chasing no-shows, retyping notes. The feeling was pure frustration — they could name the hated task to the minute. The right first step was not a grand "AI for healthcare" platform but a narrow, measurable automation of the worst workflow, with privacy designed in from the first line because patient data leaves no room for improvisation. Frustration with a specific target is the fastest feeling to turn into value, which is why our work in AI for healthcare almost always starts with one painful, countable process rather than a vision.

A manufacturer running on ambition

A factory team had years of sensor and production data and a real spark of ambition: they suspected they could predict failures and tune scheduling before problems hit the line. The danger was obvious — trying to build a full digital twin of the plant in one go. The honest first step was a tightly scoped proof of concept on a single line and a single failure mode, proving the prediction held on their own data before anyone signed off on scaling it across the floor. Our manufacturing work tends to follow exactly that shape: prove the riskiest assumption small, then widen.

A firm running on uncertainty

A professional-services firm felt the dread of falling behind. Competitors were "doing AI," the partners were not sure what that even meant for them, and the temptation was to buy something visible just to have an answer. The right first move was the least glamorous one: an honest assessment of where their data and processes actually stood, so the first euro went towards a use case that would move a real number rather than a demo to wave at clients. Uncertainty answered with clarity becomes a roadmap; answered with a panic purchase it becomes regret.

The questions that surface the real problem

If you want to find your own founding feeling before you ever speak to anyone, a handful of plain questions does most of the work. We ask versions of these in the first conversation, and you can ask them of yourself:

• What task did you most dread this week, and how long did it take? This finds frustration and quietly sizes it.
• What would you build if you knew it would work? This surfaces ambition and the assumption worth testing first.
• What are you afraid a competitor will do before you? This names uncertainty in a way you can actually act on.
• What did you try before that disappointed you, and why? This exposes hope, and the realism it now needs.
• If nothing changed in twelve months, what would it cost you? This separates a real problem from a nice-to-have.

The answers rarely point at "we need AI." They point at a specific outcome, and AI may or may not be the best route to it — which is exactly the honesty the first conversation is for. Sometimes the right answer is a process change or a better integration, not a model at all, and a good partner will say so even when it is not the most lucrative advice.

Your data is rarely the real obstacle

One feeling deserves a special mention because it stops so many projects before they start: the belief that "our data is a mess, so we are not ready." It is almost always overstated. You rarely need pristine, perfectly governed data to prove a use case; you need enough of the right data to test one assumption. Plenty of valuable first projects run on a modest, slightly untidy slice of what a company already has. The data work that genuinely matters — pipelines, quality, structure — is real, but it is usually something you build alongside the first proof of concept, not a prerequisite that has to be finished before you are allowed to begin. If the founding feeling is "we are not ready," the honest test is small and fast: take a representative sample, try the thing, and let the result tell you what the data engineering roadmap really needs to be.

How we would start with you

If any of those feelings sounded familiar, that is the whole point — it means there is a real project in there waiting to be named. We start not by pitching a technology but by getting honest about what is actually bothering you, then turning that into the smallest concrete step that proves whether it is worth pursuing. Usually that is a short, plain-spoken conversation and a working prototype by the second call, not a procurement marathon. Review our transparent pricing, or book a free consultation and we will name your first use case together — starting, as every project really does, with the feeling underneath it.

Frequently asked questions